for and while

[Russel Winder-4]

Hi,

Has anyone done any performance checks on:

        long i = 0l
        while ( i < 1000000000l ) {
                ++i
        }

versus

        for ( long i = 0l ; i < 1000000000l ; ++i ) { }

to ensure that they behave roughly the same?

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Jochen Theodorou]

Russel Winder schrieb:

> Hi,
>
> Has anyone done any performance checks on:
>
> long i = 0l
> while ( i < 1000000000l ) {
> ++i
> }
>
> versus
>
> for ( long i = 0l ; i < 1000000000l ; ++i ) { }
>
> to ensure that they behave roughly the same?

what do you mean by "roughly the same"?  both loops will not be removed
by hotspot if you mean that. Both will be in O(n). Doesn't matter if one
is a bit slower than the other.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Sat, 2009-10-10 at 16:21 +0200, Jochen Theodorou wrote:

> Russel Winder schrieb:
> > Hi,
> >
> > Has anyone done any performance checks on:
> >
> > long i = 0l
> > while ( i < 1000000000l ) {
> > ++i
> > }
> >
> > versus
> >
> > for ( long i = 0l ; i < 1000000000l ; ++i ) { }
> >
> > to ensure that they behave roughly the same?
>
> what do you mean by "roughly the same"?  both loops will not be removed
> by hotspot if you mean that. Both will be in O(n). Doesn't matter if one
> is a bit slower than the other.

Of course it matters. O(n) ignores the constant k.  If the constant is
150,000,000,000 then it matters a lot.  Indeed even if the constant is 2
it matters rather a lot --  20s to run the code is very different to 10s
to run the code.  If while is faster than for then I need to use while
instead of for.  This is effectively benchmarking code so everything
matters.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Jochen Theodorou]

Russel Winder schrieb:
[...]
> Of course it matters. O(n) ignores the constant k.  If the constant is
> 150,000,000,000 then it matters a lot.  Indeed even if the constant is 2
> it matters rather a lot --  20s to run the code is very different to 10s
> to run the code.  If while is faster than for then I need to use while
> instead of for.  This is effectively benchmarking code so everything
> matters.

Russel, sorry for being so direct, but that is bullshit. Let us assume
loop 1 takes 1ms and loop 2 takes 5ms. That means loop 2 is much slower,
right? But if the content of the loop takes 10ms, then loop1 produces
10% overhead, loop2 50%. And the longer the loop body takes to execute
the less the overhead of the loop itself will be noticeable. In Groovy
you have to do "<", which results in a call to compareTo and "++" which
is even a dynamic method call, that is just a bit faster than the
average Groovy method call, because there is a special dgm$ method for
it. Those two alone increase the overhead of the loop compared to java
already big times and matters get worse, because in case of the Java
loop hotspot can move code around much more freely. In case of the
server VM such empty loops can even be removed completely and then it is
O(1), with a possible bigger constant, yes, but not O(n).

All this is not effectively benchmarking code, this is micorbenchmarking
unrelated cases. If you want to do a real benchmark, then look at your
application. If you tell me about your application we may find some
points to optimize, but looking at microbenchmarks and then assuming
that will relate directly to your code is just not realistic

If course there are cases when microbenchmarking gives results. For
example when you want to improve Groovy method call performance, then
this is your benchmark and it is micro. That's why I think, that in that
case even reading a volatile field is too slow for Groovy. But I am not
optimizing to get a certain microbenchmark faster, I optimize because I
know that Groovy uses lots of method calls and that those need to have
the maximum possible performance for groovy to become a faster language.
Also slow method call performance is hiding other cases which would need
optimization

Then another word for your constant. For benchmarking it does not really
matter how big it is, it does matter how long the benchmark takes,
because the longer the runs, the less the effect of noise. You would run
the loop test for an hour to get a good result?

And before I forget it... different VMs will cause different results.
For example in java5 the boxing could be considered as overhead compared
to direct handling with primitives. In jdk7 hotspot has special code to
recognize boxing and to "skip" that. As a result boxing becomes less
noticable... not that it was very much before.

All in all the question for me is: What do you really want to test Russel?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

Jochen,

On Sat, 2009-10-10 at 20:18 +0200, Jochen Theodorou wrote:

