Re^2: {Perl6} Macros and native compilation

Even if you do natively compile, you need the compiler/VM there anyway, to handle the evals, so why not just keep the bulk of the code as Parrot

Because going all the way down to native code can give you a fair speed increase. You can get a very impressive turn of speed out of modern Lisp compilers.

Comment on Re^2: {Perl6} Macros and native compilation

Replies are listed 'Best First'.
Re^3: {Perl6} Macros and native compilation by chip (Curate) on Apr 11, 2005 at 14:30 UTC
In a new twist on an old favorite: "Benchmarks welcome." I'm especially interested to know what a full-on native code compiler can do for you that a JIT can't. -- Chip Salzenberg, Free-Floating Agent of Chaos	[reply]
Re^4: {Perl6} Macros and native compilation by adrianh (Chancellor) on Apr 11, 2005 at 15:24 UTC
I'm especially interested to know what a full-on native code compiler can do for you that a JIT can't Oh I've nothing against JIT. Compilation to native code is compilation to native code (if we ignore all that tedious mucking about with caching and timing of the compiles). As for benchmarks take a look at Lisp is slow (NOT!) for an example of CMUCL and SBCL (compiled Lisps) beating out C++ in a benchmark. Please don't take this to mean that I think compilation to native code is necessary, or that interpreted VMs are useless and slow. Premature optimisation and all that. I will quite happily use Perl 6 running on an interpreted Parrot and I'm sure it will do all that I need it to do. The domains that I spend most of my time coding in are not CPU bound. You just asked "why not just keep the bulk of the code as Parrot" - and speed (for those where it is an actual, rather than an imagined, issue) is one reason.	[reply]