An x86 emulator in Javascript? That must be slow, but probably not as bad as Ruby as too many heavyweights have invested in fast Javascript despite its design not being too good for speed and the fact that eval is abused way too much in javascript code.
>>7 and nobody sane uses eval.
I barely write any js myself, but I do view the source of the sites I go to and I've seen countless "minified"/"obfucated" versions of javascript abusing eval as much as they can. It's extremely common, both for compression purposes and obfucation purposes. Of course, removing the obfucation or reversing the compression to obtain the clean source code is quite easy, but that doesn't stop every idiot from abusing this.
While this isn't the fastest computer I've ever seen, it's still impressive.
Compiling and running a CRC32 bruteforcer in C took 5h13m, compared to 57sec on a singlecore celeron @ 1.3GHz.
>>30
To have some way of measuring the speed of jslinux, and it was the first mathematical operation I could think of that wouldn't be too ridiculously slow.
I've tried to use the same binary in both machines, but I get sh: ./test: not found on the JS one when trying to run the gcc compiled binary and bash: ./tccbc7: No such file or directory on the Ubanto one when trying to run the tcc's, so apparently the binary formats are incompatible or something? The first 25 binary bytes are the same (both start with the ELF signature), transfers are verified by md5sum, the file is marked as executable and is suggested by tab-completion, etc...
Box A: $ uname -a
Linux (none) 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686 GNU/Linux
$ gcc --version
gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Box B: ~ # uname -a
Linux (none) 2.6.20 #1 Wed May 18 23:22:20 CEST 2011 i586 GNU/Linux
~ # tcc -v
tcc version 0.9.25
So I installed tcc. I checked the generated code and it seemed comparable, main() and the import section were different but oh well, it'll have to do.
Now there's a quite serious problem: the JS emulator purposefully sleeps to avoid hanging the browser. According to the CPU performance counters, it generally only uses 75% of the total cycles available.
In any case, the emulator did 5m47.29s and the native one 0m1.213s. Correcting for CPU use, it's just a bit over 200 times slower. Well, that was underwhelming, but not too bad I guess.
I have no idea what urged me to do so, but I just tried this with IE6 SP1 and... HOLY SHIT, IT WORKS. It's extremely slow (took 15 minutes to boot on an OC'd i7) and eats memory like a pig (~2.3GB), but it works.