> Russel Winder schrieb:
> [...]
> > Of course it matters. O(n) ignores the constant k.  If the constant is
> > 150,000,000,000 then it matters a lot.  Indeed even if the constant is 2
> > it matters rather a lot --  20s to run the code is very different to 10s
> > to run the code.  If while is faster than for then I need to use while
> > instead of for.  This is effectively benchmarking code so everything
> > matters.
>
> Russel, sorry for being so direct, but that is bullshit. Let us assume
> loop 1 takes 1ms and loop 2 takes 5ms. That means loop 2 is much slower,
> right? But if the content of the loop takes 10ms, then loop1 produces
> 10% overhead, loop2 50%. And the longer the loop body takes to execute
> the less the overhead of the loop itself will be noticeable. In Groovy
> you have to do "<", which results in a call to compareTo and "++" which
> is even a dynamic method call, that is just a bit faster than the
> average Groovy method call, because there is a special dgm$ method for
> it. Those two alone increase the overhead of the loop compared to java
> already big times and matters get worse, because in case of the Java
> loop hotspot can move code around much more freely. In case of the
> server VM such empty loops can even be removed completely and then it is
> O(1), with a possible bigger constant, yes, but not O(n).

A robust response :-)

I think actually we are both right here.  I don't disagree with any of
your points.  However I have led you astray by not putting . . . in the
body of the loops.  I am not using empty loops, that was just bad
presentation of the original question.

I agree that Groovy is just plain slow compared to Java, I don't have a
problem with that.  In fact that is the whole point.  We need to get a
handle on guidance to people when writing Groovy/Java mixed systems.
This is going to be particularly important for GPars where the
coordination of parallel computations will be in Groovy and the
computations themselves will most likely be in Java -- or actually
possibly C++ or Fortran.

There are four stages here:

1.  All Groovy.
2.  All Groovy but being careful to ensure all expressions are using
primitives.
3.  Mixed Groovy and Java (C++).
4.  All Java (C++).

The interesting boundaries here are 2<->3 and 3<->4.  Actually if anyone
has to go 3->4 I would consider that to be a failure of Groovy.

> All this is not effectively benchmarking code, this is micorbenchmarking
> unrelated cases. If you want to do a real benchmark, then look at your
> application. If you tell me about your application we may find some
> points to optimize, but looking at microbenchmarks and then assuming
> that will relate directly to your code is just not realistic

Actually it isn't because the question was about my uise of Groovy
constructs in the context of some implementations of an embarrassingly
parallel computation.  This wasn't obvious from the original question
though.

> If course there are cases when microbenchmarking gives results. For
> example when you want to improve Groovy method call performance, then
> this is your benchmark and it is micro. That's why I think, that in that
> case even reading a volatile field is too slow for Groovy. But I am not
> optimizing to get a certain microbenchmark faster, I optimize because I
> know that Groovy uses lots of method calls and that those need to have
> the maximum possible performance for groovy to become a faster language.
> Also slow method call performance is hiding other cases which would need
> optimization

I'll pass on this as I am not interested in microbenchmarking, that is
an entirely internal to Groovy implementation thing.

> Then another word for your constant. For benchmarking it does not really
> matter how big it is, it does matter how long the benchmark takes,
> because the longer the runs, the less the effect of noise. You would run
> the loop test for an hour to get a good result?
>
> And before I forget it... different VMs will cause different results.
> For example in java5 the boxing could be considered as overhead compared
> to direct handling with primitives. In jdk7 hotspot has special code to
> recognize boxing and to "skip" that. As a result boxing becomes less
> noticable... not that it was very much before.
>
> All in all the question for me is: What do you really want to test Russel?

The speed of Groovy in doing some calculations and comparing different
splits of Groovy and Java as in 1, 2, and 3 above.

The problem at the back of my mind is that while has always been
"primitive" to Groovy where the C/C++/Java for loop was not present.
Implementing this for loop in Groovy led to lots of uses of closures and
things initially, but I didn't follow the implementation progression.
Is it still a big construct, or has it now been "primitivized"?

NB  Analogous argument happen in Python because the for loop generates a
list where the wile does not.  So in Python I have to use while loops
not for loops because of the huge memory hit you get with 10^9 items in
the iteration.
 
PS Just for information Groovy is between 85 and 2000 times slower than
Java which is itself 3 times slower that C/C++/Fortran on this
particular problem.  But that doesn't matter per se, since this is using
Groovy for something Groovy should not be used for.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Jochen Theodorou]

Russel Winder schrieb:
[...]
> We need to get a
> handle on guidance to people when writing Groovy/Java mixed systems.

you mean more than "write the critical parts in Java"?

