Someday we will set aside our optimization focus.
Our architectural validation probe will be complete.
We will have established that yes, the parrot design
can support the required speed.  Further optimization
will be seen as premature optimization. Our focus will
shift to making parrot actually work. To giving it
working exceptions, io, embeddablility, and so on.
To making parrot a platform which language implementers
can seriously target.

Just a thought.

Given Leo's numbers, it seemed a possibility worth suggesting.

I can certainly imagine other policies.  Like focusing on performance
and using it to drive interest and obtain additional people to get
things working.  But we should be clear on what we are doing.

Mitchell

Mitchell N Charity <mchar...@vendian.org> wrote:

Well, making it work and making it work correctly is of course one of
the major goals, or the primary goal. But sometimes I just don't know
yet, how it should really work, like the whole experimental code from
events over exceptions to threads. Or the current discussion WRT
Continuation. No one did answer til now, how they should really work.

OTOH: We have CPS subroutines since almost a year. Performance sucked
until today (s. fib.* benchmarks, which are plain function calls). If
Parrot's function (or method) calls are 2-3 times slower then any other
interpreter, no one will have much interest to use Parrot. Not even me.

Some optimizations might be premature but I think that some are just
necessary to create interest that makes the project keep running.

And one final note: It's of course a lot of fun to speed things up
considerably.

leo

If we never optimize, we won't have the speed to run real-world
programs.  But if all we do is optimize, we won't have the features to
run real-world programs.

Programming, like all things, is a balance.  Has Parrot found that
balance?  Probably not.  I agree that we do focus too much on
optimization now and then, leaving us with things like the COW system
(clever, but tricky, and so pervasive) that are hard to maintain and
easy to trip over.  Other times, we add lots of new features, and then
stop to test them and find they're incredibly slow.  (That's objects
right now.)

But keep in mind that, if we don't optimize at all, we would end up with
an interpreter nobody wanted to use.  And at *that* point, the
incredible slowness of the interpreter would be overwhelming, and nobody
would want to try to optimize it.

Just a thought.

--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

Oceania has always been at war with Eastasia.

Brent 'Dax' Royal-Gordon <br...@brentdax.com> writes:

In objects' defence, I'd just like to say that they are rather lovely.

At 12:13 PM -0500 3/21/04, Mitchell N Charity wrote:

Optimization, in and of itself, is rarely a bad thing. That whole
'premature optimization' quote gets slung around and like so many
other aphorisms it's almost correct. (The quote ought to be
"inappropriate optimization is the root of all evil" but
inappropriate's a much fuzzier word than premature, though premature
itself is hard to gague)

As far as I'm concerned, people are welcome to dig in and optimize
the heck out of code, with the caveat that they don't make a mess.
That is, APIs should be respected, and the code in question should be
replaceable. Optimizing data structures is a trickier thing, and for
that I'd prefer more discussion before things are done, as exposed
structures are more difficult to change later. Code, structures, and
API in that order for what's acceptable.

Besides, like it or not, programmers like to fiddle. Better to have
an approved place than not...
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk