"Near C Performance" w/ TraceMonkey JavaScript Engine

"Near C performance" on carefully selected algorithms. This fails to take into account:

a) The general cost of cleanup of variables (Garbage collection)
b) The time cost of compilation (Just in time means that large javascript libraries will take seconds, not milliseconds out of your performance)
c) The fact that javascript is both untyped and dynamic, meaning that large amounts of indirections nessisarilly occur which will prevent C-speed performance from ever being achievable with javascript
d) In C, if you write to an array past memory, your program crashes or exposes horrific bugs in your app. Because javascript should never allow arbitrary pointer-based code to run on your system, it must nessisarilly include checks that C does not, and will therefore nessisarilly experience slow down on all array accesses for bounds checking - optimising some of these away is possible, but slows down the JIT.
e) The fact that javascript generally outputs by modifying a HTML DOM tree, which is large, unwieldy and needs to be re-rendered and balanced after every mutation, which is expensive compared to C which typically only modifies in-memory objects for algorithms.

So I'm going to cry FUD on the whole "nearly as fast as C" statement here.

"Faster than C?" I think you'll find that these are just compiler optimisations, not that the code is actually faster.

For example, from (pseudo) Spec#:


ensures result > 0
ensures (p == q) implies result = 0
public int Distance(Point! p, Point! q){
  return (int)Math.Sqrt( (p.x - q.x) * (p.x - q.x) + (p.y - q.y) * (p.y - q.y) );
}

requires p > 0
ensures p == 0
public int factorial(int p){
  if(p == 0) return 1;
  return p * factorial(p - 1);
}


public static void main(){
  int i = 7;

  // Spec# should be able to avoid the if( !(p > 0) ) throw new ArgumentException("p > 0 assertion failed"); step here
  // because it knows the parameter here. In C this would typically happen inside the function.
  Console.WriteLine( factorial( i ) );

  // Spec# can probably optimise away this entire function, since distance contains no side-effects and the first ensures
  // defines the result of the function.
  Console.WriteLine( distance(new Point(i, i), new Point(i, i) ));
}

Note that while this is "better than C performance", it's not better than an ideal C representation of the program:

int factorial(int f){
  if(f == 0) return 1;
  return factorial(f - 1) * f;
}
void main(){
  printf("%d\n0", factorial(i));
}

But is better than a non-ideal version of the program:

int factorial(int f){
  assert(f < 0);
  if(f == 0) return 1;
  return f * factorial(f - 1);
}

int distance(struct Point* p, struct Point* q){
  assert(p != NULL);
  assert(q != NULL);
  return (int)sqrt( (p->x - q->x) * (p->x - q->x) + (p->y - q->y) * (p->y - q->y) );
}


void main(){
  int i = 7;
  struct Point* a, b;

  printf("%d\n", factorial(i));

  a = malloc(sizeof(Point));
  b = malloc(sizeof(Point));

  a->x = i;
  a->y = i;
  b->x = i;
  b->y = i;

  printf("%d\n", distance(a, b));

  free(a);
  free(b);
}




Because C is so close to assembly language, it's fairly simple to deconstruct assembly language into C. Consequently any high-level language that runs "faster than C" is usually lying, because the high level language can be decomposed to assembler and recomposed to C, which by-defintion runs in the same speed. High level languages have lots of benefits, but when there are additional constraints such as garbage collection, C will nearly always win in a straight battle of which has the higher theoretical speed for an algorithm.

With the 'new" keyword, almost certainly. With RAII stack initialization, probably not

// C++
void main(){
  Point* p = new Point(4,4);
  delete p;
}

pseudo-turns into:
  1. get me 8 bytes of data on the heap (a bit expensive, but not hugely)
  2. call the constructor for point  (relatively cheap)
  3. call the destructor of point (relatively cheap)
  3. free the data (almost no cost)

Total cost: some.

// C++
void main(){
  Point p = Point(4,4);
}

pseudo-turns into:
  1. add 8 to ESP (almost free)
  2. call the constructor for point (relatively cheap)
  3. call the destructor for point (relatively cheap)

Total cost: very little.

// C#:

void main(){
  // let's pretend Point is a class not a struct-type for comparison
  Point p = new Point(4,4);
}

pseudo-turns into:
  1. call GC::allocate(8);  (relatively cheap)
  2. expand the heap if necessary (expensive - requires a full generational collection)
  3. register the object in the GC (relatively cheap)
  4. call the constructor for point (relatively cheap)
  5. Fall off the end of the program. Call destructors for everything (relatively cheap)

Total cost: a bit.

That definition of speed relies too heavilly on the competence of the programmer.

It's like saying that my new hypothetical language is much better than C because it uses quicksort, whereas some hypothetical C programmer uses bubblesort. Since my implementation is better, my language is faster at sorting an array.

I don't want to a pedant, but malloc is a library function (sbrk is the OS version and is limited to whole pages).

For double-pedantry, C# doesn't use malloc because the GC uses it's own heap, roughly of the sort:

class GCHeap {
public:
  unsigned char* base, current;
  size_t capacity;

  void* allocate(size_t s){
    if(current - base > capacity) { fullCollect(); expandHeap(); }
    void* next = current;
    current += size;
    return next;
  }
}

Which is rather cheap to perform (amortized O(1) time). The rationale here is to avoid memory fragmentation.

I'm happy to concede that a fortran program could achieve better than C performance. I'm going to be uneasy with C# getting better than C performance without using clever optimisations such as those found in Spec# (where I'll concede that this may be possible for normal programs). If a paper concluded this I would look rather carefully at the graphs and code to make sure they weren't cherry-picking examples . But for javascript? No. You've got to be having a laugh. Javascript is interpreted at runtime, dynamic, operates on a DOM which is graphically rendered, is not pointer based and is fully garbage collected. There is no hope in hell that it will ever be in the same league as C for speed.