> Its a scripted language, therefore it needs to > be interpreted to produce a result. Its no raw > byte code like a compiled exe.
Raw byte code still needs to be interpreted - albeit translated to machine ops (rather than interpreted in the sense that a scripted language is). Only a compiled exe is. well. a compiled exe. Maybe by "'raw' byte code" you meant "pre-cooked - reheat to serve", as opposed to "These are the ingredients, now go cook it" :D My interest in these benchmarks is in the source - one must presume that the submissions were written to squeeze every last cycle of performance out of the language/runtime involved, since that was the object of the exercise. write fast code. Some Delphi source has been posted, and I find it interesting that the first attempt in Delphi, written intuitively, not highly optimised, not especially esoteric or exotic, was still faster than the best performing, presumably highly tweaked (so far) C# attempt. And I dread to think what that C# code would look like. Difficult to say without seeing the sources though. Performance is - in most cases - a trade off between raw execution speed and practically maintainable source. Delphi's - or perhaps rather: Pascal's + native compilation - great strength imho is that you get great execution speed without sacrificing maintainability, and can still get AWESOME execution speed should you absolutely need it. -- "Smile", they said. "it could be worse!" So I did. And it was. _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