[...]
> There are four stages here:
>
> 1.  All Groovy.
> 2.  All Groovy but being careful to ensure all expressions are using
> primitives.

you seem to assume, that this will improve performance greatly. This is
not the case, it does not have to be the primitive, it can be its
wrapper too... at last in 1.6/1.7. The only area were you can really
save something is with double/Double to avoid BigDecimal based computation.

> 3.  Mixed Groovy and Java (C++).
> 4.  All Java (C++).

[...]

>> All in all the question for me is: What do you really want to test Russel?
>
> The speed of Groovy in doing some calculations and comparing different
> splits of Groovy and Java as in 1, 2, and 3 above.
>
> The problem at the back of my mind is that while has always been
> "primitive" to Groovy where the C/C++/Java for loop was not present.
> Implementing this for loop in Groovy led to lots of uses of closures and
> things initially, but I didn't follow the implementation progression.
> Is it still a big construct, or has it now been "primitivized"?

the for loop? The "for" loop is roughly the same as your while loop,
there is really not much of a difference, there had been. Even the
for-in-loop had been this way. The alternative usage of closures was for
using "each", "find" and friends. Those have not been "primivized", but
that may happen in the future.

> NB  Analogous argument happen in Python because the for loop generates a
> list where the wile does not.  So in Python I have to use while loops
> not for loops because of the huge memory hit you get with 10^9 items in
> the iteration.

ah, ok, I didn't know that.

> PS Just for information Groovy is between 85 and 2000 times slower than
> Java which is itself 3 times slower that C/C++/Fortran on this
> particular problem.  But that doesn't matter per se, since this is using
> Groovy for something Groovy should not be used for.

85 to 2000 times slower.. I cannot agree. I have numbers from 30% slower
  up to... well open end. It very depends on the case. But well, you
have a certain case you are addressing here... I just wonder why you get
such a wide range for a certain case.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Mon, 2009-10-12 at 10:38 +0200, Jochen Theodorou wrote:
> Russel Winder schrieb:
> [...]
> > We need to get a
> > handle on guidance to people when writing Groovy/Java mixed systems.
>
> you mean more than "write the critical parts in Java"?

But that is the whole point.  Define "critical" in this context.
Clearly the knee-jerk reaction will be "profile your code" and to a
great extent that is the right answer, but it would be good to collect
together some rules of thumb to give people indicators.

> [...]
> > There are four stages here:
> >
> > 1.  All Groovy.
> > 2.  All Groovy but being careful to ensure all expressions are using
> > primitives.
>
> you seem to assume, that this will improve performance greatly. This is
> not the case, it does not have to be the primitive, it can be its
> wrapper too... at last in 1.6/1.7. The only area were you can really
> save something is with double/Double to avoid BigDecimal based computation.

Uuurrrr... it is the case, you say so yourself:  BigDecimal kills
performance for the sorts of computation I am talking about here.
Ensuring ints are ints not Integers is of marginal benefit -- but worth
doing if you are in the mind set and doing it in the right place.
Ensuring doubles are doubles can increase performance by around a factor
of 100 for these calculations.  Mandelbrot set calculations are the
trivial case I can cite.  Using BigDecimal computation takes too long to
wait, using doubles in Groovy speeds things up to almost acceptable.
Separating out the UI in Groovy and computation in Java makes it
entirely acceptable.

> > 3.  Mixed Groovy and Java (C++).
> > 4.  All Java (C++).
>
> [...]
> >> All in all the question for me is: What do you really want to test Russel?
> >
> > The speed of Groovy in doing some calculations and comparing different
> > splits of Groovy and Java as in 1, 2, and 3 above.
> >
> > The problem at the back of my mind is that while has always been
> > "primitive" to Groovy where the C/C++/Java for loop was not present.
> > Implementing this for loop in Groovy led to lots of uses of closures and
> > things initially, but I didn't follow the implementation progression.
> > Is it still a big construct, or has it now been "primitivized"?
>
> the for loop? The "for" loop is roughly the same as your while loop,
> there is really not much of a difference, there had been. Even the
> for-in-loop had been this way. The alternative usage of closures was for
> using "each", "find" and friends. Those have not been "primivized", but
> that may happen in the future.

The crucial statement here is "there had been".  I missed the note that
must have been published that advertised the change in the for loop
processing.  My problem.
 
> > NB  Analogous argument happen in Python because the for loop generates a
> > list where the wile does not.  So in Python I have to use while loops
> > not for loops because of the huge memory hit you get with 10^9 items in
> > the iteration.
>
> ah, ok, I didn't know that.

