J
Jim Moy
Interesting stuff for Python, is any work like this being done in Ruby?
http://psyco.sourceforge.net/introduction.html
Jim Moy
http://psyco.sourceforge.net/introduction.html
Jim Moy
J
Jean-Hugues ROBERT
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
R
Robert Feldt
Maybe, but first you should do static type inference as much as you can,Jean-Hugues ROBERT said:
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
L
Lothar Scholz
Hello Robert,
Saturday, April 24, 2004, 2:36:39 AM, you wrote:
RF> Maybe, but first you should do static type inference as much as you can,
RF> see
RF> http://www.python.org/pycon/dc2004/papers/1/paper.pdf
RF> and if you then want to give hints there is no need to extend the
RF> syntax; simply add a private method on Module for attaching type hints
RF> to methods etc. I think the StarKiller has some kind of type annotation
RF> language like that.
You must use some compiler/interpreter internals and only if it is to
ignore the type assertation without additional overhead.
RF> But speed may not be very important anyway...
It is only important for 75% of all projects.
Saturday, April 24, 2004, 2:36:39 AM, you wrote:
RF> Maybe, but first you should do static type inference as much as you can,
RF> see
RF> http://www.python.org/pycon/dc2004/papers/1/paper.pdf
RF> and if you then want to give hints there is no need to extend the
RF> syntax; simply add a private method on Module for attaching type hints
RF> to methods etc. I think the StarKiller has some kind of type annotation
RF> language like that.
You must use some compiler/interpreter internals and only if it is to
ignore the type assertation without additional overhead.
RF> But speed may not be very important anyway...
It is only important for 75% of all projects.
J
Jean-Hugues ROBERT
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.
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
K
Kristof Bastiaensen
Yes, I believe gcc even just ignores any 'register' you specify,
because it can find a better solution than you anyway.
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 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.
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!
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?)
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?).
G
gabriele renzi
il Sat, 24 Apr 2004 16:27:58 +0900, Jean-Hugues ROBERT
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
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
T
ts
K> A good way to speed up Ruby's method calling would be to
K> cache Class-information. It should cache only one value,
K> because mostly methods are called on the same class,
K> except the generic ones (like each, etc..). If it finds
K> the same class, it could directly call the associated method,
K> (with a dirty bit, if the method was changed recently). Otherwise
K> 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
K> cache Class-information. It should cache only one value,
K> because mostly methods are called on the same class,
K> except the generic ones (like each, etc..). If it finds
K> the same class, it could directly call the associated method,
K> (with a dirty bit, if the method was changed recently). Otherwise
K> 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
J
Jean-Hugues ROBERT
il Sat, 24 Apr 2004 16:27:58 +0900, Jean-Hugues ROBERT
I believe you want the Agile Object System from the SmallScript/S#
guys
http://www.smallscript.com
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
K
Kristof Bastiaensen
I meant caching at the point of invokation.
Is this the way it is actually done in Ruby?
R
Robert Feldt
It is small but there might be licensing troubles. It was also a longJean-Hugues ROBERT said:
time since it was updated...
Regards,
Robert
T
ts
K> 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
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
G
gabriele renzi
il Sun, 25 Apr 2004 02:56:47 +0900, Jean-Hugues ROBERT
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
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
R
Robert Feldt
I agree with this; I was very into this at one point and talked to DavidI 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
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