« Return to Thread: Groovy performance: what to do
Re: Groovy performance: what to do
by glaforge
::
Rate this Message:
This is an interesting experiment.
You've done a great work so far on improving the performance of
Groovy, and Groovy 1.6 will bring Groovy ahead of the pack as the most
performant dynamic language for the JVM.
Congratulations for this work.
However, as this has been discussed on this list a few times already
or at the last Groovy Developer Conference, it's better and saner to
make Groovy the fastest dynamic language possible on the JVM by
creating the best second generation MOP, rather than by adding a few
hacks to make Groovy a more statically typed language.
What would happen if such a proposal was committed?
In a few months from now, all Groovy code samples we would come across
would be littered with @Typed annotations all around -- who remembers
the ugly @Property annotation making your Groovy beans ugly?
A few months later, and people will wonder why this is not the default
behavior and be applied to all possible methods or classes.
Groovy will become more and more statically typed, and for
"performance sake", we'd imagine other such hacks to make Groovy less
and less dynamic over time, or littered with ugly annotations.
Such a proposal would be a consent that we failed to make Groovy the
fastest dynamic language possible.
Have we really tried to make Groovy as fast as possible? Have we
implemented a second generation MOP yet? No.
Furthermore, even with such an annotation, this code path would always
be slower than raw Java anyway.
Remember that Groovy has not been conceived to replace Java, but as a
complement, an adjunct, an enhancer to Java.
It's a core value of the language and the project.
With the joint compiler, the ant tasks, the maven plugin, it's so easy
to just implement one additional Java class, that it is totally
seamless and transparent to mix Groovy and Java together.
When raw performance matter, using Java is simply the best option, and
nothing we could do would make the code faster than raw Java.
It doesn't mean that Groovy can't be made more performant than it is
today, on the contrary, it's time to work on MOP2 instead. So you can
focus your energy on something less frustrating if you so wish.
As discussed several times already, we should focus now on this new
Meta-Object Protocol, perhaps to make Groovy even more dynamic, but to
make it the faster possible dynamic language across all possible
platforms -- it's not an unrealistic goal to be faster than Ruby and
Python.
John Wilson and his experiments prove that even without call site
caching and similar techniques, we can be even more performant than we
are today with all these techniques applied. The Jython and JRuby
guys, as well as the guys on the JVM language list prove us that there
are better ways too.
If ever we recognize that this new architecture is a failure, we don't
even need to implement such annotation trick, as the simplest possible
way to make the code as performant as possible is to just implement a
few lines of Java code to make the overal performance right so that
all possible projects meet the expected stricter SLAs.
So, thanks a lot for this suggestion and experiment, but I think it's
not the right direction to take in terms of performance improvements,
but rather it's time we spend our time and energy on designing the
next generation dynamic system for Groovy.
On Tue, Feb 19, 2008 at 11:10 AM, Alex Tkachman <alex.tkachman@...> wrote:
> Hi Groovy Developers!
>
> As many of you know I spent almost last 8 months (since July) working
> mostly on different aspects of Groovy performance. And results so far
> are very good - each new version are noticeably faster then previous
> one.
>
> But you know what - I feel myself like an idiot.
>
> The problem we try to solve can be formulated very simply
> - we have piece of code, which is effectlvely statically typed (either
> typed already or can become typed without to much problems for
> developer because he knows that nothing dynamic is involved)
> - we forget almost all we know about types during compilation because
> we assume that everything can be dynamicly changed at any momemt
> - we try to achieve same performance as Java has by doing amounts of
> very complicated tricks on runtime
>
> After 4th attempt to rewrite call sites optimization and avoid some
> very tricky bugs with EMC and categories on multi-threading I felt
> that it is not the best way to spend my life.
>
> At this point I remind myself well-known rule that 95% of performance
> problems come from 5% of code. Well, we can argue about exact figures
> - some people say 99-1, some 90-10, some 80-20 and I my personal
> experience during many years is 95-5 but I don't think it is really
> matter.
>
> What is really matter is that instead of runtime optimizing everything
> without help of developer I (as developer) would prefer to help
> compiler to optimize 5% of code, which is performance critical for me.
>
> So I did simple experiment
> - I introduced annotation
>
> @Retention(RetentionPolicy.SOURCE)
> @Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
> public @interface Typed {
> public enum TypePolicy {
> Dynamicly, // traditional Groovy, no resolve
> Strictly, // traditional Java, full resolve required
> SemiStrictly // resolve and call statically what you can
> and call the rest dynamically
> }
>
> TypePolicy value () default TypePolicy.Strictly;
> }
>
> - I prototyped compiler modification to use for static resolve (for
> Strictly and SemiStrictly) both type information, DGM methods and
> categories in use
> - I prototyped work with primitives for Strictly and SemiStrictly
>
> - I experimented with just one script spectralnorm, which is my huge
> headache last weeks and which is much much slower then Java
> counterpart.
>
> - By annotating just one method with @Typed it becomes only twice
> slower compare to Java
>
> - By annotating two methods it becomes only 5% slower than Java
>
> Is it surprise? Of course, not.
>
> Does it show right way to go? I believe so. Instead of fighting for
> optimization of code, which is assumed to be dynamic (read can't be
> really optimized) we give tool for developer to choose when he want to
> optimize.
>
> Someone can argue that developer can always use Java, when he needs
> piece of statically typed code. There are several reasons why this is
> wrong
> - we seriously limit his freedom to develop
> - if he needs just 1 or 2 statically typed methods, why to add another
> Java class
>
> Now when Groovy becomes more and more popular and used together with
> tons of existing Java code we hear a lot of complains from users and
> developers (like recent messages from Peter and Graeme) regarding need
> for compile time (and even IDE level) type check instead od runtime.
> The beuty of my approach is it also gives ability to mark piece of
> code as type checked.
>
> I believe if we choose to implement this program Groovy will become
> even stronger and appealing for Java developers.
>
> What do you think?
>
> Best regards
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
You've done a great work so far on improving the performance of
Groovy, and Groovy 1.6 will bring Groovy ahead of the pack as the most
performant dynamic language for the JVM.
Congratulations for this work.
However, as this has been discussed on this list a few times already
or at the last Groovy Developer Conference, it's better and saner to
make Groovy the fastest dynamic language possible on the JVM by
creating the best second generation MOP, rather than by adding a few
hacks to make Groovy a more statically typed language.
What would happen if such a proposal was committed?
In a few months from now, all Groovy code samples we would come across
would be littered with @Typed annotations all around -- who remembers
the ugly @Property annotation making your Groovy beans ugly?
A few months later, and people will wonder why this is not the default
behavior and be applied to all possible methods or classes.
Groovy will become more and more statically typed, and for
"performance sake", we'd imagine other such hacks to make Groovy less
and less dynamic over time, or littered with ugly annotations.
Such a proposal would be a consent that we failed to make Groovy the
fastest dynamic language possible.
Have we really tried to make Groovy as fast as possible? Have we
implemented a second generation MOP yet? No.
Furthermore, even with such an annotation, this code path would always
be slower than raw Java anyway.
Remember that Groovy has not been conceived to replace Java, but as a
complement, an adjunct, an enhancer to Java.
It's a core value of the language and the project.
With the joint compiler, the ant tasks, the maven plugin, it's so easy
to just implement one additional Java class, that it is totally
seamless and transparent to mix Groovy and Java together.
When raw performance matter, using Java is simply the best option, and
nothing we could do would make the code faster than raw Java.
It doesn't mean that Groovy can't be made more performant than it is
today, on the contrary, it's time to work on MOP2 instead. So you can
focus your energy on something less frustrating if you so wish.
As discussed several times already, we should focus now on this new
Meta-Object Protocol, perhaps to make Groovy even more dynamic, but to
make it the faster possible dynamic language across all possible
platforms -- it's not an unrealistic goal to be faster than Ruby and
Python.
John Wilson and his experiments prove that even without call site
caching and similar techniques, we can be even more performant than we
are today with all these techniques applied. The Jython and JRuby
guys, as well as the guys on the JVM language list prove us that there
are better ways too.
If ever we recognize that this new architecture is a failure, we don't
even need to implement such annotation trick, as the simplest possible
way to make the code as performant as possible is to just implement a
few lines of Java code to make the overal performance right so that
all possible projects meet the expected stricter SLAs.
So, thanks a lot for this suggestion and experiment, but I think it's
not the right direction to take in terms of performance improvements,
but rather it's time we spend our time and energy on designing the
next generation dynamic system for Groovy.
On Tue, Feb 19, 2008 at 11:10 AM, Alex Tkachman <alex.tkachman@...> wrote:
> Hi Groovy Developers!
>
> As many of you know I spent almost last 8 months (since July) working
> mostly on different aspects of Groovy performance. And results so far
> are very good - each new version are noticeably faster then previous
> one.
>
> But you know what - I feel myself like an idiot.
>
> The problem we try to solve can be formulated very simply
> - we have piece of code, which is effectlvely statically typed (either
> typed already or can become typed without to much problems for
> developer because he knows that nothing dynamic is involved)
> - we forget almost all we know about types during compilation because
> we assume that everything can be dynamicly changed at any momemt
> - we try to achieve same performance as Java has by doing amounts of
> very complicated tricks on runtime
>
> After 4th attempt to rewrite call sites optimization and avoid some
> very tricky bugs with EMC and categories on multi-threading I felt
> that it is not the best way to spend my life.
>
> At this point I remind myself well-known rule that 95% of performance
> problems come from 5% of code. Well, we can argue about exact figures
> - some people say 99-1, some 90-10, some 80-20 and I my personal
> experience during many years is 95-5 but I don't think it is really
> matter.
>
> What is really matter is that instead of runtime optimizing everything
> without help of developer I (as developer) would prefer to help
> compiler to optimize 5% of code, which is performance critical for me.
>
> So I did simple experiment
> - I introduced annotation
>
> @Retention(RetentionPolicy.SOURCE)
> @Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
> public @interface Typed {
> public enum TypePolicy {
> Dynamicly, // traditional Groovy, no resolve
> Strictly, // traditional Java, full resolve required
> SemiStrictly // resolve and call statically what you can
> and call the rest dynamically
> }
>
> TypePolicy value () default TypePolicy.Strictly;
> }
>
> - I prototyped compiler modification to use for static resolve (for
> Strictly and SemiStrictly) both type information, DGM methods and
> categories in use
> - I prototyped work with primitives for Strictly and SemiStrictly
>
> - I experimented with just one script spectralnorm, which is my huge
> headache last weeks and which is much much slower then Java
> counterpart.
>
> - By annotating just one method with @Typed it becomes only twice
> slower compare to Java
>
> - By annotating two methods it becomes only 5% slower than Java
>
> Is it surprise? Of course, not.
>
> Does it show right way to go? I believe so. Instead of fighting for
> optimization of code, which is assumed to be dynamic (read can't be
> really optimized) we give tool for developer to choose when he want to
> optimize.
>
> Someone can argue that developer can always use Java, when he needs
> piece of statically typed code. There are several reasons why this is
> wrong
> - we seriously limit his freedom to develop
> - if he needs just 1 or 2 statically typed methods, why to add another
> Java class
>
> Now when Groovy becomes more and more popular and used together with
> tons of existing Java code we hear a lot of complains from users and
> developers (like recent messages from Peter and Graeme) regarding need
> for compile time (and even IDE level) type check instead od runtime.
> The beuty of my approach is it also gives ability to mark piece of
> code as type checked.
>
> I believe if we choose to implement this program Groovy will become
> even stronger and appealing for Java developers.
>
> What do you think?
>
> Best regards
> Alex
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: Groovy performance: what to do
| Free embeddable forum powered by Nabble | Forum Help |