You'll have to come on my Python courses ;-)

> > PS Just for information Groovy is between 85 and 2000 times slower than
> > Java which is itself 3 times slower that C/C++/Fortran on this
> > particular problem.  But that doesn't matter per se, since this is using
> > Groovy for something Groovy should not be used for.
>
> 85 to 2000 times slower.. I cannot agree. I have numbers from 30% slower
>   up to... well open end. It very depends on the case. But well, you
> have a certain case you are addressing here... I just wonder why you get
> such a wide range for a certain case.

I'm afraid you have to agree, I have the data.  For this computation
using Groovy with BigDecimal is well over 2000 times slower than Java.
Carefully ensure use of double instead and you are down to around 85-100
times slower than Java.  But let me emphasize:  this is to be expected
and it is not bad -- this is using Groovy where Java can and should be
used.  That is after all the whole point of the Groovy/Java symbiosis.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Jochen Theodorou]

Russel Winder schrieb:

> On Mon, 2009-10-12 at 10:38 +0200, Jochen Theodorou wrote:
>> Russel Winder schrieb:
>> [...]
>>> We need to get a
>>> handle on guidance to people when writing Groovy/Java mixed systems.
>> you mean more than "write the critical parts in Java"?
>
> But that is the whole point.  Define "critical" in this context.
> Clearly the knee-jerk reaction will be "profile your code" and to a
> great extent that is the right answer, but it would be good to collect
> together some rules of thumb to give people indicators.

but if it is a for-loop and you write then contents of the loop in Java,
then why not the loop itself too? Now the funny thing is, that I think
iterating over a list in Groovy using the for-in-loop is faster, then
using the classic for loop. That is because the for-in-loop contains a
dynamic call to get an Iterator, but all calls to hasNext() and next()
are direct method calls. Not even boxing is done for hasNext(). In cas
of the for-loop "++" and "<" are not direct method calls and the result
of "<" is boxed just to be unboxed again. And I think that especially
"++" will have an bad effect on the computation, because "++" will cause
data synchronization, preventing hotspot of doing lots of good stuff. If
hotspot could do that for the iterator I don't know. But at last no
synchronization will have to be done.

[...]
>> The "for" loop is roughly the same as your while loop,
>> there is really not much of a difference, there had been. Even the
>> for-in-loop had been this way. The alternative usage of closures was for
>> using "each", "find" and friends. Those have not been "primivized", but
>> that may happen in the future.
>
> The crucial statement here is "there had been".  I missed the note that
> must have been published that advertised the change in the for loop
> processing.  My problem.

ehm... actually I think I wanted to write "there had never been" ;) If
the for loop processing ever changed, then it was before my time at
Groovy, because I did not do any such change and until recently I was
the only one brave enough to do such changes to the compiler.

>>> NB  Analogous argument happen in Python because the for loop generates a
>>> list where the wile does not.  So in Python I have to use while loops
>>> not for loops because of the huge memory hit you get with 10^9 items in
>>> the iteration.
>> ah, ok, I didn't know that.
>
> You'll have to come on my Python courses ;-)

Python is a nice language I think, just a bit... "implementation near" I
could probably phrase it. That has the advantage that you can think of
all possible tricks and has the disadvantage that you have to think
about them too... not to forget that little syntax problem ;)

>>> PS Just for information Groovy is between 85 and 2000 times slower than
>>> Java which is itself 3 times slower that C/C++/Fortran on this
>>> particular problem.  But that doesn't matter per se, since this is using
>>> Groovy for something Groovy should not be used for.
>> 85 to 2000 times slower.. I cannot agree. I have numbers from 30% slower
>>   up to... well open end. It very depends on the case. But well, you
>> have a certain case you are addressing here... I just wonder why you get
>> such a wide range for a certain case.
>
> I'm afraid you have to agree, I have the data.  For this computation
> using Groovy with BigDecimal is well over 2000 times slower than Java.

ah, with BigDecimal, ok, then it makes sense.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Mon, 2009-10-12 at 13:02 +0200, Jochen Theodorou wrote:

