Hello,
I've been playing around a little with Amber and Javascript. I found this Javascript benchmark from Dan Ingalls: http://www.weather-dimensions.com/Dan/JavaScriptBenchmark.html I copied that code into Amber using the "< ... >" syntax for embedding Javascript code in Amber methods. (Which I discovered in Number>>jsbenchFib). I made very few changes, only adding extra ">" escapes in the embedded HTML, and adding a call to the tinyBenchmarks function at the end. Here are the results I get from running the Javascript benchmark directly in my browser: n1 = 2; time = 1 milliseconds; 1000000000 operations/sec. n1 = 4; time = 3 milliseconds; 666666667 operations/sec. n1 = 8; time = 8 milliseconds; 500000000 operations/sec. n1 = 16; time = 14 milliseconds; 571428571 operations/sec. n1 = 32; time = 10 milliseconds; 1600000000 operations/sec. n1 = 64; time = 19 milliseconds; 1684210526 operations/sec. n1 = 128; time = 40 milliseconds; 1600000000 operations/sec. n1 = 256; time = 84 milliseconds; 1523809524 operations/sec. n1 = 512; time = 164 milliseconds; 1560975610 operations/sec. n1 = 1024; time = 342 milliseconds; 1497076023 operations/sec. n1 = 2048; time = 690 milliseconds; 1484057971 operations/sec. n2 = 24; time = 2 milliseconds; 37512500 sends/sec. n2 = 25; time = 4 milliseconds; 30348250 sends/sec. n2 = 26; time = 7 milliseconds; 28059714 sends/sec. n2 = 27; time = 10 milliseconds; 31781100 sends/sec. n2 = 28; time = 17 milliseconds; 30248765 sends/sec. n2 = 29; time = 27 milliseconds; 30816296 sends/sec. n2 = 30; time = 43 milliseconds; 31308581 sends/sec. n2 = 31; time = 72 milliseconds; 30254292 sends/sec. n2 = 32; time = 115 milliseconds; 30648504 sends/sec. n2 = 33; time = 197 milliseconds; 28948665 sends/sec. n2 = 34; time = 302 milliseconds; 30554520 sends/sec. n2 = 35; time = 489 milliseconds; 30532417 sends/sec. n2 = 36; time = 799 milliseconds; 30235065 sends/sec. Here are the results I get running the benchmark from inside Amber: n1 = 2; time = 26 milliseconds; 38461538 operations/sec. n1 = 4; time = 36 milliseconds; 55555556 operations/sec. n1 = 8; time = 25 milliseconds; 160000000 operations/sec. n1 = 16; time = 49 milliseconds; 163265306 operations/sec. n1 = 32; time = 99 milliseconds; 161616162 operations/sec. n1 = 64; time = 200 milliseconds; 160000000 operations/sec. n1 = 128; time = 397 milliseconds; 161209068 operations/sec. n1 = 256; time = 794 milliseconds; 161209068 operations/sec. n2 = 24; time = 5 milliseconds; 15005000 sends/sec. n2 = 25; time = 7 milliseconds; 17341857 sends/sec. n2 = 26; time = 12 milliseconds; 16368167 sends/sec. n2 = 27; time = 20 milliseconds; 15890550 sends/sec. n2 = 28; time = 34 milliseconds; 15124382 sends/sec. n2 = 29; time = 49 milliseconds; 16980408 sends/sec. n2 = 30; time = 82 milliseconds; 16417915 sends/sec. n2 = 31; time = 134 milliseconds; 16256037 sends/sec. n2 = 32; time = 214 milliseconds; 16469991 sends/sec. n2 = 33; time = 362 milliseconds; 15753831 sends/sec. n2 = 34; time = 603 milliseconds; 15302595 sends/sec. As you can see, the pure Javascript is much faster. I don't know much about the underlying mechanics of Amber (does anyone have pointers to an overview of how Amber works?). But I was surprised that a method that consists of a big chunk of Javascript is so much slower than the pure Javascript version. I expected that there would be a little call overhead, but the Javascript should then run at nearly full speed. I seems to me that the Javascript should not even be measuring the overhead, since all of the calculations and printing results are all done inside the Javascript code. As a final update before posting this message, I decided to save the code to a package, update my index.html with the package reference, and test again by reloading the Amber page. (vs. just typing the code into Amber and immediately running the test in a workspace). Here are the results: n1 = 2; time = 4 milliseconds; 250000000 operations/sec. n1 = 4; time = 1 milliseconds; 2000000000 operations/sec. n1 = 8; time = 3 milliseconds; 1333333333 operations/sec. n1 = 16; time = 5 milliseconds; 1600000000 operations/sec. n1 = 32; time = 10 milliseconds; 1600000000 operations/sec. n1 = 64; time = 21 milliseconds; 1523809524 operations/sec. n1 = 128; time = 41 milliseconds; 1560975610 operations/sec. n1 = 256; time = 96 milliseconds; 1333333333 operations/sec. n1 = 512; time = 170 milliseconds; 1505882353 operations/sec. n1 = 1024; time = 347 milliseconds; 1475504323 operations/sec. n1 = 2048; time = 716 milliseconds; 1430167598 operations/sec. n2 = 24; time = 5 milliseconds; 15005000 sends/sec. n2 = 25; time = 8 milliseconds; 15174125 sends/sec. n2 = 26; time = 12 milliseconds; 16368167 sends/sec. n2 = 27; time = 18 milliseconds; 17656167 sends/sec. n2 = 28; time = 30 milliseconds; 17140967 sends/sec. n2 = 29; time = 50 milliseconds; 16640800 sends/sec. n2 = 30; time = 81 milliseconds; 16620605 sends/sec. n2 = 31; time = 131 milliseconds; 16628313 sends/sec. n2 = 32; time = 213 milliseconds; 16547315 sends/sec. n2 = 33; time = 345 milliseconds; 16530107 sends/sec. n2 = 34; time = 602 milliseconds; 15328015 sends/sec. These numbers are much better than the code that was entered live in Amber. Maybe the Javascript JIT does not optimize dynamically loaded code? But, the sends/sec measurements are still low compared to the pure Javascript benchmarks. Does anyone have any ideas about what is going on here? (BTW these tests are using IE 9 on Windows 7). Thanks! Jerry |
Hi Jerry! I have no idea of IE, but i know, that some javascript jitters only compile at runtime (not at load!) and *only* inner loops, the rest stays interpreted. This is e.g. the case in Android 2.2+ for Java and in Javascript. I would be interested to see benchmarks in newest Firefox and chrome. And again my advice: Use chrome (beta on ANDROID 4.0 only :-( ) for development, because you can debug JavaScript via USB remote. best, Guido Stepken Am 12.02.2012 18:10 schrieb "Jerry Bell" <[hidden email]>:
Hello, |
Free forum by Nabble | Edit this page |