Okay, I need to prefix this with a public apology. My initial reply was
cranky and unprofessional
At 01:48 AM 10/8/2001 +0530, V Vinay wrote:
>Dear Dan,
>
>You are doing a wonderful job and my intension is not to pass judgements on
>any one's technical abilities on this list. We have a bunch of
[This is short, since it's a bit late for me. A full, non-cranky,
response'll come tomorrow]
On Mon, 8 Oct 2001, V Vinay wrote:
> It is reasonable to expect these two quantities to be within a factor of 2
> or thereabouts. This measure directly says something about the quality
> of the instruct
Dear Dan,
You are doing a wonderful job and my intension is not to pass judgements on
any one's technical abilities on this list. We have a bunch of very
talented people here that would be difficult to match in any other group.
:> The interpreter is way too slow and we all admit to that.
:
:No,
Dear Simon,
:On Sun, Oct 07, 2001 at 01:05:57PM +0530, V Vinay wrote:
:> This is my first mail to the list; I am a compulational complexity theorist
:
:Aaah, theorists... :)
Am Doomed, ain't I :)
:> (It is not ansi C complaint: it works on any gcc port however.
:
:The entire point of Parrot
On Sunday 07 October 2001 12:24 pm, Brent Dax wrote:
> If GCC has this great feature, maybe we should use it if the compiler is
> GCC and fall back to something else otherwise. It's not gonnna hurt on
> other compilers, and it could help significantly on GCC.
I'm already assuming that we will ha
Simon Cozens:
# On Sun, Oct 07, 2001 at 01:05:57PM +0530, V Vinay wrote:
# > This is my first mail to the list; I am a compulational
# complexity theorist
#
# Aaah, theorists... :)
#
# > (It is not ansi C complaint: it works on any gcc port however.
#
# The entire point of Parrot 0.0.2 was to remi
On Sun, 7 Oct 2001, V Vinay wrote:
> I do not understand all the
> issues thought I have sampled the discussion over the last six months.
You may need to go back further, then.
> The interpreter is way too slow and we all admit to that.
No, we don't, actually. The benchmarks show us running ar
On Sun, Oct 07, 2001 at 01:05:57PM +0530, V Vinay wrote:
> This is my first mail to the list; I am a compulational complexity theorist
Aaah, theorists... :)
> (It is not ansi C complaint: it works on any gcc port however.
The entire point of Parrot 0.0.2 was to remind developers that the world
This is my first mail to the list; I am a compulational complexity theorist
(yes, NP - Completeness and such things :) and immensely enjoy perl
programming. I have been following parrot for the last two weeks and felt
compelled to join the discussions yesterday. I do not understand all the
issues
I tried removing the bounds checking and adding multiple DO_OPs inside the
while loop. with -O0 the loop unrolling helped, but removing the bounds
checking actually slowed it down. With -O3, neither one helped at all.
On Saturday 06 October 2001 09:07 pm, Gregor N. Purdy wrote:
> > But before we going jumping the gun, let's see what straight registers
> > do. {dum de dum de dum...} Runs about the same for me. (A shade slower
> > on Linux.)
>
> Could you elaborate on this statement please? I'm not sure I follow
Bryan --
> ... But you did bring up one thing - you don't get a
> copy of the registers when you push. That makes it nigh impossible to pass
> values in the registers when you need to save the registers off. Dan?)
This is the part about the current design I have a hard time
understanding. T
On Saturday 06 October 2001 08:05 pm, Buggs wrote:
> On Sunday 07 October 2001 01:16, Bryan C. Warnock wrote:
> [...]
>
> > One of the more interesting discoveries? Adding a 'default:' case to
> > the switch slowed down the Linux runs by several percent.
>
> In that, umh, case: do you have an exp
On Saturday 06 October 2001 07:43 pm, Gregor N. Purdy wrote:
> The Crystalizing Loader proposal I just made would work better if the
> addresses to the current registers were always the same and pushing
> regs onto stacks made copies, rather than having the current reg file
> be the new set of reg
On Sunday 07 October 2001 01:16, Bryan C. Warnock wrote:
[...]
> One of the more interesting discoveries? Adding a 'default:' case to the
> switch slowed down the Linux runs by several percent.
In that, umh, case: do you have an explanation
or could you provide the code?
Buggs
Bryan --
> > 4) Accessing the necessary registers as current written (from the
> > interpreter struct.)
>
> The added benchmarks are the caching of the interpreter's register groups
> within the runops_*_core. (You can't cache the register set itself, as
> functions may manipulate the register
On Saturday 06 October 2001 06:38 pm, Bryan C. Warnock wrote:
> 4) Accessing the necessary registers as current written (from the
> interpreter struct.)
The added benchmarks are the caching of the interpreter's register groups
within the runops_*_core. (You can't cache the register set itself, a
1) Assuming a core set of unoverrideable opcodes 0-128 (so I don't need to
differentiate between core and alternate opcodes.)
2) Maintaining each operation as a block (so that any necessary variables
are declared locally to each case.)
3) Incrementing the pc pointer directly.
4) Accessing the ne
On Oct 06, Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> took up a
keyboard and banged out
> I think that changing from a function based implementation to a switch
> based
> implementation will help on many platforms. Someone did a patch on
> that,
> maybe we could update it and commit it.
I'll r
At 05:46 PM 10/6/2001 +0200, Paolo Molaro wrote:
>I get about the same number for Parrot on my K6-400, but
>compiling with -O2 gets it up to 11,500,000, so maybe your forgot
>to use -O2 or it may be the laptop in power-saving mode:-)
>The current mono interp can do at least twice that many ops
>us
At 11:36 AM 10/6/2001 -0400, Bryan C. Warnock wrote:
>On Saturday 06 October 2001 10:58 am, Dan Sugalski wrote:
> >
> > It's the function pointer indirection, to some extent. The switch dispatch
> > loop should help some. Also I don't think you should make too many
> > performance comparisons unti
On 10/06/01 Simon Cozens wrote:
> On Sat, Oct 06, 2001 at 12:44:59AM -0400, Bryan C. Warnock wrote:
> > Ops/sec:31,716,577.291820
>
> Wowsers. What are you running that thing on?
>
> For comparison, on this machine:
> Parrot Ops/sec: 500.00
> Python2 ops/sec: 3289276.607351
> (Python 1
On Saturday 06 October 2001 10:58 am, Dan Sugalski wrote:
>
> It's the function pointer indirection, to some extent. The switch dispatch
> loop should help some. Also I don't think you should make too many
> performance comparisons until we've got something equivalent to compare
> with.
Unless we
At 03:18 PM 10/6/2001 +0100, Simon Cozens wrote:
>On Sat, Oct 06, 2001 at 12:44:59AM -0400, Bryan C. Warnock wrote:
> > Ops/sec:31,716,577.291820
>
>Wowsers. What are you running that thing on?
>
>For comparison, on this machine:
>Parrot Ops/sec: 500.00
>Python2 ops/sec: 3289276.607351
>(
On Sat, Oct 06, 2001 at 12:44:59AM -0400, Bryan C. Warnock wrote:
> Ops/sec:31,716,577.291820
Wowsers. What are you running that thing on?
For comparison, on this machine:
Parrot Ops/sec: 500.00
Python2 ops/sec: 3289276.607351
(Python 1 is slightly faster - at the moment.)
That's not f
On Saturday 06 October 2001 02:04 am, Gibbs Tanton - tgibbs wrote:
> I think that changing from a function based implementation to a switch
> based implementation will help on many platforms. Someone did a patch on
> that, maybe we could update it and commit it. Having to go through two
> indire
much too
slowly.
Tanton
-Original Message-
From: Bryan C. Warnock
To: [EMAIL PROTECTED]
Sent: 10/5/2001 11:44 PM
Subject: More speed trials
Holding steady.
As a lark, I wrote the functionality of test.pasm (the time test) in
Perl,
and ran it under 5.6.1. (Keep it mind, you've got v
Holding steady.
As a lark, I wrote the functionality of test.pasm (the time test) in Perl,
and ran it under 5.6.1. (Keep it mind, you've got variables that you're
fetching and storing to.)
Parrot Assembler (with the time_n patch, since the elapsed time is so small.
The comma delimeters are
Holding steady since last report.
--
Bryan C. Warnock
[EMAIL PROTECTED]
29 matches
Mail list logo