> Russel Winder schrieb:
> > On Mon, 2009-10-12 at 10:38 +0200, Jochen Theodorou wrote:
> >> Russel Winder schrieb:
> >> [...]
> >>> We need to get a
> >>> handle on guidance to people when writing Groovy/Java mixed systems.
> >> you mean more than "write the critical parts in Java"?
> >
> > But that is the whole point.  Define "critical" in this context.
> > Clearly the knee-jerk reaction will be "profile your code" and to a
> > great extent that is the right answer, but it would be good to collect
> > together some rules of thumb to give people indicators.
>
> but if it is a for-loop and you write then contents of the loop in Java,
> then why not the loop itself too? Now the funny thing is, that I think
> iterating over a list in Groovy using the for-in-loop is faster, then
> using the classic for loop. That is because the for-in-loop contains a
> dynamic call to get an Iterator, but all calls to hasNext() and next()
> are direct method calls. Not even boxing is done for hasNext(). In cas
> of the for-loop "++" and "<" are not direct method calls and the result
> of "<" is boxed just to be unboxed again. And I think that especially
> "++" will have an bad effect on the computation, because "++" will cause
> data synchronization, preventing hotspot of doing lots of good stuff. If
> hotspot could do that for the iterator I don't know. But at last no
> synchronization will have to be done.

Iterating over the range 0..10^9 is definitely best done by not creating
a list!

In the production code this loop in its entirety is best coded up in
Java, agreed.  The question originally arose due to some experimental
findings coding the whole thing using Groovy (production wise
inappropriate, but interesting as a test) which led to discovering a
problem in GPars.  (Václav and Alex are busy getting rid of this as we
email.)  Given the problem in Python, and my memory of the history of
the for ( . . . ; . . . ; . . .  ) construct in Groovy, I thought the
question worth asking.  After some misunderstandings, now got over, I
think the question was well worth asking.

> [...]
> >> The "for" loop is roughly the same as your while loop,
> >> there is really not much of a difference, there had been. Even the
> >> for-in-loop had been this way. The alternative usage of closures was for
> >> using "each", "find" and friends. Those have not been "primivized", but
> >> that may happen in the future.
> >
> > The crucial statement here is "there had been".  I missed the note that
> > must have been published that advertised the change in the for loop
> > processing.  My problem.
>
> ehm... actually I think I wanted to write "there had never been" ;) If
> the for loop processing ever changed, then it was before my time at
> Groovy, because I did not do any such change and until recently I was
> the only one brave enough to do such changes to the compiler.

I just remember a huge email thread many, many moons ago about
introducing the for ( . . . ; . . . ; . . .  ) construct and that the
implementation alighted on at the time was somewhat inefficient.  Sounds
like that has now gone away.  Which is great.

> >>> NB  Analogous argument happen in Python because the for loop generates a
> >>> list where the wile does not.  So in Python I have to use while loops
> >>> not for loops because of the huge memory hit you get with 10^9 items in
> >>> the iteration.
> >> ah, ok, I didn't know that.
> >
> > You'll have to come on my Python courses ;-)
>
> Python is a nice language I think, just a bit... "implementation near" I
> could probably phrase it. That has the advantage that you can think of
> all possible tricks and has the disadvantage that you have to think
> about them too... not to forget that little syntax problem ;)

I am still ambivalent about the significant whitespace approach, but
overall, I think Python is a very nice language.  It is however sadly
missing a proper framework for handling parallelism.  So is Java/Groovy
of course but GPars is going to fix that, and very soon too.

> >>> PS Just for information Groovy is between 85 and 2000 times slower than
> >>> Java which is itself 3 times slower that C/C++/Fortran on this
> >>> particular problem.  But that doesn't matter per se, since this is using
> >>> Groovy for something Groovy should not be used for.
> >> 85 to 2000 times slower.. I cannot agree. I have numbers from 30% slower
> >>   up to... well open end. It very depends on the case. But well, you
> >> have a certain case you are addressing here... I just wonder why you get
> >> such a wide range for a certain case.
> >
> > I'm afraid you have to agree, I have the data.  For this computation
> > using Groovy with BigDecimal is well over 2000 times slower than Java.
>
> ah, with BigDecimal, ok, then it makes sense.

:-)

I am entirely happy with BigDecimal being the standard floating point
representation in Groovy, it just makes sense.  But as soon as you start
to do any lengthy computation, you need to choose whether to switch the
Groovy to using double (which can be a bit painful) or switch that out
to Java (which can disrupt the code architecture/design).
 
--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Jochen Theodorou]

Russel Winder schrieb:
[...]
> Iterating over the range 0..10^9 is definitely best done by not creating
> a list!

In Groovy you need an Iterator, if that comes from some kind of
generator or a list does not matter.

