[coyotos-dev] Accept GCJ into the tool chain?

[Jonathan S. Shapiro]

On Mon, 2006-11-27 at 18:16 -0800, Tracy R Reed wrote:
> Ah, but by saying "factor of two" instead of "2ms vs 1ms" we are playing 
> statistical games to make the difference seem big.
> 
> Sort of like how a certain chemical might "double" your risk of cancer 
> which in reality means from .0002% to .0004%.
> 
> Even if it were 20ms vs 1ms it still wouldn't be a big deal. I can 
> afford to wait 19ms longer if it means I can have the software to use vs 
> not having it or having it work correctly vs being buggy.

Tracy:

I agree with the point you are making, but it isn't relevant to those
benchmarks.

First, those benchmarks are dominated by inner computational loops.
Depending on the benchmark, what we are seeing is a direct measure of
compute efficiency or memory access efficiency. In this case, I suspect
that the main performance issues are (1) the absence of any fixed
precision integer type in Haskell, and (2) the fact that Haskell, like
ML, is indirection prone (i.e. makes heavy reliance on boxed object
representations).

Of the two, the indirection issue is the important one for larger scale
computations. As computations grow too large to be handled in cache, the
indirections continue to incur load costs, but now at main-memory
latencies. This effect has been consistently measurable since the
invention of the "everything is a reference" languages.

GHC and other compilers have made interesting strides in deciding when
to take boxing out, but the problem here is fundamental: the language
lacks a way to express a programmer desire for unboxing, and the
compiler must infer it conservatively.

The ability to express both value types (i.e. unboxed aggregate or
composite types) and fixed-precision integral types is one of the
reasons I think BitC may do better on this class of benchmark, but of
course, we can't know that yet.


shap