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
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 =
> "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
> "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> 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
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
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
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
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
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
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
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 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 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 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
> 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 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
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
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 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
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
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
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
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
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
> 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 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
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
- 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
29 matches
Mail list logo
