You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by MG <mg...@arscreat.com> on 2017/12/18 00:01:39 UTC
Re: Building Groovy
Just came across this as an example where using Groovy 2.4.6
invokedynamic seems to have been much slower than the older callsite
caching mechanism:
https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones
(https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)
Quote:
"While Groovy has performance options that allow you to keep your code
dynamically typed I never had good results with them. For Moqui
Framework using the Indy compiler and runtime (for Java invokedynamic)
actually made it significantly slower!
The best option for code that needs to run fast is the @CompileStatic
annotation. When you apply this annotation you can't use Groovy features
that depend on dynamic typing, but fortunately most of the more useful
features still work just fine."
I can totally understand the pull to get rid of large, old code parts -
but if this holds for more projects, I expect it will not go down well
with (dynamic) Groovy users...
mg
On 21.11.2017 17:38, Jochen Theodorou wrote:
>
>
> Am 21.11.2017 um 08:28 schrieb Paul King:
>> The "double" build is because of indy vs non-indy (one wipes out the
>> other) because of some assumptions that keep other parts of the build
>> simple. Could no doubt be streamlined given some TLC.
>>
>> Last I checked there were different performance characteristics
>> between indy/non-indy. We haven't gotten around to working out the
>> best path forward yet that will give us one set of jars without
>> losing performance in some scenarios. Again, just needs some time
>> dedicated to it.
>
> I don't see the old callsite caching still working properly in a Java9
> world, so it is time to cut loose
>
> bye Jochen
>
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
But the fact that it is an internal implementation detail does not
prohibit technical minded people to be interested in them. Most
developers I have met were interested in such things.
Most men have e.g. at least some knowledge about the inner workings of
their car, even if that are internal implementation details.
In any case I think it would be worth a try, if nothing comes of it,
nothing is lost...
On 21.12.2017 15:59, Cédric Champeau wrote:
>
>>
>> I disagree. 99% of our users don't even know what call site
>> caching is. They don't know what invokedynamic means,
>
> You think that 99% of Java professionals do not know what a
> feature that has been around since Java 7 is ?
> And even if that was the case: Google "java invoke dynamic" =>
> https://stackoverflow.com/questions/6638735/whats-invokedynamic-and-how-do-i-use-it
> <https://stackoverflow.com/questions/6638735/whats-invokedynamic-and-how-do-i-use-it>
> from 2011
>
>
> Of course. It's not a user facing feature. It's an internal
> implementation detail of JVM languages. Even if you play with
> `MethodHandles`, you will never deal directly with invoke dynamic.
Re: Building Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
>
>
> I disagree. 99% of our users don't even know what call site caching is.
> They don't know what invokedynamic means,
>
>
> You think that 99% of Java professionals do not know what a feature that
> has been around since Java 7 is ?
> And even if that was the case: Google "java invoke dynamic" =>
> https://stackoverflow.com/questions/6638735/whats-
> invokedynamic-and-how-do-i-use-it from 2011
>
Of course. It's not a user facing feature. It's an internal implementation
detail of JVM languages. Even if you play with `MethodHandles`, you will
never deal directly with invoke dynamic.
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
On 19.12.2017 09:37, Cédric Champeau wrote:
> 2017-12-19 2:21 GMT+01:00 MG <mgbiz@arscreat.com
> <ma...@arscreat.com>>:
>
> Hmmm, I don't know if Paul has some comeback, but to me you make a
> very convincing point...
> In that case the best way forward to me seems to be to
> 1) Ask non-@CompileStatic Groovy users who can afford the time to
> switch to the invoke dynamic variety of the Groovy jars and report
> back on performance issues (tests that run much slower, etc)
>
>
> This has been the case for years now, and almost nobody uses the
> invokedynamic version.
Speaking from my own experience: Of course, why would they - unless you
give them a reason/motivation...
> 2) Add a clearly visible message to the Groovy distribution
> download section, Maven/etc URL spots that Groovy 3.0 will be
> invoke dynamic only, and again ask for people to use indy now &
> give feedback if code seems to be unusally slow
>
>
> I disagree. 99% of our users don't even know what call site caching
> is. They don't know what invokedynamic means,
You think that 99% of Java professionals do not know what a feature that
has been around since Java 7 is ?
And even if that was the case: Google "java invoke dynamic" =>
https://stackoverflow.com/questions/6638735/whats-invokedynamic-and-how-do-i-use-it
from 2011
> and they don't have to. It's an internal implementation detail. What
> they care, on the other hand, is performance. So "is it slow? yes ->
> report a bug". No one has to care about the implementation detail,
> unless you're a language designer.
Or "is it slow? yes -> Groovy sucks (1st time user) / has become slow
(returning user) -> let's use Kotlin"
In the web there are still posts that present Groovy as being slow, back
from the time when it actually was, so it actually becoming slow is
something which in my humble opinion one should try to avoid.
In my experience with technical minded people it is never a bad idea to
explain why things are the way they are.
Paul seems to be of the opinion that it is just a problem of resources,
but even then I think it would be better to have more input now, to be
able to gauge the extent of the problem. Anyways, just my 0.1 EUR...
Cheers,
mg
Re: Building Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
2017-12-19 2:21 GMT+01:00 MG <mg...@arscreat.com>:
> Hmmm, I don't know if Paul has some comeback, but to me you make a very
> convincing point...
> In that case the best way forward to me seems to be to
> 1) Ask non-@CompileStatic Groovy users who can afford the time to switch
> to the invoke dynamic variety of the Groovy jars and report back on
> performance issues (tests that run much slower, etc)
>
This has been the case for years now, and almost nobody uses the
invokedynamic version. It's not just the fault of the users: when you have
a dependency on a library that is built to use the old call site caching
version, it's just not possible to "switch it to indy".
> 2) Add a clearly visible message to the Groovy distribution download
> section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic only,
> and again ask for people to use indy now & give feedback if code seems to
> be unusally slow
>
I disagree. 99% of our users don't even know what call site caching is.
They don't know what invokedynamic means, and they don't have to. It's an
internal implementation detail. What they care, on the other hand, is
performance. So "is it slow? yes -> report a bug". No one has to care about
the implementation detail, unless you're a language designer.
> 3) Start a competition who can come up with the most unexpectedly worst
> performing piece of Groovy indy code... ;-)
> (To be quite honest, I am wondering myself how invoke dynamic can be
> slower than the older, homebrewn approach, even if that is highly optimized
> - it seems to me like it should be a bit like a software renderer going up
> against a GPU...)
>
Again, I don't think optimizing the worst case is what we need to do. We
need to optimize the most common cases. If there are edge cases worth
optimizing, we can try, but we shouldn't compromise on the other cases for
a corner one.
>
> Cheers,
> mg
>
>
>
> On 18.12.2017 15:54, Jochen Theodorou wrote:
>
>> On 18.12.2017 01:01, MG wrote:
>>
>>> Just came across this as an example where using Groovy 2.4.6
>>> invokedynamic seems to have been much slower than the older callsite
>>> caching mechanism: https://www.linkedin.com/pulse
>>> /how-make-groovy-fast-java-david-e-jones (https://dzone.com/articles/ho
>>> w-to-make-groovy-as-fast-as-java)
>>>
>>
>> It is a chicken-egg problem. We still need to optimize indy in some
>> areas. But this does not happen if no users care to give detailed reports
>> which we can base optimizations on. They on the other hand simply switch to
>> static compilation or old callsite caching then. So in the end there is no
>> optimization, because optimizations tend to inflate and complicate code.
>>
>> And for the old callsite caching there is another part... I highly doubt
>> it is still well working with JDK9. Worse, I do not see how this can be
>> made work efficiently under JDK9. The preferred way in JDK9 is
>> invokedynamic after all. And while they (JDK developers) tend to increase
>> the capabilities of invokedynamic, it is the opposite story for reflection
>> (deep reflection, callsite sensitive rights made even worse through
>> modules, ...)
>>
>> So frankly I do not see much of a future for the old callsite caching
>>
>> bye Jochen
>>
>>
>
Re: Building Groovy
Posted by Russel Winder <ru...@winder.org.uk>.
On Wed, 2017-12-20 at 17:48 -0700, Nathan Harvey wrote:
>
[…]
> and
> advertised forum. Unfortunately the concept of a mailing list is
> deeply
[…]
For some people forums are anathema, email being the only sane way.
Other believe the opposite. The only community I know that deal with
this is the D community that has an email/forum system that everyone
can use the way they want.
The Gradle forum is a huge turn off for me
The Rust forum likewise.
But at least both provide RSS feeds so you can work with them a bit.
The whole idea of going to a forum is to create a walled garden.
--
Russel.
===========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: Building Groovy
Posted by Nathan Harvey <na...@gmail.com>.
I have another thread dedicated to the discussion of the forum. Ironically,
my post is marked as "not being accepted by the mailing list" despite there
being replies, but now my follow up posts aren't showing up, so I don't know
if the discussion can continue there. Here is the thread:
http://groovy.329449.n5.nabble.com/Start-a-forum-using-Discourse-tp5742677.html
- would you mind posting on there and telling me what the last post is?
Thanks.
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Building Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
On 21.12.2017 01:48, Nathan Harvey wrote:
> Although I think this discussion is getting off topic, I'll go ahead and
> chime in myself. I would once again remind people that a strong open source
> community is built on public communications. Mailing lists are old, they are
> fickle, they are annoying, and the list goes on. If Groovy wants to remain
> relevant, it needs to stay up to date, and it needs a well supported and
> advertised forum. Unfortunately the concept of a mailing list is deeply
> entrenched in Apache's requirements, which holds the community back. In
> truth, I don't know if that is possible to fix.
There is no Apache requirement to have a user list mailing list at all.
Only the developers/contributors decisions, discussions and votes have
to be present on the mailing list.
bye Jochen
Re: Building Groovy
Posted by Nathan Harvey <na...@gmail.com>.
Although I think this discussion is getting off topic, I'll go ahead and
chime in myself. I would once again remind people that a strong open source
community is built on public communications. Mailing lists are old, they are
fickle, they are annoying, and the list goes on. If Groovy wants to remain
relevant, it needs to stay up to date, and it needs a well supported and
advertised forum. Unfortunately the concept of a mailing list is deeply
entrenched in Apache's requirements, which holds the community back. In
truth, I don't know if that is possible to fix.
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
On 19.12.2017 18:23, Paul King wrote:
> I agree with earlier comments in particular from Jochen and Cédric. I
> also suspect that JDK 9 issues may force us down the indy only path at
> some point not too far away and I think we just have to keep
> optimising the common cases in the meantime using some benchmarking
> tests perhaps to guide efforts - just hard to find the time to tackle
> that right now.
10 cent time: With regards to the problem of development resources, have
you tried / considered gathering money through crowdfunding to pay
someone to speed up important development goals ? I think I read a post
by you that touched on the topic of being a paid Groovy developer, and I
am not suggesting someone quit his day job to do this. Funding would
most likely be too unsteady to do that. But if someone already had a
software company with some employees, he could see this as one project
among others, on which one developer could work for some time. And it
woud allow companies who use Groovy to expedit development without
committing too much...
Cheers,
mg
Re: Building Groovy
Posted by Paul King <pa...@asert.com.au>.
On Tue, Dec 19, 2017 at 11:21 AM, MG <mg...@arscreat.com> wrote:
> Hmmm, I don't know if Paul has some comeback, but to me you make a very
> convincing point...
>
I agree with earlier comments in particular from Jochen and Cédric. I also
suspect that JDK 9 issues may force us down the indy only path at some
point not too far away and I think we just have to keep optimising the
common cases in the meantime using some benchmarking tests perhaps to guide
efforts - just hard to find the time to tackle that right now.
Cheers, Paul.
> In that case the best way forward to me seems to be to
> 1) Ask non-@CompileStatic Groovy users who can afford the time to switch
> to the invoke dynamic variety of the Groovy jars and report back on
> performance issues (tests that run much slower, etc)
> 2) Add a clearly visible message to the Groovy distribution download
> section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic only,
> and again ask for people to use indy now & give feedback if code seems to
> be unusally slow
> 3) Start a competition who can come up with the most unexpectedly worst
> performing piece of Groovy indy code... ;-)
> (To be quite honest, I am wondering myself how invoke dynamic can be
> slower than the older, homebrewn approach, even if that is highly optimized
> - it seems to me like it should be a bit like a software renderer going up
> against a GPU...)
>
> Cheers,
> mg
>
>
>
> On 18.12.2017 15:54, Jochen Theodorou wrote:
>
>> On 18.12.2017 01:01, MG wrote:
>>
>>> Just came across this as an example where using Groovy 2.4.6
>>> invokedynamic seems to have been much slower than the older callsite
>>> caching mechanism: https://www.linkedin.com/pulse
>>> /how-make-groovy-fast-java-david-e-jones (https://dzone.com/articles/ho
>>> w-to-make-groovy-as-fast-as-java)
>>>
>>
>> It is a chicken-egg problem. We still need to optimize indy in some
>> areas. But this does not happen if no users care to give detailed reports
>> which we can base optimizations on. They on the other hand simply switch to
>> static compilation or old callsite caching then. So in the end there is no
>> optimization, because optimizations tend to inflate and complicate code.
>>
>> And for the old callsite caching there is another part... I highly doubt
>> it is still well working with JDK9. Worse, I do not see how this can be
>> made work efficiently under JDK9. The preferred way in JDK9 is
>> invokedynamic after all. And while they (JDK developers) tend to increase
>> the capabilities of invokedynamic, it is the opposite story for reflection
>> (deep reflection, callsite sensitive rights made even worse through
>> modules, ...)
>>
>> So frankly I do not see much of a future for the old callsite caching
>>
>> bye Jochen
>>
>>
>
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
Hmmm, I don't know if Paul has some comeback, but to me you make a very
convincing point...
In that case the best way forward to me seems to be to
1) Ask non-@CompileStatic Groovy users who can afford the time to switch
to the invoke dynamic variety of the Groovy jars and report back on
performance issues (tests that run much slower, etc)
2) Add a clearly visible message to the Groovy distribution download
section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic
only, and again ask for people to use indy now & give feedback if code
seems to be unusally slow
3) Start a competition who can come up with the most unexpectedly worst
performing piece of Groovy indy code... ;-)
(To be quite honest, I am wondering myself how invoke dynamic can be
slower than the older, homebrewn approach, even if that is highly
optimized - it seems to me like it should be a bit like a software
renderer going up against a GPU...)
Cheers,
mg
On 18.12.2017 15:54, Jochen Theodorou wrote:
> On 18.12.2017 01:01, MG wrote:
>> Just came across this as an example where using Groovy 2.4.6
>> invokedynamic seems to have been much slower than the older callsite
>> caching mechanism:
>> https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones
>> (https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)
>
> It is a chicken-egg problem. We still need to optimize indy in some
> areas. But this does not happen if no users care to give detailed
> reports which we can base optimizations on. They on the other hand
> simply switch to static compilation or old callsite caching then. So
> in the end there is no optimization, because optimizations tend to
> inflate and complicate code.
>
> And for the old callsite caching there is another part... I highly
> doubt it is still well working with JDK9. Worse, I do not see how this
> can be made work efficiently under JDK9. The preferred way in JDK9 is
> invokedynamic after all. And while they (JDK developers) tend to
> increase the capabilities of invokedynamic, it is the opposite story
> for reflection (deep reflection, callsite sensitive rights made even
> worse through modules, ...)
>
> So frankly I do not see much of a future for the old callsite caching
>
> bye Jochen
>
Re: Building Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
On 18.12.2017 01:01, MG wrote:
> Just came across this as an example where using Groovy 2.4.6
> invokedynamic seems to have been much slower than the older callsite
> caching mechanism:
> https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones
> (https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)
It is a chicken-egg problem. We still need to optimize indy in some
areas. But this does not happen if no users care to give detailed
reports which we can base optimizations on. They on the other hand
simply switch to static compilation or old callsite caching then. So in
the end there is no optimization, because optimizations tend to inflate
and complicate code.
And for the old callsite caching there is another part... I highly doubt
it is still well working with JDK9. Worse, I do not see how this can be
made work efficiently under JDK9. The preferred way in JDK9 is
invokedynamic after all. And while they (JDK developers) tend to
increase the capabilities of invokedynamic, it is the opposite story for
reflection (deep reflection, callsite sensitive rights made even worse
through modules, ...)
So frankly I do not see much of a future for the old callsite caching
bye Jochen