- Original Message -
From: "Ken Fox" <[EMAIL PROTECTED]>
To: "Uri Guttman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, October 30, 2001 7:05 AM
Subject: Re: Improved storage-to-storage architecture performan
Michael L Maraist wrote:
> The only "memory" storage for scalars that I currently am conceiving of is
> in name-space stashes (globals). Thus our most likely implementation of S2S
> would be to have 'add "g_x", "g_y", "g_z"' which performs two stash
> lookups, an add, then one stash write.
Kakap
Dan Sugalski wrote:
> Hmmm. I'd like to see the two run with the same style dispatcher to get a
> closer comparison of run speeds. When you say threaded, you're doing more
> or less what the switch/computed-goto dispatcher does, right?
If you take a look at the op_add code I posted, you'll see
On Tuesday 30 October 2001 01:47 am, Ken Fox wrote:
> Uri Guttman wrote:
> > that is good. i wasn't disagreeing with your alternative architecture.
> > i was just making sure that the priority was execution over compilation
> > speed.
>
> I use a snazzy quintuple-pass object-oriented assembler wri
At 12:42 PM 10/30/2001 -0500, Michael L Maraist wrote:
> > Absolutely. Compile-and-go is an absolute must, and one that'll end up
> > disabling most of the potential optimizations for sheer startup time
> > reasons. Which is a pity, but we can always let people enable them if they
> > want from
Ah, one other spot where SS is a real problem.
Threads.
If we have fixed addresses to data stored in the executable code, it means
that every time we spawn off a thread we need to clone and fix up all the
code it has access to, otherwise Bad Things Will Happen. :(
At 11:21 PM 10/29/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > What sort of dispatch was your version using, and what sort was
> > parrot using in your test?
>
>Parrot used the standard function call dispatcher without bounds
>checking.
>
>Kakapo used a threaded dispatcher. There's a pre-pr
> Absolutely. Compile-and-go is an absolute must, and one that'll end up
> disabling most of the potential optimizations for sheer startup time
> reasons. Which is a pity, but we can always let people enable them if they
> want from the command line.
Or via "use flags", since mod_perl and the l
At 01:05 AM 10/30/2001 -0500, Ken Fox wrote:
>The other thing to consider is that Perl is still a compile-on-the-fly
>system. I hope Perl 6 keeps this aspect of Perl instead of moving to a
>more Javaesque development environment.
Absolutely. Compile-and-go is an absolute must, and one that'll end
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Uri Guttman wrote:
>> so my point is the the speed of the VM is a separate issue from the ease
>> of code generation. an S2S VM would be easier to code generate for but
>> may be slower to run. the speed difference is still an open poi
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Uri Guttman wrote:
>> and please don't bring in hardware comparisons again. a VM design
>> cannot be compared in any way to a hardware design.
KF> I didn't say a single thing about hardware. My entire post was
KF> simply about an al
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> I think this is why storage-to-storage architectures have lost
KF> favor -- today's compilers are just too smart. Possibly with a
KF> software VM the memory pressure argument favoring registers isn't
KF> strong enough to offset the di
Uri Guttman wrote:
> that is good. i wasn't disagreeing with your alternative architecture.
> i was just making sure that the priority was execution over compilation
> speed.
I use a snazzy quintuple-pass object-oriented assembler written
in equal parts spit and string (with a little RecDescent t
Uri Guttman wrote:
> so my point is the the speed of the VM is a separate issue from the ease
> of code generation. an S2S VM would be easier to code generate for but
> may be slower to run. the speed difference is still an open point as dan
> has said. but since his goal is execution speed, that
Uri Guttman wrote:
> and please don't bring in hardware comparisons again. a VM design
> cannot be compared in any way to a hardware design.
I have absolutely no idea what you are talking about. I didn't
say a single thing about hardware. My entire post was simply about
an alternative VM architec
Dan Sugalski wrote:
> What sort of dispatch was your version using, and what sort was
> parrot using in your test?
Parrot used the standard function call dispatcher without bounds
checking.
Kakapo used a threaded dispatcher. There's a pre-processing phase
that does byte code verification because
At 04:44 PM 10/29/2001 -0500, Ken Fox wrote:
>Well, I've tuned things up a bit. It's now
>hitting 56 mops with the mops.pasm example. Parrot
>turns in 24 mops on the same machine with the same
>compiler options.
Damn. I hate it when things outside my comfort zone end up being faster. :)
>This i
A little while back I posted some code that
implemented a storage-to-storage architecture.
It was slow, but I tossed that off as an
implementation detail. Really. It was. :)
Well, I've tuned things up a bit. It's now
hitting 56 mops with the mops.pasm example. Parrot
turns in 24 mops on the same
18 matches
Mail list logo
