[Shootout-list] thoughts on the subject of ''compile to native code''

[Bengt Kleberg]

Brandon J. Van Every wrote:
...deleted
> I think we'll first have to define what 'grossly distinct' means.  2x or
> 3x performance differences matter to me.

if you look at the scorecard of a current shootout test you will find 
that some interpreted languages are faster than some languages that 
compiled to native code.
therefore i think that while your belif might have been correct some 
time ago (you refer to the original shootout like this:''all the 
compiled languages were in the same
ballpark of performance.  All the interpreted languages were in a clump
below them.''), this is no longer true.
if you have some definition of 'grossly distinct' that will make your 
statement true again, you are wellcome to supply it.


...deleted

> Because it's a Big Picture issue and the top test page is where Big
> Picture issues should go.

i think that if we are looking at performance, then how we have achived 
this performance is important. i do not think that one method of 
achiving this performance is a big picture issue, while the others are 
not. i think it is logical instead to look at how big a performance 
change we get from what we did. if we want more than one entry for a 
language in a test, then the importance of the change should decide if 
it should be a big picture issue. not if it is a certain kind of 
performance enhancer, no matter if it made a change to performance of not.
would you care to explain why compiles to native code is an big issue, 
when the other means of speeding up the test are not? the explanation 
would preferably handle the cases when compiled to native slowed down 
the test.


>>i would go as far as
>>to state that this is impossible since some languages does
>>not have both compiler and interpreter.
> 
> 
> When people select a language and implementation, they do not limit
> themselves only to a specific language.  They say, "Ok, I can get both
...deleted

on this particular example of a thought on the subject of ''compile to 
native code'' i am limiting myself to specific languages. i am limiting 
myself to those that can achive a speedup in a test by either doing lots 
of performance enhanching tricks with flags while not compiling to 
native code, or they can do lots of performance enhanching tricks with 
flags while also compiling to native code.
there are not many of those in the shootout. i am sure about erlang, 
almost sure about mzscheme and ocaml.

perhaps i have missed some more? corrections are wellcome.

anyway, i do not understand your arguemnts as to why these languages 
should have exactly 2 entries in the test score card.
i think one entry is more logical. we are talking performance, and 
should take the best performance entry. we do that for all other ways of 
increasing performance. given the large amount of ways available i think 
there is no logical reason to special treat compiles to native code.


...deleted
> *mentally* tracking how good the Windows support is.  What I'm saying,
> is there's a reason to put the 1st, 2nd, 3rd, and 4th best language
> performers on a top page.  People are not interested in performance
> only.  Implicitly, if not explicitly, they're evaluating the language on
> many axes when they look at the performance numbers.

i agree. i think there are other important things, too.

in this thread i am trying to show that i find no logical reason to have 
special treatment of compiles to native code for the languages that can 
increase performance in other ways too.


...deleted
> I agree that bytecode vs. interpreted is another gross distinction.

that is nice. would you please let me know how you have reasoned when 
deciding that this gross destinction is not to be part of the big 
picture issue?


...deleted

> Actually, we can.  Nothing's stopping us.  The question is why we would
> or wouldn't want to.  Personally, I think we wouldn't want to, due to
> information overload.  I think we should stick to the options that cause
> major performance differences, and blow off the minor tweaks.

i agree about the information overload. i specifically think that only 
the fastest performance should be present for each langugage.
why should the option compile to native code always be present for the 
(3?) languages that can do it? it might not even be the tweak giving the 
major performance boost for that language in that test


>>the shootout is about performance.
>>we should use performance as the decisive factor for what we
>>should put on a ''top test page''.
> 
> 
> 'Performance comparison' or 'maximum performance' ?  You seem to be
> implying the latter, and I don't agree with you.  I think the
> performance differences between natively compiled, bytecode compiled,
> and interpreted code are important enough to warrant front page billing.

ok. does this mean that you want (for those languages that have the 
possiblility) to list the 3 fastest test results?
(ie, that is one fastest result for native code, one for byte code and 
one for interpreted)
why do you not want just-in-time compilation, too?


...deleted

i have here deleted some writings by Brandon J. Van Every that does not 
deal with the technical questions we are discussing. this is not done 
because there is anything wrong with them. it is because i have promised 
the shootout list to conduct such discussions in private email.

please Brandon J. Van Every, try and be polite towards the other readers 
of this list. use private email if you are interested in creating a 
better understanding of the non technical part of our discusion.


bengt