62 messages in org.codehaus.groovy.devRe: [groovy-dev] Groovy performance: ...
FromSent OnAttachments
Alex TkachmanFeb 19, 2008 2:09 am 
Steven DevijverFeb 19, 2008 2:37 am 
Alexandru Popescu ☀Feb 19, 2008 2:57 am 
Alex TkachmanFeb 19, 2008 3:03 am 
Patric BechtelFeb 19, 2008 3:12 am 
Guillaume LaforgeFeb 19, 2008 3:25 am 
Guillaume LaforgeFeb 19, 2008 3:26 am 
Patric BechtelFeb 19, 2008 5:05 am 
Gavin GroverFeb 19, 2008 5:51 am 
Steven DevijverFeb 19, 2008 5:52 am 
Guillaume LaforgeFeb 19, 2008 5:54 am 
Tom NicholsFeb 19, 2008 6:26 am 
Alex TkachmanFeb 19, 2008 6:28 am 
Guillaume LaforgeFeb 19, 2008 6:35 am 
Tom NicholsFeb 19, 2008 7:03 am 
Guillaume LaforgeFeb 19, 2008 7:38 am 
Chanwit KaewkasiFeb 19, 2008 7:52 am 
Charles Oliver NutterFeb 19, 2008 8:49 am 
Steven DevijverFeb 19, 2008 10:03 am 
Charles Oliver NutterFeb 19, 2008 11:38 am 
Steven DevijverFeb 19, 2008 12:11 pm 
Alex TkachmanFeb 19, 2008 12:39 pm 
Alex TkachmanFeb 19, 2008 12:48 pm 
tugwilsonFeb 19, 2008 1:36 pm 
Alex TkachmanFeb 19, 2008 8:51 pm 
Guillaume LaforgeFeb 20, 2008 2:10 am 
Jochen TheodorouFeb 20, 2008 9:46 am 
Martin C. MartinFeb 20, 2008 5:25 pm 
Guillaume LaforgeFeb 21, 2008 1:35 am 
Tom NicholsFeb 21, 2008 4:15 am 
Martin C. MartinFeb 21, 2008 5:44 am 
Tom NicholsFeb 21, 2008 6:22 am 
Smith, Jason, CTR, OASD(HA)/TMAFeb 21, 2008 6:34 am 
Martin C. MartinFeb 21, 2008 6:43 am 
Guillaume LaforgeFeb 21, 2008 6:48 am 
Guillaume LaforgeFeb 21, 2008 7:04 am 
Smith, Jason, CTR, OASD(HA)/TMAFeb 21, 2008 7:18 am 
Charles Oliver NutterFeb 21, 2008 7:38 am 
Guillaume LaforgeFeb 21, 2008 7:42 am 
Martin C. MartinFeb 21, 2008 8:36 am 
Martin C. MartinFeb 21, 2008 8:48 am 
Pascal DeMillyFeb 21, 2008 5:35 pm 
Gavin GroverFeb 21, 2008 6:21 pm 
Jochen TheodorouFeb 22, 2008 4:31 am 
Tom NicholsFeb 22, 2008 4:49 am 
Charles Oliver NutterFeb 22, 2008 11:43 pm 
Guillaume LaforgeFeb 23, 2008 12:28 am 
Martin C. MartinFeb 23, 2008 3:51 am 
Jochen TheodorouFeb 23, 2008 2:49 pm 
Jochen TheodorouFeb 23, 2008 2:53 pm 
Charles Oliver NutterFeb 24, 2008 2:01 am 
Martin C. MartinFeb 24, 2008 3:56 am 
Martin C. MartinFeb 24, 2008 4:11 am 
Charles Oliver NutterFeb 24, 2008 5:12 am 
Jochen TheodorouFeb 24, 2008 3:17 pm 
Jochen TheodorouFeb 24, 2008 3:31 pm 
Alexandru Popescu ☀Feb 24, 2008 3:36 pm 
Martin C. MartinFeb 26, 2008 2:20 pm 
Martin C. MartinFeb 26, 2008 3:15 pm 
Jochen TheodorouFeb 27, 2008 2:38 am 
Jochen TheodorouFeb 27, 2008 3:03 am 
Martin C. MartinMar 2, 2008 5:21 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [groovy-dev] Groovy performance: what to doActions...
From:Alexandru Popescu ☀ (the.@gmail.com)
Date:Feb 19, 2008 2:57:14 am
List:org.codehaus.groovy.dev

On Feb 19, 2008 12:10 PM, Alex Tkachman <alex@gmail.com> 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?

Hi Alex,

First of all, I would like to thank you for the work to improve the performance of Groovy. Your efforts are much appreciated!

Now, I see this problem in the following way:

1/ I do think that the current implementation (and I am referring here to the 1.5 branch) of MOP + Categories is suboptimal. JRuby guys, John's Ng and I think even Jython guys have found better ways to handle these implementation details.

I know that rewriting this part might require a huge effort and most probably will result in breaking changes. However, according to the JRuby benchmarks, I think it is worth it. And by looking at other popular languages (you mentioned at some point that you are very familiar with Python), they have got the guts to introduce late breaking changes that have lead to overall improvements (those being about performance, stability or consistency of the language). I do believe that Groovy should follow the same way and that the next major version should have these part rewritten. Call it Groovy 2 or Groovy 2k or whatever, but I strongly feel that this should be the place where your and maybe others effort should go.

2/ As we have previously discussed, I also like the idea of letting the developer decide on which parts he/she wants strict/dynamic typing. And if this is the only option to get a huge performance improvement for the 1.5 branch then I guess it may be worth to offer this option to our users.

Concluding, for me the near future of Groovy depends a lot of the language consistency and performance (and in a smaller measure to its API stability -- remember I've said near future). I would like to have a new version whose overall performance is improved thanks to clarifying the details of the MOP/Categories implementation. And I do believe that thanks to the consistency introduced by such a reimplementation most of the people will be willing to switch to the new version. However, for those that have invested a lot in the current version, the solution you're suggesting may work (and I do think it may be useful also in the next version).

bests,

./alex -- .w( the_mindstorm )p.

--------------------------------------------------------------------- To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email