- 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 performance
> Uri Guttman wrote:
> > so my point is t
Implements the following instructions:
1) open(i|ic,i|ic,s|sc) - Filehandle in $1, r/w mode in $2 (permissions
644), filename in $3
2) read(s,i|ic,i|ic) - String register in $1, filehandle in $2, number
of chars in $3
3) write(i,s) - Filehandle in $1, string register in $2
4) close(i) - Filehandl
On Oct 30, Dan Sugalski <[EMAIL PROTECTED]> took up a keyboard and banged out
> At 10:19 AM 10/30/2001 -0500, Michael Fischer wrote:
> >On Oct 29, Dan Sugalski <[EMAIL PROTECTED]> took up a keyboard and banged out
> > > At 03:33 PM 10/29/2001 -0500, Ken Fox wrote:
> > > >Anybody do a gcc-specific
> I have an Athlon 700 too. With these compiler flags:
>
> PERL-CFLAGS = -O3 -fomit-frame-pointer -pipe -s -march=pentium -ffast-math \
> -fexpensive-optimizations -fno-strict-aliasing \
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
> I'm seeing 24 mops which puts Parrot even cl
On Tue, 30 Oct 2001, Dan Sugalski wrote:
> Okay, so I put together the code to handle checking the type of a stack
> entry. (entrytype Ix, iy) Seems to work OK, and I'm about to commit the
> thing. The single thing that's missing are some tests, so I take a look at
> t/op/stacks.t, and... Eeek
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
Okay, so I put together the code to handle checking the type of a stack
entry. (entrytype Ix, iy) Seems to work OK, and I'm about to commit the
thing. The single thing that's missing are some tests, so I take a look at
t/op/stacks.t, and... Eeek!
I fully admit I have no idea what's going on in
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 09:46 AM 10/30/2001 -0500, Ken Fox wrote:
>Kevin Huber wrote:
> > This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
> > versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
> > Parrot performance is very comparable to Java in interpreted mode.
>
>I have an
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 05:27 PM 10/29/2001 +, David Trusty wrote:
>I would like to request a new feature for perl: The ability to
>attach a perl debugger to a running process.
This is a not inconsiderable task, and one with some potential security
issues if perl wasn't fired up with remote debugging enabled al
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
At 07:16 PM 10/29/2001 -0500, James Mastros wrote:
>Yeah. But that's a convention thing, I think. I also think that most
>people won't go to the bother of writing conversion functions that they
>don't have to. What we need to worry about is both, say, big5 and shiftjis
>writing both of the conv
At 10:19 AM 10/30/2001 -0500, Michael Fischer wrote:
>On Oct 29, Dan Sugalski <[EMAIL PROTECTED]> took up a keyboard and banged out
> > At 03:33 PM 10/29/2001 -0500, Ken Fox wrote:
> > >Anybody do a gcc-specific "goto *pc" dispatcher
> > >for Parrot yet? On some architectures it really
> > >cooks.
At 04:24 PM 10/30/2001 +, Simon Cozens wrote:
>On Tue, Oct 30, 2001 at 10:19:10AM -0500, Michael Fischer wrote:
> > Also, my understanding was that the goto *pc _was_ indeed very
> > gcc specific, and therefore a no-no for parrot. Thoughts?
>
>If we have switchable runops cores, I'm cool with
On Tue, Oct 30, 2001 at 10:19:10AM -0500, Michael Fischer wrote:
> Also, my understanding was that the goto *pc _was_ indeed very
> gcc specific, and therefore a no-no for parrot. Thoughts?
If we have switchable runops cores, I'm cool with having
compiler-specific stuff. But wouldn't it be cool
On Oct 29, Dan Sugalski <[EMAIL PROTECTED]> took up a keyboard and banged out
> At 03:33 PM 10/29/2001 -0500, Ken Fox wrote:
> >Anybody do a gcc-specific "goto *pc" dispatcher
> >for Parrot yet? On some architectures it really
> >cooks.
>
> That's a good question. There was talk and benchmark num
Kevin Huber wrote:
> This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
> versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
> Parrot performance is very comparable to Java in interpreted mode.
I have an Athlon 700 too. With these compiler flags:
PERL-CFLAG
Kevin Huber sent the following bits through the ether:
> Parrot2Java which I will make available once I fix a few more bugs
> :-).
Oh, cute! I've been frustrating myself by trying to do it the other
way around (it'll happen eventually...). Optimising the stack
loads/saves will be the fun part
This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
Parrot performance is very comparable to Java in interpreted mode.
I've attached mops.class and mops.ksm, some disassembly output from
Kopi. mops.class was
> "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
Automated smoke report for patch Oct 29 20:00:02 2001 UTC
v0.02 on hpux using cc version B.11.11.02
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t =
In message <[EMAIL PROTECTED]>
James Mastros <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 29, 2001 at 11:20:47PM +, Tom Hughes wrote:
>
> > I suspect that the encode and decode methods in the encoding vtable
> > are enough for doing chr/ord aren't they?
>
> Hmm... come to think of it, ye
29 matches
Mail list logo
