groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <Jason.Winneb...@windstream.com>
Subject RE: Integer primitive division
Date Tue, 03 Nov 2015 16:05:24 GMT
OK, I did create one: https://issues.apache.org/jira/browse/GROOVY-7659

It would be a nice-to-have, but to be honest I’m not sure how much of an impact this is
in real-world applications. I’m sure BigDecimal division is orders of magnitude slower than
primitive int division, but I’m not sure how often int division occurs in real-world apps
– code that already is very performance sensitive that is using fixed-point math like image
processing is probably already written in Java or C or even ASM anyway. There is also use
cases for primopts when parsing binary data, but shifting is more common there than division
and I tested bitshift and  (a >>> 3 & 0xFF for example), and there compile static
appears to generate the same code as Java.

Jason

From: Keegan Witt [mailto:keeganwitt@gmail.com]
Sent: Monday, November 02, 2015 11:44 PM
To: users@groovy.incubator.apache.org
Subject: Re: Integer primitive division

Yea, I'm pretty sure by "improvement report" Jochen meant a Jira.
-Keegan

On Mon, Oct 26, 2015 at 9:01 AM, Winnebeck, Jason <Jason.Winnebeck@windstream.com<mailto:Jason.Winnebeck@windstream.com>>
wrote:
By improvement report do you mean you'd like for me to put in a JIRA for it?

As for performance, I haven't benchmarked it. I'm more wondering for general knowledge as
well. We just ported about 600 classes from a proprietary business rule language into static-compiled
Groovy, and for that rule execution, CPU performance is a concern (and upcoming dedicated
project) as the code runs on a web application refresh to recalculate values. We also use
Groovy elsewhere as well in a project that is otherwise written in Java, but since we've moved
about a 3rd of the project over to Groovy, a good part of my argument for using Groovy is
that we can use Groovy features and DSLs and still keep largely the same performance and compile-time
checking as in Java, but use dynamic where it makes sense (for example we use dynamic exclusively
in production and consumption of our web service APIs).

Jason

-----Original Message-----
From: Jochen Theodorou [mailto:blackdrag@gmx.org<mailto:blackdrag@gmx.org>]
Sent: Saturday, October 24, 2015 5:07 AM
To: users@groovy.incubator.apache.org<mailto:users@groovy.incubator.apache.org>
Subject: Re: Integer primitive division
On 23.10.2015 22:47, Winnebeck, Jason wrote:
> Is there any way to perform primitive integer division in Groovy
> compile static mode? If I do:
>
> (int)(12/2)
>
> Then it coverts 12 and 2 to Integer objects, calls a method that
> performs BigDecimal division, then calls "as int" (not just intValue)
> on the result, which itself does instanceof checks.
>
> I tried intdiv, and it is more efficient, but it still converts to and
> from Integer objects so that it can do A.intValue() / B.intValue(),
> and storing that result in an Integer itself.

I think I did do an optimization for this kind of thing for double, but I may not have done
that for int... normally if you do something like

int i = 12/2

the compiler should be able to optimize this to a normal int division like in Java for primopts
and compilestatic.. checking now I find a

     BIPUSH 12
     ICONST_2
     IDIV
     ISTORE 3

meaning it works for primopts, but not for compilstatic. Probably, because in normal Groovy
we do not prevent conversions with loss for numbers, while copilestatic insists of the div
resulting in a BigDecimal. And then primopts fail to help compilestatic.

Not sure if I should really qualify that as static compilation bug

As for intDiv... ideally the JVM does optimize the overhead away. But considering optimizations
being done here for primopts as well as the invokedynamic version I think some work should
be invested here.

An improvement report for this would be a good start

As for "What I'm wondering is if Java is strictly required if performance is a concern with
division." Did you check the impact of this?


bye blackdrag
----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.

Mime
View raw message