

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
62 messages in org.codehaus.groovy.devRe: [groovy-dev] Groovy performance: ...| From | Sent On | Attachments |
|---|---|---|
| Alex Tkachman | Feb 19, 2008 2:09 am | |
| Steven Devijver | Feb 19, 2008 2:37 am | |
| Alexandru Popescu ☀ | Feb 19, 2008 2:57 am | |
| Alex Tkachman | Feb 19, 2008 3:03 am | |
| Patric Bechtel | Feb 19, 2008 3:12 am | |
| Guillaume Laforge | Feb 19, 2008 3:25 am | |
| Guillaume Laforge | Feb 19, 2008 3:26 am | |
| Patric Bechtel | Feb 19, 2008 5:05 am | |
| Gavin Grover | Feb 19, 2008 5:51 am | |
| Steven Devijver | Feb 19, 2008 5:52 am | |
| Guillaume Laforge | Feb 19, 2008 5:54 am | |
| Tom Nichols | Feb 19, 2008 6:26 am | |
| Alex Tkachman | Feb 19, 2008 6:28 am | |
| Guillaume Laforge | Feb 19, 2008 6:35 am | |
| Tom Nichols | Feb 19, 2008 7:03 am | |
| Guillaume Laforge | Feb 19, 2008 7:38 am | |
| Chanwit Kaewkasi | Feb 19, 2008 7:52 am | |
| Charles Oliver Nutter | Feb 19, 2008 8:49 am | |
| Steven Devijver | Feb 19, 2008 10:03 am | |
| Charles Oliver Nutter | Feb 19, 2008 11:38 am | |
| Steven Devijver | Feb 19, 2008 12:11 pm | |
| Alex Tkachman | Feb 19, 2008 12:39 pm | |
| Alex Tkachman | Feb 19, 2008 12:48 pm | |
| tugwilson | Feb 19, 2008 1:36 pm | |
| Alex Tkachman | Feb 19, 2008 8:51 pm | |
| Guillaume Laforge | Feb 20, 2008 2:10 am | |
| Jochen Theodorou | Feb 20, 2008 9:46 am | |
| Martin C. Martin | Feb 20, 2008 5:25 pm | |
| Guillaume Laforge | Feb 21, 2008 1:35 am | |
| Tom Nichols | Feb 21, 2008 4:15 am | |
| Martin C. Martin | Feb 21, 2008 5:44 am | |
| Tom Nichols | Feb 21, 2008 6:22 am | |
| Smith, Jason, CTR, OASD(HA)/TMA | Feb 21, 2008 6:34 am | |
| Martin C. Martin | Feb 21, 2008 6:43 am | |
| Guillaume Laforge | Feb 21, 2008 6:48 am | |
| Guillaume Laforge | Feb 21, 2008 7:04 am | |
| Smith, Jason, CTR, OASD(HA)/TMA | Feb 21, 2008 7:18 am | |
| Charles Oliver Nutter | Feb 21, 2008 7:38 am | |
| Guillaume Laforge | Feb 21, 2008 7:42 am | |
| Martin C. Martin | Feb 21, 2008 8:36 am | |
| Martin C. Martin | Feb 21, 2008 8:48 am | |
| Pascal DeMilly | Feb 21, 2008 5:35 pm | |
| Gavin Grover | Feb 21, 2008 6:21 pm | |
| Jochen Theodorou | Feb 22, 2008 4:31 am | |
| Tom Nichols | Feb 22, 2008 4:49 am | |
| Charles Oliver Nutter | Feb 22, 2008 11:43 pm | |
| Guillaume Laforge | Feb 23, 2008 12:28 am | |
| Martin C. Martin | Feb 23, 2008 3:51 am | |
| Jochen Theodorou | Feb 23, 2008 2:49 pm | |
| Jochen Theodorou | Feb 23, 2008 2:53 pm | |
| Charles Oliver Nutter | Feb 24, 2008 2:01 am | |
| Martin C. Martin | Feb 24, 2008 3:56 am | |
| Martin C. Martin | Feb 24, 2008 4:11 am | |
| Charles Oliver Nutter | Feb 24, 2008 5:12 am | |
| Jochen Theodorou | Feb 24, 2008 3:17 pm | |
| Jochen Theodorou | Feb 24, 2008 3:31 pm | |
| Alexandru Popescu ☀ | Feb 24, 2008 3:36 pm | |
| Martin C. Martin | Feb 26, 2008 2:20 pm | |
| Martin C. Martin | Feb 26, 2008 3:15 pm | |
| Jochen Theodorou | Feb 27, 2008 2:38 am | |
| Jochen Theodorou | Feb 27, 2008 3:03 am | |
| Martin C. Martin | Mar 2, 2008 5:21 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread 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 do | Actions... |
|---|---|---|
| From: | Martin C. Martin (mar...@martincmartin.com) | |
| Date: | Feb 21, 2008 5:44:50 am | |
| List: | org.codehaus.groovy.dev | |
The people steering Groovy are firmly against the idea of programmers providing hints to the runtime that the semantics of some class or object are simple. I can appreciate their position. I'm a firm believer that languages should be driven by a single vision, held by a single person or a small group of like minded people, and one of the things that makes Groovy my favourite language is its wonderful design and semantics.
An advantage of open source is to allow sub groups to experiment with alternatives. Alex, how hard would it be to provide a patch to support this extension? Then, people who want to experiment with this FastGroovy, or whatever you want to call it, could do so.
There are a couple options I see:
1. An annotation or keyword which changes the semantics of Groovy, the way you've proposed.
2. A kind of hint to the compiler that variable X contains an object of class Y or one of its subclasses, and that it uses some metaclass known at compile time. At runtime, you can check to see whether that's true, and if so, call the appropriate method. If not, fall back on the traditional call dispatch.
3. Like 2, but it's an assertion. If the hint isn't true, signal an error. Perhaps have some way to even skip the check in very performance critical code, so that it just calls the appropriate method. Maybe this reduces to 1. in that case, although I'm not familiar with the details enough.
I really think this is a philosophical difference in the goal of the language, and best settled by experimentation. The experiment would help answer the question "how much would we have to change Groovy to have the best of both worlds: extreme dynamism most of the time, yet performance within 2x Java's when needed. How often would this work easily, predictably, and intuitively, vs. how often would it lead to messy interactions."
I really feel that we could be on the cusp of having both flexibility and performance, by simply making it easier to specify simple semantics when that's what you want anyway. I think it could be quite exciting to explore when and where this is possible, when we could retool libraries that use a lot of dynamics to use less (without reducing features), etc.
What do people think?
Best, Martin
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:
--------------------------------------------------------------------- To unsubscribe from this list, please visit:







