On Wed, Aug 02, 2000 at 09:01:18PM +0100, [EMAIL PROTECTED] wrote:
> On Wed, Aug 02, 2000 at 12:20:00PM -0600, Nathan Torkington wrote:
> > Ken Fox writes:
> > > pipeline stalls, cache misses and a whole bunch of interesting things. One
> > > of the reasons Perl performed well is that it spent a lot of time in what
> > > they called native code, i.e. not decoding and dispatching ops.
>
> I think the key point there is that many perl ops are 'heavy'. They
> tend to do a lot of work.
I assume folks have read the C# article by now. As seen from here, one
of the most interesting things that they have is declared that .NET
languages will not be interpreted. Everything is compiled to native
code, either before execution or just-in-time. Obviously this is
(potentially) faster than any kind of bytecode or op-tree.
Of course perl6 can retain both execution models (op-tree & native
code), but perhaps the emphasis should be on optimized native code. To
contrast, perl5 is interpreter-centric with native code generation
bolted on well into the development lifecycle. It light of this
perspective, chatter about no/inline & opcode reorganization seems a bit
premature. On the other hand, compile-time variable typing seems
eminently relevant. Also, I'm sure we can improve perl's arithmetic
performance. Does .NET support PDL[1]?
[1] pdl.perl.org
--
May the best description of competition prevail.
(via, but not speaking for Deutsche Bank)
