- 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
On 10/30/01 5:12 PM, Damian Conway wrote:
>> # Change apple color, but leave the blue berry
>> $obj.fruit(apple => 'green');
>
> No. You want:
>
> $obj.fruit{apple} = 'green';
Hm, I think I'll be writing arg-type versions of that one because I'm not
too comfortable with exposing the fac
> 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
Damian Conway:
# BTW, colon isn't an operator (it's a separator), so it can't be hyped.
What do you mean? We can hype the colon all we want! :^)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, Im not going to fire a $2 million missile at a $10
empty tent and h
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
> > method foo ( $me, $again : $big, $boy ) {...}
> >
> > should be able to be called via either of:
> >
> > foo $obj1, $obj2 : @args;
> > or:
> > ($obj1, $obj2).foo(@args);
>
>
> This stuff brings to mind all sorts of questions:
>
John icked:
> > # # Change apple color, but leave the blue berry
> > # $obj.fruit(apple => 'green');
> > #
> > # print $obj.fruit('apple'); # green
> >
> > $obj.fruit{apple}
>
> Icky, looks "unencapsulated" to me :)
[For the benefit of those playing alon
John asked:
> So, what about simple array accessors?
Writing:
class Demo;
my @.colors is public;
gives you:
> $obj.colors('red', 'green', 'blue');
No. $obj.colors() takes no arguments.
> $obj.colors = ('red', 'green', 'blue');
Yes.
> $obj.color
On Wed, 31 Oct 2001, Damian Conway wrote:
> To me C means: "the *value* stored in the memory
> implementing this variable cannot be changed". Which doesn't preclude
> rebinding the variable to some *other* memory.
>
> But others have a different (and equally reasonable) interpretation of
> C: "th
Aaron wrote:
> > sub foo (@args) -> rettype
>
> Hmm... I would have expected "is" to come in here:
>
>sub foo (@args) is IO::Handle
It would have to be:
sub foo (@args) is type(IO::Handle)
or something, I think. Unless Larry decides that every class/module
name i
Aaron wrote:
> > C means: "Once declared cannot be *assigned* to".
> >
> > But that doesn't mean one can't *bind* a new value to the
> > variable (which would retain its C-induced unassignability
> > after the binding).
>
> I understand that. I guess what I'm saying is, f
On Tue, Oct 30, 2001 at 12:27:32PM +1100, Damian Conway wrote:
>
>> >($obj1, $obj2)->foo(@args);
>>
>> Is that merely sugar for:
>>
>> # errr, $_.foo(@args) ?
>> $_->foo(@args) foreach($obj1, $obj2);
>
> No. What you showed would be achieved with either
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
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
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
On 10/30/01 12:13 PM, Brent Dax wrote:
> John Siracusa:
> Please note that these are my best guesses; I'm not a Damian ;^).
>
> # $obj.colors('red', 'green', 'blue');
> #
> # $obj.colors = ('red', 'green', 'blue');
> #
> # $obj.colors = ['red', 'green', 'blue' ];
>
> $obj.colors=('r
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
John Siracusa:
# Okay, so we've got these guys auto-created if we want:
#
# method foo is lvalue { return $.foo }
#
# (plus or minus the syntax) which lets us do:
#
# $obj.foo = 5;
# print $obj.foo;
#
# So, what about simple array accessors?
Please note that these are my best guesses;
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
Okay, so we've got these guys auto-created if we want:
method foo is lvalue { return $.foo }
(plus or minus the syntax) which lets us do:
$obj.foo = 5;
print $obj.foo;
So, what about simple array accessors?
$obj.colors('red', 'green', 'blue');
$obj.colors = ('red', 'green
On Mon, Oct 29, 2001 at 04:16:24PM -0800, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> : 3. If you declare a method *without* any parameter list:
> :
> : method foo {...}
> :
> :then the method call arguments (including the invocant?)
> :are bound to @_.
> :
>
On Tue, Oct 30, 2001 at 03:59:30PM +1100, Damian Conway wrote:
> (Though I *do* harbour a secret desire to resurrect -> as a type specifier:
>
> sub foo (@args) -> rettype
Hmm... I would have expected "is" to come in here:
sub foo (@args) is IO::Handle
> my $bar -> int;
H
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 Tue, Oct 30, 2001 at 04:29:15PM +1100, Damian Conway wrote:
>
>> > I'd do that like so (using Larry's preferred syntax):
>> [...]
>> > method INIT ($idval) { $.id := $idval }
>>
>> Hm... that looks to me like a regular ":="; is it?
>
> Yep.
>
>
>> If so, what
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
44 matches
Mail list logo
