31 messages in org.codehaus.groovy.devRe: [groovy-dev] as usual on performa...
FromSent OnAttachments
Alex TkachmanFeb 27, 2008 5:38 am 
Guillaume LaforgeFeb 27, 2008 5:47 am 
Alex TkachmanFeb 27, 2008 6:01 am 
Chanwit KaewkasiFeb 27, 2008 6:21 am 
Martin C. MartinFeb 27, 2008 6:27 am 
Jochen TheodorouFeb 27, 2008 6:32 am 
Jochen TheodorouFeb 27, 2008 6:33 am 
tugwilsonFeb 27, 2008 6:55 am 
Chanwit KaewkasiFeb 27, 2008 7:15 am 
Chanwit KaewkasiFeb 27, 2008 8:01 am 
Jochen TheodorouFeb 27, 2008 8:28 am 
tugwilsonFeb 27, 2008 9:00 am 
tugwilsonFeb 27, 2008 9:55 am 
Chanwit KaewkasiFeb 27, 2008 11:27 am 
Chanwit KaewkasiFeb 27, 2008 11:31 am 
Jochen TheodorouFeb 27, 2008 11:36 am 
Alex TkachmanFeb 27, 2008 11:58 am 
Martin C. MartinFeb 27, 2008 12:18 pm 
Jochen TheodorouFeb 27, 2008 12:37 pm 
Jochen TheodorouFeb 27, 2008 12:45 pm 
tugwilsonFeb 27, 2008 12:48 pm 
tugwilsonFeb 27, 2008 12:51 pm 
Martin C. MartinFeb 27, 2008 1:27 pm 
Alex TkachmanFeb 27, 2008 1:48 pm 
tugwilsonFeb 27, 2008 2:14 pm 
Jochen TheodorouFeb 27, 2008 5:09 pm 
Alexandru Popescu ☀Feb 27, 2008 5:38 pm 
Charles Oliver NutterFeb 28, 2008 12:20 am 
Jochen TheodorouFeb 28, 2008 1:33 am 
Alexandru Popescu ☀Feb 28, 2008 2:56 am 
tugwilsonFeb 28, 2008 3:29 am 
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] as usual on performance - operations on primitivesActions...
From:Chanwit Kaewkasi (chan@gmail.com)
Date:Feb 27, 2008 8:01:39 am
List:org.codehaus.groovy.dev

John,

The papers said about generating bytecodes from what they called 'trace'. The representation is their trace is a kind of SSA variant. When the system semantic is altered, they re-record or extend the trace. Each time they got a complete trace for each method, the trace will be compiled into the machine language (in our case JVML).

It looks good enough for me to try. I'll write some small code to prove its concept. Whether it works or not, I will post here ;-)

Cheers,

Chanwit

On 27/02/2008, tugwilson <tu@wilson.co.uk> wrote:

chanwit wrote:

Hi Alex,

P.S. Unfortunately 30-40% is much less than I expected :(

I've been reading some papers about trace-based Just-in-Time compilation, and what I've found out for Groovy is that there is not enough *type information* to feedback for JIT to optimize. This probably because Groovy class is not designed to be interpreted since

Th Ng runtime system executes floating point operations about 30% slower than pure Java (i.e. if Java takes 1 second Ng takes 1.3 seconds) if the operands are statically typed as float.

If the operands are untyped Ng is just under twice as slow as Java for floating point arithmetic.

The runtime system allows the behaviour of the operations to be changed on the fly via either a Category or the direct manipulation of the MetaClass for float.

You can have any number of Categories in operation and they will make no difference to the performance unless the category changes the semantics of an operation on float.

As the Ng runtime system supports semantics which are virtually identical to Groovy for arithmetic operations on primitive types (Groovy returns a double as the result of an operation on two floats Ng returns a float) I would say that the papers you are reading are tosh :)

John Wilson

-- View this message in context:
http://www.nabble.com/as-usual-on-performance---operations-on-primitives-tp15713441p15714947.html Sent from the groovy - dev mailing list archive at Nabble.com.

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

http://xircles.codehaus.org/manage_email

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

http://xircles.codehaus.org/manage_email