5 ms·

Ahead of time compilers do work quite well for a subset of dynamic languages. Just like tracing JIT works well for a subset. This has been proven by projects

by illumen 17y ago

Ahead of time compilers do work quite well for a subset of dynamic languages. Just like tracing JIT works well for a subset. This has been proven by projects like shedskin, cython, and tinypyC++. Given typing information, either explicitly or through type inference - massive speed-ups are possible. Also, tracing JIT currently does not do multiple CPU optimizations - which static compilers have been doing. They also don't do SIMD or MIMD optimizations, which compilers like gcc/icc/etc are doing. However, runtime assemblers - like 'Orc' 'corepy' and older ones like 'softwire' are proving to be lots faster in multimedia applications compared to traditional compilers or interpreters. These runtime assemblers give authors of programs access to the compilers/assemblers. Just like allowing people to specify typing, letting people construct programs at runtime can give massive speed-ups. C has even had fast interpreters for a while - see tinycc as an example. It doesn't use a tracing compiler, but a very straight forward direct translation compiler which happens to be faster than many interpreters. It's quite easy to argue 'No' to this question I think.

beagle3 17y ago
> C has even had fast interpreters for a while - see tinycc as an example. It doesn't use a tracing compiler, but a very straight forward direct translation compiler which happens to be faster than many interpreters. How is tinycc an interpreter? It's a full-blown compiler, alas a very simple one with very little optimization. If it weren't faster than an interpreter, I'd be shocked. For well written code, it reaches 50%-70% of modern gcc speed from tests I did a couple of years ago. I think that's on par, or even slightly better, than gcc 1.x
- barrkel 17y ago
  It helps that C is designed to have an almost one to one mapping between its native operators and machine operations and addressing modes. For example, the pre and post increment operators are expressions with side effects, can be confusing and can provoke undefined behaviour with ease. Having two variants also seems redundant. But the two variants may have different optimal translations to underlying CPU addressing modes, while leaving the pre or post modified value in a register is often a side-effect of the CPU translation. If the language only permitted ++ as a statement, the usefulness of side-effect would be lost. It's a cliche that C is little more than portable assembler, but at a design level there's a lot of truth to it. The length of the assembly translation of C code is usually pretty directly proportional to the source code token length. In more expressive languages with more powerful abstractions, that's frequently not the case.
  - andrewcooke 17y ago
    not arguing with your general point, but the difference between pre and post increment is very useful when writing things like stacks and queues with pointers. these days maybe people use libraries or templates, but i suspect they were introduced for ease of programming, not ease of translation. [edit: really, it's two sides of the same coin. it's useful, so both c and cisc chips have it, so the two match up...]
    - eru 17y ago
      > not arguing with your general point, but the difference between pre and post increment is very useful when writing things like stacks and queues with pointers. Of course this only applies to ephemeral variants of those data structures.

by illumen 17y ago

beagle3 17y ago

> C has even had fast interpreters for a while - see tinycc as an example. It doesn't use a tracing compiler, but a very straight forward direct translation compiler which happens to be faster than many interpreters. How is tinycc an interpreter? It's a full-blown compiler, alas a very simple one with very little optimization. If it weren't faster than an interpreter, I'd be shocked. For well written code, it reaches 50%-70% of modern gcc speed from tests I did a couple of years ago. I think that's on par, or even slightly better, than gcc 1.x

barrkel 17y ago
It helps that C is designed to have an almost one to one mapping between its native operators and machine operations and addressing modes. For example, the pre and post increment operators are expressions with side effects, can be confusing and can provoke undefined behaviour with ease. Having two variants also seems redundant. But the two variants may have different optimal translations to underlying CPU addressing modes, while leaving the pre or post modified value in a register is often a side-effect of the CPU translation. If the language only permitted ++ as a statement, the usefulness of side-effect would be lost. It's a cliche that C is little more than portable assembler, but at a design level there's a lot of truth to it. The length of the assembly translation of C code is usually pretty directly proportional to the source code token length. In more expressive languages with more powerful abstractions, that's frequently not the case.
- andrewcooke 17y ago
  not arguing with your general point, but the difference between pre and post increment is very useful when writing things like stacks and queues with pointers. these days maybe people use libraries or templates, but i suspect they were introduced for ease of programming, not ease of translation. [edit: really, it's two sides of the same coin. it's useful, so both c and cisc chips have it, so the two match up...]
  - eru 17y ago
    > not arguing with your general point, but the difference between pre and post increment is very useful when writing things like stacks and queues with pointers. Of course this only applies to ephemeral variants of those data structures.