On 09/07/01 Dan Sugalski wrote:
The only optimizations that interpreter had, were computed goto and
allocating the eval stack with alloca() instead of malloc().
Doesn't this really get in the way of threading? You'll chew up great gobs
of system stack, and that's a scarce resource when
hi,
I see that it was mentioned that Perl5 is fast than Java, Python etc... and
was wondering is there any comparison how-much, if ? and if why ? and if we
know the reason can we exploit it further ... and similar...
And does really Perl6 will be faster. how much u expect ?
Thanx
=
iVAN
At 10:30 PM 9/7/2001 +0300, raptor wrote:
I see that it was mentioned that Perl5 is fast than Java, Python etc... and
was wondering is there any comparison how-much, if ? and if why ? and if we
know the reason can we exploit it further ... and similar...
And does really Perl6 will be faster.
On Friday 07 September 2001 05:38 pm, Dan Sugalski wrote:
As for perl 6 vs perl 5, that's reasonably easy. We benchmark things on
perl 5.004_04 and 6.x, and see who wins. If 6 doesn't, we find out why and
speed it up. :)
5.004? (Is that where the big drop-off begins?)
You are going to take
At 05:41 PM 9/7/2001 -0400, Bryan C. Warnock wrote:
On Friday 07 September 2001 05:38 pm, Dan Sugalski wrote:
As for perl 6 vs perl 5, that's reasonably easy. We benchmark things on
perl 5.004_04 and 6.x, and see who wins. If 6 doesn't, we find out why and
speed it up. :)
5.004? (Is
On Friday 07 September 2001 05:51 pm, Dan Sugalski wrote:
(Like
Unicode Everywhere).
Who's doing that? We're keeping things in native format as much as we can.
If one of our stated goals is Unicode support (even for the source itself -
that's what I meant by everywhere: source, input,
: Friday, September 07, 2001 3:30 PM
To: [EMAIL PROTECTED]
Subject: Re: An overview of the Parrot interpreter [speed]
hi,
I see that it was mentioned that Perl5 is fast than Java, Python
etc... and
was wondering is there any comparison how-much, if ? and if why ?
and if we
know the reason
On Friday 07 September 2001 11:08 pm, Sterin, Ilya wrote:
Actually there were some tests done, can't recall where now, though by a
trusted source. I will be digging it up in my email and emailing it to the
list. There were a few languages tested including Perl, C, C++, Java
(can't remember
On Sun, Sep 02, 2001 at 11:56:10PM +0100, Simon Cozens wrote:
Here's the first of a bunch of things I'm writing which should give you
practical information to get you up to speed on what we're going to be doing
with Parrot so we can get you coding away. :) Think of them as having a
Simon Cozens wrote:
I want to get on with writing all the other documents like this one, but
I don't want the questions raised in this thread to go undocumented and
unanswered. I would *love* it if someone could volunteer to send me a patch
to the original document tightening it up in the
On Thu, Sep 06, 2001 at 10:46:56AM -0400, Ken Fox wrote:
Sure. I can do that while *waiting patiently* for Parrot to be
released. ;)
Don't tell Nat I said this, but we're hoping for around the
beginning of next week.
Simon
On 09/05/01 Nick Ing-Simmons wrote:
It's easier to generate code for a stack machine
True, but it is easier to generate FAST code for a register machine.
A stack machine forces a lot of book-keeping either run-time inc/dec of sp,
or alternatively compile-time what-is-offset-now stuff. The
On 09/05/01 Dan Sugalski wrote:
It's easier to generate code for a stack machine
So? Take a look at all the stack-based interpreters. I can name a bunch,
including perl. They're all slow. Some slower than others, and perl tends
to be the fastest of the bunch, but they're all slow.
Have a
Paolo Molaro wrote:
If anyone has any
evidence that coding a stack-based virtual machine or a register one
provides for better instructions scheduling in the dispatch code,
please step forward.
I think we're going to have some evidence in a few weeks. I'm not
sure which side the evidence is
On 09/05/01 Hong Zhang wrote:
I think we need to get some initial performance characteristics of register
machine vs stack machine before we go too far. There is not much points left
debating in email list.
Unfortunately getting meaningful figures is quite hard, there are
so many thing to
At 06:12 PM 9/6/2001 +0200, Paolo Molaro wrote:
On 09/05/01 Dan Sugalski wrote:
It's easier to generate code for a stack machine
So? Take a look at all the stack-based interpreters. I can name a bunch,
including perl. They're all slow. Some slower than others, and perl tends
to be the
(Firstly, I'd say trust Nick's expertise--he has spent a good-sized chunk
of his career doing software simulations of CPUs, and knows whereof he
speaks, both in terms of software running on hardware and software running
on software)
At 05:33 PM 9/6/2001 +0200, Paolo Molaro wrote:
I believe
At 06:12 PM 9/6/2001 +0200, Paolo Molaro wrote:
As I said in another mail, I think the stack-based approach will not
be necessarily faster, but it will allow more optimizations down the path.
It may well be 20 % slower in some cases when interpreted, but if it allows
me to easily JIT it and get
On 09/06/01 Dan Sugalski wrote:
Okay, I just did a test run, converting my sample program from interpreted
to compiled. (Hand-conversion, unfortunately, to C that went through GCC)
Went from 2.72M ops/sec to the equivalent of 22.5M ops/sec. And with -O3 on
it went to 120M ops/sec. The
At 09:11 PM 9/6/2001 +0200, Paolo Molaro wrote:
On 09/06/01 Dan Sugalski wrote:
The original mono interpreter (that didn't implement all the semantics
required by IL code that slow down interpretation) ran about 4 times
faster than perl/python on benchmarks dominated by branches, function
At 09:22 PM 9/6/2001 +0200, Paolo Molaro wrote:
A 10x slowdown on that kind of code is normal for an interpreter
(where 10x can range from 5x to 20x, depending on the semantics).
If we're in the normal range, then, I'm happy.
Well, until we get equivalent benchmarks for Mono, in which case I
On 09/06/01 Dan Sugalski wrote:
Then I'm impressed. I expect you've done some things that I haven't yet.
The only optimizations that interpreter had, were computed goto and
allocating the eval stack with alloca() instead of malloc().
Of course, now it's slower, because I implemented the full
On 09/04/01 Dan Sugalski wrote:
Regardless, it's the way we're going to go for now. If it turns out to be a
performance dog then we'll go with a stack-based system. Initial
indications look pretty good, though.
Care to share some numbers/code for that?
You're right that optimization
At 03:19 PM 9/5/2001 +0200, Paolo Molaro wrote:
On 09/04/01 Uri Guttman wrote:
does it really matter about comprehension? this is not going to be used
by the unwashed masses. a stack machine is easier to describe (hence all
the freshman CS projects :), but as dan has said, there isn't much
DS == Dan Sugalski [EMAIL PROTECTED] writes:
stack machine - post-order walk of the tree
reg machine - instruction selection - register allocation -
DS So what? That happens exactly once, in the compilation phase. Yes, it means
DS compilation will be somewhat slower, but not by
[I'm answering these out of order--sorry. Already answered elsewhere bits
snipped]
At 02:28 PM 9/5/2001 +0200, Paolo Molaro wrote:
On 09/04/01 Dan Sugalski wrote:
More on this point later in the mail.
There's a reason for that: register virtual machines are more complex
and more difficult
On 09/04/01 Uri Guttman wrote:
does it really matter about comprehension? this is not going to be used
by the unwashed masses. a stack machine is easier to describe (hence all
the freshman CS projects :), but as dan has said, there isn't much
mental difference if you have done any serious
True, but it is easier to generate FAST code for a register machine.
A stack machine forces a lot of book-keeping either run-time inc/dec of
sp,
or alternatively compile-time what-is-offset-now stuff. The latter is a
real
pain if you are trying to issue multiple instructions at once.
I
If you really want a comparison, here's one. Take this loop:
i = 0;
while (i 1000) {
i = i + 7;
}
with the ops executed in the loop marked with pipes. The corresponding
parrot code would be:
getaddr P0, i
store P0, 0
store I0,
At 11:17 AM 9/5/2001 -0700, Hong Zhang wrote:
Howerver, I like to point out one hidden overhead of register opcode is
decoding the parameter. The add instrction of stack machine does not have
args, but for register machine, it has 3 arguments.
I skipped the decoding step in the machine design on
On Mon, Sep 03, 2001 at 09:53:11PM -0400, Dan Sugalski wrote:
Might as well just promote the things to PMCs and pass in a list of them.
I anticipate that, especially for Perl, in a lot of cases we'll be dealing
with PMCs more often than the scalar data types.
Simon
Dan Sugalski [EMAIL PROTECTED] writes:
At 08:19 PM 9/3/2001 -0400, Sam Tregar wrote:
Speaking of soubroutines, what is Parrot's calling conventions? Obviously
we're no long in PUSH/POP land...
Up until now, I didn't know, so consider yourself the first to find out. :)
* Integer, String,
Simon Cozens:
# On Mon, Sep 03, 2001 at 04:05:26PM -0700, Brent Dax wrote:
# In other words, when you have sub foo {} in your code, it will be
# assigned an opcode number in the 'private' section. The
# global section
# is for things that are built-in to Parrot, while the
# private section is
On Mon, Sep 03, 2001 at 06:33:19PM -0400, Ken Fox wrote:
Thanks for the info. If you guys maintain this level of documentation
as the code develops, Perl 6 will be easy for first-timers to work on.
That's exactly the idea. :)
To be more specific about the software CPU, it will contain a
On Mon, Sep 03, 2001 at 04:05:26PM -0700, Brent Dax wrote:
In other words, when you have sub foo {} in your code, it will be
assigned an opcode number in the 'private' section. The global section
is for things that are built-in to Parrot, while the private section is
for stuff you write.
On Mon, Sep 03, 2001 at 08:19:32PM -0400, Sam Tregar wrote:
I'm still not sure I understand why Parrot is doing string ops at all. Do
all our target languages have identical semantics for string operations?
Nope. But that's OK, because they won't have identical vtables.
(The string vtable
On 09/02/01 Simon Cozens wrote:
=head1 The Software CPU
Like all interpreter systems of its kind, the Parrot interpreter is
a virtual machine; this is another way of saying that it is a software
CPU. However, unlike other VMs, the Parrot interpreter is designed to
more closely mirror
At 12:38 PM 9/4/2001 +0200, Paolo Molaro wrote:
I'm not convinced the register machine is the way to go.
Well, neither am I, and I came up with the plan.
Regardless, it's the way we're going to go for now. If it turns out to be a
performance dog then we'll go with a stack-based system. Initial
At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
* Methods get their parameters passed in as a list in
* PMC register 0, unless we can unambiguously figure
* out their prototype at
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
Will the subroutine know how it was called? (ie: Through method
dispatch or through straightforward symbol table lookup. I'm really
hoping the answer to this is 'yes'.) Or will methods
At 03:04 PM 9/4/2001 -0400, Uri Guttman wrote:
for sure. one case i saw recently in c.l.p.m was someone who wanted to
chain method calls together like this:
$obj-meth1()-meth2() ;
this is easy assuming you return the object in each method call. but he
ALSO wanted:
$bar =
On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
Can you see any use of a sub knowing it was called via a method call?
So that
At 09:06 AM 9/4/2001 +0100, Simon Cozens wrote:
On Mon, Sep 03, 2001 at 09:53:11PM -0400, Dan Sugalski wrote:
Might as well just promote the things to PMCs and pass in a list of them.
I anticipate that, especially for Perl, in a lot of cases we'll be dealing
with PMCs more often than the
At 08:05 PM 9/4/2001 +0100, Graham Barr wrote:
On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
Can you see any use of a sub
From: Graham Barr [mailto:[EMAIL PROTECTED]]
On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
Can you see any use of a sub
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS I don't buy that there's a higher bar on comprehension,
DS either. Register machines in general aren't anything at all
DS new. Granted, lots of folks grew up with the abomination that is
DS x86 assembly, if they even bothered hitting
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Ah. I've always wanted to do that with tied hashes. Okay, even
DS more reason to pass the data in! (We're going to end up with a
DS WANT register by the time we're done...)
that is not a bad idea. we could allocate a PMC register (e.g.
At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
* Methods get their parameters passed in as a list in PMC register 0,
* unless we can unambiguously figure out their prototype at
* compilation time
Will the subroutine know how it was called? (ie: Through method
dispatch or through
At 03:48 PM 9/4/2001 -0400, Uri Guttman wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Ah. I've always wanted to do that with tied hashes. Okay, even
DS more reason to pass the data in! (We're going to end up with a
DS WANT register by the time we're done...)
that is not a
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 03:48 PM 9/4/2001 -0400, Uri Guttman wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Ah. I've always wanted to do that with tied
hashes. Okay, even
DS more reason to pass the data in! (We're going to
end up with a
DS WANT
At 10:53 AM 9/4/2001 +0300, Ariel Scolnicov wrote:
What happens when I call a prototyped sub with a code ref?
We call the I've been called with a single list entry point. One that,
until recently, I hadn't planned on. :)
That, I expect, will extract the elements from the list into registers,
Here's the first of a bunch of things I'm writing which should give you
practical information to get you up to speed on what we're going to be doing
with Parrot so we can get you coding away. :) Think of them as having a
Apocalypse-Exegesis relationship to the PDDs.
I haven't yet finished
On Sun, 2 Sep 2001, Simon Cozens wrote:
For instance, the Parrot VM will have a register architecture, rather
than a stack architecture. It will also have extremely low-level
operations, more similar to Java's than the medium-level ops of Perl and
Python and the like.
For those of you
Simon Cozens [EMAIL PROTECTED] wrote:
Firstly, a magic number is presented to identify the bytecode file as
Parrot code.
Hopefully this is followed by a header that has a version number and
lots of useful stuff like flags and offsets and things, just like wot
real object files have :-)
Next
KF == Ken Fox [EMAIL PROTECTED] writes:
KF Simon Cozens wrote:
To be more specific about the software CPU, it will contain a large
number of registers.
KF The register frames store values, not pointers to values? If
KF there's another level of indirection with registers, I'm not
On Sun, 2 Sep 2001, Simon Cozens wrote:
For instance, the Parrot VM will have a register architecture, rather
than a stack architecture.
s/rather than/as well as/; # we've got a stack of register frames, right?
There will be global and private opcode tables; that is to say, an area
of the
Note: this is my understanding of the situation; I could be wrong.
Sam Tregar:
# On Sun, 2 Sep 2001, Simon Cozens wrote:
#
# For instance, the Parrot VM will have a register
# architecture, rather
# than a stack architecture.
#
# s/rather than/as well as/; # we've got a stack of register
#
At 06:37 PM 9/3/2001 -0400, Sam Tregar wrote:
On Sun, 2 Sep 2001, Simon Cozens wrote:
For instance, the Parrot VM will have a register architecture, rather
than a stack architecture.
s/rather than/as well as/; # we've got a stack of register frames, right?
Well, register in the sense that
Sam Tregar writes:
If our PMC is a string and has a vtable which implements Perl-like
string operations, this will return the length of the string. If, on the
other hand, the PMC is an array, we might get back the number of
elements in the array. (If that's what we want it to do.)
Ok,
Dan Sugalski wrote:
For those of you worrying that parrot will be *just* low-level ops,
don't. There will be medium and high level ops in the set as well.
I was going to cite http://citeseer.nj.nec.com/romer96structure.html,
but you guys have already read that, eh? ;)
One thing I was
Thanks for the info. If you guys maintain this level of documentation
as the code develops, Perl 6 will be easy for first-timers to work on.
One goal down, N-1 to go... ;)
Simon Cozens wrote:
To be more specific about the software CPU, it will contain a large
number of registers.
The register
On Monday 03 September 2001 08:06 pm, Sam Tregar wrote:
I think I understand this. What I don't understand is how this relates to
the next section about Parrot's special relationship with strings. If
Parrot has a string type and string handling functions, why use a PMC
to implement a
On Mon, 3 Sep 2001, Dan Sugalski wrote:
Basically chunks of perl code can define opcodes on the fly--they might be
perl subs that meet the proper critera, or opcode functions defined by C
code with magic stuck in the parser, or wacky optimizer extensions or
whatever. There won't be a single
At 08:19 PM 9/3/2001 -0400, Sam Tregar wrote:
On Mon, 3 Sep 2001, Dan Sugalski wrote:
Basically chunks of perl code can define opcodes on the fly--they might be
perl subs that meet the proper critera, or opcode functions defined by C
code with magic stuck in the parser, or wacky optimizer
On Mon, 3 Sep 2001, Dan Sugalski wrote:
avoid using a call opcode all over the place, right?
No, more a try and leave the bytecode sections read-only hack.
Imagine, if you will, building LWP and bytecode compiling it. It uses
private opcodes 1024-1160. Then you later build, say,
At 09:26 PM 9/3/2001 -0400, Sam Tregar wrote:
On Mon, 3 Sep 2001, Dan Sugalski wrote:
avoid using a call opcode all over the place, right?
No, more a try and leave the bytecode sections read-only hack.
Imagine, if you will, building LWP and bytecode compiling it. It uses
private
On Mon, 3 Sep 2001, Dan Sugalski wrote:
I'm not entirely sure how much this'll be used, but I really, *really* want
to be able to call any sub that qualifies as an op rather than as a sub.
What would a sub have to do (be?) to qualify?
I don't understand this restriction. Won't it make
At 09:41 PM 9/3/2001 -0400, Sam Tregar wrote:
On Mon, 3 Sep 2001, Dan Sugalski wrote:
I'm not entirely sure how much this'll be used, but I really, *really* want
to be able to call any sub that qualifies as an op rather than as a sub.
What would a sub have to do (be?) to qualify?
It'd have
On Mon, 3 Sep 2001, Nathan Torkington wrote:
Ok, so one example of a PMC is a Perl string...
If you grok vtables, think of a PMC as the thing a vtable hangs off.
Another way to think of it is that a PMC is an object. To the outside
(the interpreter that is manipulating data values) its
BD == Brent Dax [EMAIL PROTECTED] writes:
BD # s/rather than/as well as/; # we've got a stack of register
BD # frames, right?
BD IIRC, that's mostly for when we run out of registers or we're changing
BD scopes or whatever. For the most part, it's a register architecture.
as dan has
ST == Sam Tregar [EMAIL PROTECTED] writes:
* Integer, String, and Number registers 0-x are used to pass parameters
when the compiler calls routines.
ST s/compiler/interpreter/, right?
nope. he means when the compiler generates op codes. the compiler will
generate code to put the op
71 matches
Mail list logo
