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:keeganw...@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.winneb...@windstream.com<mailto:jason.winneb...@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:blackd...@gmx.org<mailto:blackd...@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.
