From: Jorge on
On Feb 1, 9:58 pm, Lasse Reichstein Nielsen <lrn.unr...(a)>
> Jorge <jo...(a)> writes:
> > Any ideas as for what would be a reasonable, short C vs. JS
> > benchmark ? :-)
> I wouldn't want anything too short. Micro-benchmarks generally suck
> at showing anything relevant for actual use.
> You could check out the computer language shootout (although I think
> it's a little misleading to allow a Java implementation that is one
> just JNI call to native code).

Well, this "Micro-benchmark" falls clearly in the "too short" class,

The results:

C: 126.5 MHz i386/32
C: 126.5 MHz x86/64
FF3.6: 29.3 MHz FireBug OFF
Chrome5.0.307.9: 26.8 MHz
v8-shell: 25.4 MHz version
FF3.5.8 21.2 MHz FireBug OFF
jsc: 9.0 MHz javascriptCore shell
Safari4.0.4: 7.9 MHz javascriptCore
Safari4.0.4: 1.8 MHz webInspector console
FF 3.0.15: 1.7 MHz FireBug OFF
Opera 10.5: 1.3 MHz
Opera 9.64: 1.2 MHz
Opera 10.10: 1.1 MHz
FF3.6: 0.6 MHz FireBug Console
Chrome5.0.307.9: 0.6 MHz Developer Tools console
FF2.0.0.20: 0.2 MHz FireBug OFF

The source code:

var k= 20e6; n= k, v= 0, t= +new Date();

while (n) {
v+= n/2/n;

t= +new Date() -t;
(this.alert || this.print)([(k/t/1e3).toFixed(1)+ " MHz", t+" ms",

volatile int RUN= 1;

void alrmHandler (int status) {
RUN= 0;

int main (int argc, char* argv[]) {
double ctr= 0;
double v= 0;
struct itimerval timer;
timer.it_interval.tv_sec= timer.it_interval.tv_usec= 0;
timer.it_value.tv_usec= 0;
timer.it_value.tv_sec= 1;

signal(SIGALRM, alrmHandler);
setitimer(ITIMER_REAL, &timer, 0);

while (RUN) {
v+= ctr/2/ctr;

fprintf(stdout, "%.1f MHz, %.1f\n", ctr/1e6, v);
return 0;

From: Jorge on
On Feb 2, 2:39 am, RobG <rg...(a)> wrote:
> On Feb 1, 11:19 am, Jorge <jo...(a)> wrote:
> [...]
> > Any ideas as for what would be a reasonable, short C vs. JS
> > benchmark ? :-)
> Is there any point?
> Such comparisons only really matter where you have a choice of doing
> something in both languages and other criteria for discrimination are
> (more-or-less) equal.
> For example, if the objective is a program that can be downloaded and
> run in most browsers, C is probably a not a consideration no matter
> how much faster it runs. On the other hand, if the requirement is for
> complex server-side processing, javascript probably isn't in the race
> as it doesn't have any built-in input/output mechanism and is
> dependent on a suitable host environment. If requirements indicate a
> scripting language, a platform-native shell script may be the best
> choice.
> Do you have a proposed scenario?

The ratio of processing power between them is changing every day. JS's
processing power has increased in a few years in more than 2 orders of
magnitude. It's still not (and will never be) as fast as a finely-
tuned C program (*) could be. But, you need to know better in order to
be able to decide -when JS is a viable option- where to draw the line
that separates what's possible/advisable to do with it, and what's

(*)A finely-tuned C program -that very likely- is going to take to
write many times as long as in a higher-level dynamic language -with
all the bells and whistles- such as e.g. JS.