Interesting, ye this is something like im talking about

curious if games made in JS or as java applets are much more slow than that? I heard tahat Js is about 5 times slower than native code, java should be faster probably.. still dont know those things though they are probably well known

What you heard is random hearsay about various other projects, not your projects.

JavaScript is a very different thing from Java applets. The name is only similar due to marketers.

Any tales of "5 times slower" are going to depend on details that are not provided. There are programmers who just keep guessing and hoping, and there are programmers who use science, as in computer science.

Take measurements. Form a hypothesis based on the measurements. Make a test. Take new measurements based on the test. Then make decisions based on the test results. You don't say "I heard someone once took measurements on some other projects, so I'm going to blindly assume that is my problem as well."


Since we are in computer science, it works like this:

I measured the program to be slow due to X. I suspect that the problem is Y. I can implement change Z which will correct the problem because of specific reasons that I can list. After implementing the change, I can measure again and get results X' which I can compare against X. If X' is better than X I will submit the change and accept that Y was correct. If not, I will assume either Y or Z was wrong and try again.


Yes, scripted code sometimes run slower than compiled code. But it is very likely that isn't the problem. Unless it is. Your computer can do billions of instructions every second. Does your code require billions of instructions? I've seen computer vision algorithms written in scripted languages that ran in real time on 300MHz computers. Chances are good that whatever bottleneck you are facing, it isn't the fact that you are using a scripted language.

Depending on how you define 'safe' I would argue that neither can be done safely.

windows programs are anyway strangely unsafe, for example is it often a need to grant an application possibility to write data to the other folders than its own? - also to change global settings etc

curious if games made in JS or as java applets are much more slow than that?

This is why The Code Deity invented Benchmarks and gave the Word to the People so that they might spread the Benchmarks to all that they might know Her grace and majesty.

Here's one of Box2D that literally took 10 seconds to find.

very interesting - close to what i heard but a bit more indepth

javascript being slower a couple of times (say about 7x and that order -

that is fast, quite fast),

jave being slower 2x here (I tested sometimes java is faster, some number crunching i tested in java once was so fast as in c) anyway it is also fast

action script is faster than javascript and a bit unknown to me asmjs is

like java

so imo it is worth to invest in javascript as it is easy to use and interesting

In answer to the Thread Title.

Anything that is transported from the internet onto a machine and executed there natively just in place is a security risk. Only in a closed environment and for a defined set of commands it may have a lower risk, because it is under control of the management of this closed environment.

In answer to the Thread Title.

Anything that is transported from the internet onto a machine and executed there natively just in place is a security risk. Only in a closed environment and for a defined set of commands it may have a lower risk, because it is under control of the management of this closed environment.

sure but question is if binary code couldnt be safely sandboxed same safely as bytecode or scriptcode

This is another very different question.

byte-code-interpreters use a virtual machine to let the code run.

If you want native code let run in a vm you loose the speed benefits that may exist compared to a java vm or php or perl.

All the for now existing byte-code languages with their respective VM have a long time of development gone by. If a solution do not give any benefit over the already available languages noone will work on the realization of such a technique.

This is another very different question.

byte-code-interpreters use a virtual machine to let the code run.

If you want native code let run in a vm you loose the speed benefits that may exist compared to a java vm or php or perl.

All the for now existing byte-code languages with their respective VM have a long time of development gone by. If a solution do not give any benefit over the already available languages noone will work on the realization of such a technique.

as you see gogle native client is doing this, they say

NaCl uses software fault isolation for sandboxing on x86-64 and ARM.[17] The x86-32 implementation of Native Client is notable for its novel sandboxing method which makes use of the x86 architecture's rarely-usedsegmentation facility.[18] Native Client sets up x86 segments to restrict the memory range that the sandboxed code can access. It uses a code verifier to prevent use of unsafe instructions such as those that perform system calls. To prevent the code from jumping to an unsafe instruction hidden in the middle of a safe instruction, Native Client requires that all indirect jumps be jumps to the start of 32-byte-aligned blocks, and instructions are not allowed to straddle these blocks.[18]Because of these constraints, C/C++ code must be recompiled to run under Native Client, which provides customized versions of the GNU toolchain, specificallyGCC and binutils as well as LLVM.

(i do not understand whats going on with this 32-aligned blocks, but anyway it seem that i can answet to my question that it can be done

safely though with some slowdown (some benhmark mentioned in other thread was saying that it was for example 30% slowdown) Anyway im not sure if it is so much usable, Todays ineternet seem to be full of so many tehnologies, java, flash, javascript, some other things yet this 9i know a little about this all)

Not using a VM but trying to isolate the plugin is a security risk. Using the segment registers makes assumptions about the processors that run the software. On Intel processors this may work, even it is something that noone should rely on. Forced to use a different toolchain and to use a 32-Bit environment gives lots of trouble while creating the software.

If you develop the software and do your tests on a simple PC machine, and you must afterwards cross-compile the software to put it on target, you added the first source of faults to your development. Reducing the default data width from a 64-Bit environment to a 32-Bit environment you will add another source of faults to your development.

sure, but i know that all no need to write it to me as i just know it;

as for me this thread can be closed now