Interesting stuff for Python, is any work like this being done in Ruby?
http://psyco.sourceforge.net/introduction.html
Jim Moy
Impressive !
They could produce better code (less memory overhead) if Python’s
syntax was expanded so that user could provide “hints” about what
deserves to be optimized. Today they suggest profiling as an
heuristic.
There was a time when C compilers had #pragma register, whereby
users worried about speed could help the compiler produce faster
code (when you need speed, you need it hard).
Better have some user directed optimizations than nothing.
Jean-Hugues
···
At 06:07 24/04/2004 +0900, you wrote:
Interesting stuff for Python, is any work like this being done in Ruby?
Psyco - Introduction
Jim Moy
Jean-Hugues ROBERT wrote:
Interesting stuff for Python, is any work like this being done in Ruby?
Psyco - Introduction
Jim MoyImpressive !
They could produce better code (less memory overhead) if Python’s
syntax was expanded so that user could provide “hints” about what
deserves to be optimized. Today they suggest profiling as an
heuristic.There was a time when C compilers had #pragma register, whereby
users worried about speed could help the compiler produce faster
code (when you need speed, you need it hard).Better have some user directed optimizations than nothing.
Maybe, but first you should do static type inference as much as you can,
see
http://www.python.org/pycon/dc2004/papers/1/paper.pdf
and if you then want to give hints there is no need to extend the
syntax; simply add a private method on Module for attaching type hints
to methods etc. I think the StarKiller has some kind of type annotation
language like that.
But speed may not be very important anyway… 
Regards,
Robert
···
At 06:07 24/04/2004 +0900, you wrote:
Hello Robert,
Saturday, April 24, 2004, 2:36:39 AM, you wrote:
Jean-Hugues ROBERT wrote:
Interesting stuff for Python, is any work like this being done in Ruby?
Psyco - Introduction
Jim MoyImpressive !
They could produce better code (less memory overhead) if Python’s
syntax was expanded so that user could provide “hints” about what
deserves to be optimized. Today they suggest profiling as an
heuristic.There was a time when C compilers had #pragma register, whereby
users worried about speed could help the compiler produce faster
code (when you need speed, you need it hard).Better have some user directed optimizations than nothing.
Maybe, but first you should do static type inference as much as you can,
see
and if you then want to give hints there is no need to extend the
syntax; simply add a private method on Module for attaching type hints
to methods etc. I think the StarKiller has some kind of type annotation
language like that.
You must use some compiler/interpreter internals and only if it is to
ignore the type assertation without additional overhead.
But speed may not be very important anyway…
It is only important for 75% of all projects.
···
At 06:07 24/04/2004 +0900, you wrote:
–
Best regards,
Lothar mailto:mailinglists@scriptolutions.com
Jean-Hugues ROBERT wrote:
Interesting stuff for Python, is any work like this being done in Ruby?
Psyco - Introduction
Jim MoyImpressive !
They could produce better code (less memory overhead) if Python’s
syntax was expanded so that user could provide “hints” about what
deserves to be optimized. Today they suggest profiling as an
heuristic.There was a time when C compilers had #pragma register, whereby
users worried about speed could help the compiler produce faster
code (when you need speed, you need it hard).Better have some user directed optimizations than nothing.
Maybe, but first you should do static type inference as much as you can, see
static type inference is great, no doubt about that, this is the way to go.
However, it may take a while until something like that is available.
Ruby is not the easiest language from the point of view of a type
inference scheme implementor. I believe there is currently more energy
spent on implementing a VM for Ruby then on any type inference solution.
So, in the mean time, I believe the end user may be willing to
spend some energy to get more speed (well… maybe not to the point
where you start considering C).
Analogy:
For sure, nowadays C optimizing compilers do a great job and
it is rare that you have to resort to “register” (which is not a #pragma,
sorry for my distorted memory) anymore. Yet, at its time, register
helped.
MinMax strategy: Minimize work for Ruby implementors, Maximize
user profit. In a perfect world, only implementors would work,
in today’s world, users’ skills could legitimately be leveraged.
http://www.python.org/pycon/dc2004/papers/1/paper.pdf
and if you then want to give hints there is no need to extend the syntax;
simply add a private method on Module for attaching type hints to methods
etc. I think the StarKiller has some kind of type annotation language like
that.
Nice !
I guess my notion of “hints” is aimed at the same goal as type
annotation language of StarKiller. However, for locality of
concerns purposes, I prefer the annotation to be in-lined versus
separated. It makes the result easier to read/modify I believe.
I believe that a syntax oriented solution is often
better looking and is worth the effort for frequent constructions.
As an example, think about the attr() method family. It is great,
for sure. Yet attr :myAttr is kind of surprising for a newbie, attr myAttr
would seem more direct (of course, once you understand that attr: is just
another method and that you may have your own variations of it… you
love that !).
The ultimate would probably be a compiler with a customizable syntax.
I mean, if I could change Smalltalk’s syntax, I would use Smalltalk.
I would make it look like Ruby of course
But speed may not be very important anyway…
I suppose that I would be using C++ if it were 
The Psyco motto is that “higher level languages should actually
outperform lower level ones in terms of speed”. I totally agree with
that statement, but I am slightly impatient.
BTW: Any one knows about some Ruby API to walk the Ruby compiler’s
AST ? (I had a look at node.h and for sure such an API could exist).
Jean-Hugues
···
At 09:36 24/04/2004 +0900, you wrote:
At 06:07 24/04/2004 +0900, you wrote:
For sure, nowadays C optimizing compilers do a great job and
it is rare that you have to resort to “register” (which is not a #pragma,
sorry for my distorted memory) anymore. Yet, at its time, register
helped.
Yes, I believe gcc even just ignores any ‘register’ you specify,
because it can find a better solution than you anyway.
MinMax strategy: Minimize work for Ruby implementors, Maximize
user profit. In a perfect world, only implementors would work,
in today’s world, users’ skills could legitimately be leveraged.
That’s the way it should be (sorry Matz!). If Ruby would be
much faster, it could be used for more tasks, and take away
more time from programmers. And they wouldn’t have to think
about performance to much.
I believe that a syntax oriented solution is often
better looking and is worth the effort for frequent constructions.
I don’t believe that Ruby syntax should be poluted with type
information (public static Numeric inline parm … ew!). It
would be great to have a new language resembling Ruby that
would contain some static information (and sacrifice dynamism),
but could be compiled into machine code (cRuby?).
A good way to speed up Ruby’s method calling would be to
cache Class-information. It should cache only one value,
because mostly methods are called on the same class,
except the generic ones (like each, etc…). If it finds
the same class, it could directly call the associated method,
(with a dirty bit, if the method was changed recently). Otherwise
it would look up the method.
As an example, think about the attr() method family. It is great,
for sure. Yet attr :myAttr is kind of surprising for a newbie, attr myAttr
would seem more direct (of course, once you understand that attr: is just
another method and that you may have your own variations of it… you
love that !).
I remember finding it strange when I started learning Ruby, but
when you learn something new, you just accept some facts, and later
learn why they are like that. And Ruby is remarkably consistent,
it keeps surprising me every time!
But speed may not be very important anyway…
I suppose that I would be using C++ if it were
What about Objective-C? The Object model of Objective-C resembles
that of small-talk and Ruby, and is far more dynamic than C++.
It is a shame that it is used so little, instead of C++.
(is that because it is an Apple-thing?)
The Psyco motto is that “higher level languages should actually
outperform lower level ones in terms of speed”. I totally agree with
that statement, but I am slightly impatient.
Me too. When you express something very clearly, the compiler
should be able to find the fastest solution for you. But this
“super-compiler” still doesn’t exist (or does it?).
···
On Sat, 24 Apr 2004 16:27:58 +0900, Jean-Hugues ROBERT wrote:
The ultimate would probably be a compiler with a customizable syntax.
I mean, if I could change Smalltalk’s syntax, I would use Smalltalk.
I would make it look like Ruby of course
I believe you want the Agile Object System from the SmallScript/S#
guys
http://www.smallscript.com
I believe nodedump and nodewrap may be useful for you?
Or just use ripper, it has a sax-like event driven interface, and It
would be nice to see more people using it and helping it to mature
···
il Sat, 24 Apr 2004 16:27:58 +0900, Jean-Hugues ROBERT jean_hugues_robert@yahoo.com ha scritto::
A good way to speed up Ruby's method calling would be to
cache Class-information. It should cache only one value,
because mostly methods are called on the same class,
except the generic ones (like each, etc..). If it finds
the same class, it could directly call the associated method,
(with a dirty bit, if the method was changed recently). Otherwise
it would look up the method.
What do you think that ruby do actually ?
svg% fgrep cache? eval.c
/* is it in the method cache? */
/* is it in the method cache? */
svg%
Guy Decoux
It takes some courage to figure out what this is about.
What makes you feel this is what I want ? I have a hard time
understanding how Smallscript could let me redefine its syntax
to make it look like ruby’s one.
As a side note, besides the total lack of documentation, this is
an impressive piece of work.
I wonder how much work that would be to generate Smallscript
code from Ruby’s AST (using nodedump or Guy Decoux’s fl_ii) ???
The impedance mismatch between Ruby and Smallscript seems rather
small (syntax put aside).
Thanks for the links.
Jean-Hugues
···
At 21:29 24/04/2004 +0900, Garbriel wrote:
il Sat, 24 Apr 2004 16:27:58 +0900, Jean-Hugues ROBERT
The ultimate would probably be a compiler with a customizable syntax.
I mean, if I could change Smalltalk’s syntax, I would use Smalltalk.
I would make it look like Ruby of course
I believe you want the Agile Object System from the SmallScript/S#
guys
http://www.smallscript.com
I meant caching at the point of invokation.
Is this the way it is actually done in Ruby?
···
On Sun, 25 Apr 2004 00:32:34 +0900, ts wrote:
A good way to speed up Ruby’s method calling would be to
cache Class-information. It should cache only one value,
because mostly methods are called on the same class,
except the generic ones (like each, etc…). If it finds
the same class, it could directly call the associated method,
(with a dirty bit, if the method was changed recently). Otherwise
it would look up the method.What do you think that ruby do actually ?
svg% fgrep cache? eval.c
/* is it in the method cache? /
/ is it in the method cache? */
svg%
Jean-Hugues ROBERT wrote:
il Sat, 24 Apr 2004 16:27:58 +0900, Jean-Hugues ROBERT
The ultimate would probably be a compiler with a customizable syntax.
I mean, if I could change Smalltalk’s syntax, I would use Smalltalk.
I would make it look like Ruby of courseI believe you want the Agile Object System from the SmallScript/S#
guys
http://www.smallscript.comIt takes some courage to figure out what this is about.
What makes you feel this is what I want ? I have a hard time
understanding how Smallscript could let me redefine its syntax
to make it look like ruby’s one.As a side note, besides the total lack of documentation, this is
an impressive piece of work.
Agreed.
I wonder how much work that would be to generate Smallscript
code from Ruby’s AST (using nodedump or Guy Decoux’s fl_ii) ???
The impedance mismatch between Ruby and Smallscript seems rather
small (syntax put aside).
It is small but there might be licensing troubles. It was also a long
time since it was updated…
Regards,
Robert
···
At 21:29 24/04/2004 +0900, Garbriel wrote:
I meant to say that this is a system/platform that gives you all the
basics to let you build ruby on top of it with little effort.
Yeah, I don’t think you can put a simple parse.y in it and get out a
ruby implementation
But it should be quite easy to show ruby working over AOS, given that
most every ruby feature is found in it
···
il Sun, 25 Apr 2004 02:56:47 +0900, Jean-Hugues ROBERT jean_hugues_robert@yahoo.com ha scritto::
At 21:29 24/04/2004 +0900, Garbriel wrote:
I believe you want the Agile Object System from the SmallScript/S#
guys
http://www.smallscript.comIt takes some courage to figure out what this is about.
What makes you feel this is what I want ? I have a hard time
understanding how Smallscript could let me redefine its syntax
to make it look like ruby’s one.
Is this the way it is actually done in Ruby?
When ruby find a method, after a lookup, it store it in the cache. When it
need to call a method, it first look in the cache if it's not found it
make a lookup to find the method.
The entries in the cache can be invalided when there is a modification (by
id, by class, or global undef)
A better description is given in eval.c (warning it's written in C not in
English :-))
Guy Decoux
I meant to say that this is a system/platform that gives you all the
basics to let you build ruby on top of it with little effort.Yeah, I don’t think you can put a simple parse.y in it and get out a
ruby implementationBut it should be quite easy to show ruby working over AOS, given that
most every ruby feature is found in it
I agree with this; I was very into this at one point and talked to David
about it. However, I feel a bit unsure about his licensing, where he is
taking the project and when a 1.0 release will come out. Seems he has no
plans to release the source for the VM. Thus I think CLR (MS and/or
Mono), Parrot, pure-assembler (or of course Rite) are currently the most
promising “back-ends” for Ruby.
Regards,
Robert