> In the production code this loop in its entirety is best coded up in
> Java, agreed.  The question originally arose due to some experimental
> findings coding the whole thing using Groovy (production wise
> inappropriate, but interesting as a test) which led to discovering a
> problem in GPars.  (Václav and Alex are busy getting rid of this as we
> email.)  Given the problem in Python, and my memory of the history of
> the for ( . . . ; . . . ; . . .  ) construct in Groovy, I thought the
> question worth asking.  After some misunderstandings, now got over, I
> think the question was well worth asking.

you may have in memory that (...;...;...) is a list of Closures as I
originally implemented the for-loop. But that doesn't mean there is an
impact on the actual for-loop implementation, since the Closure list
would be a just an implementation detail. Actually the for-loop
implementation produced never a closure, even if a Closure list was used.

[...]
> I am entirely happy with BigDecimal being the standard floating point
> representation in Groovy, it just makes sense.  But as soon as you start
> to do any lengthy computation, you need to choose whether to switch the
> Groovy to using double (which can be a bit painful) or switch that out
> to Java (which can disrupt the code architecture/design).

yeah, as I said, I have to work on that part more, to make it more easy
for the developer to just get the right thing. For example if you do
BigDecimal*BigDecimal, with the result stored in a double... does it
then make sense to do a BigDecimal based calculation? int and long are
kind of examples for that problem, but in that case you more or less
just remove some bits when you store the long in an int. It is not that
easy with BigDecimal. If you do BigInteger*BigInteger and store it in an
int, then it would be well enough to just get the int part of both and
then an int*int multiplication. But since BigDecimal and double even
have different models for precession it is bit difficult

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


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

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

Jochen Theodorou wrote:
> Russel Winder schrieb:
 >

> yeah, as I said, I have to work on that part more, to make it more easy
> for the developer to just get the right thing. For example if you do
> BigDecimal*BigDecimal, with the result stored in a double... does it
> then make sense to do a BigDecimal based calculation? int and long are
> kind of examples for that problem, but in that case you more or less
> just remove some bits when you store the long in an int. It is not that
> easy with BigDecimal. If you do BigInteger*BigInteger and store it in an
> int, then it would be well enough to just get the int part of both and
> then an int*int multiplication. But since BigDecimal and double even
> have different models for precession it is bit difficult
>

Remember that BigDecimal and double math can get you very different answers to the same question, so
which system you use may well matter for the correctness of your program.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/gormbook


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

    http://xircles.codehaus.org/manage_email

[Jim White]

Jochen Theodorou wrote:

> ...
> All this is not effectively benchmarking code, this is micorbenchmarking
> unrelated cases. If you want to do a real benchmark, then look at your
> application. If you tell me about your application we may find some
> points to optimize, but looking at microbenchmarks and then assuming
> that will relate directly to your code is just not realistic
> ...

This is what Google Fellow Jeff Dean has to say about microbenchmarks:

Write Microbenchmarks!
• Great to understand performance
   – Builds intuition for back-of-the-envelope calculations
• Reduces cycle time to test performance improvements

"Designs, Lessons and Advice from Building Large Distributed Systems"

http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf

He is talking exactly about the issue here; development of
infrastructure (which includes things like language and library
implementations) that is used by a wide variety of applications.

Microbenchmarks that examine commonly used features (such as any and all
kinds of iteration) are part of systematic, rather than ad hoc,
performance enhancement.

Jim


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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jim White schrieb:
[...]

> This is what Google Fellow Jeff Dean has to say about microbenchmarks:
>
> Write Microbenchmarks!
> • Great to understand performance
>   – Builds intuition for back-of-the-envelope calculations
> • Reduces cycle time to test performance improvements
>
> "Designs, Lessons and Advice from Building Large Distributed Systems"
>
> http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf 
>
>
> He is talking exactly about the issue here; development of
> infrastructure (which includes things like language and library
> implementations) that is used by a wide variety of applications.
>
> Microbenchmarks that examine commonly used features (such as any and all
> kinds of iteration) are part of systematic, rather than ad hoc,
> performance enhancement.

microbenchmark is micro because it is small and not every small
benchmark makes sense.

For example benchmarking method call performance in Groovy makes sense,
since nearly all operations are based on method calls. Benchmarking a
loop header is a totally different story because of the reasons I
already mentioned. Method calls had always been a source of evil in
Groovy. Callsite caching made the costs a bit less, but still the
problems are there. This is neither new nor surprising. And as developer
the only choice you have is to not to write the program in Groovy if you
want maximum performance. This has always been a way we suggested.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


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

    http://xircles.codehaus.org/manage_email