Simon Chappell | 1 Mar 2007 01:09
Picon
Gravatar

Re: Groovy in Action has been slashdotted

On 2/28/07, Guillaume Laforge <glaforge@...> wrote:
> Simon P Chappell has written a review of Groovy in Action on Slashdot:
> http://books.slashdot.org/article.pl?sid=07/02/28/1435250&from=rss

Did you like it? I tried to mix as much Groovy evangelism in as I
thought I could get away with without being too obvious. :-)

Simon

--

-- 
simonpeter.org | simonpeter.com | techbook.info

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

    http://xircles.codehaus.org/manage_email

Fred Janon | 1 Mar 2007 02:43
Picon

Javalobby: Groovy making great strides... GroovyBlogs.org... new framework called Grails

Grrovy, Grails and the 20hr challenge in the Javalobby news...
 
 
Fred
 
Charles Oliver Nutter | 1 Mar 2007 02:55
Picon
Gravatar

Re: Groovy...competitive performance?

Russel Winder wrote:
> Groovy and Python are different languages with different aims and goals
> although they are both dynamic programming languages.  Python has been
> worked on for > 17years and the PVM has been optimized very highly.
> Groovy has been going about 3-4 years and has just released 1.0 as the
> reference definition of the language.  I would fully expect Groovy to
> get a lot faster in the next 13 years :-)

If other options are faster now, do you expect people will wait 13 
years? Don't rest on the strength of the language to save you when the 
implementation doesn't perform like it should or could. Be aggressive.

Also, to be fair, Python is pretty darn fast. Even Ruby 1.9, which has 
on average quadrupled performance over 1.8, isn't up to Python speeds yet.

> Currently I would expect a Groovy program doing sorting to be slow
> compared to Java and Python.  I would therefore use Java for this rather
> than Groovy.  And that is my real point, in a Groovy program you would
> use Java for the bits where Java is the right language for the sub-task
> and Groovy for the bits where Groovy is the right language for the
> sub-task.

Don't fall into this trap...the Rubyists say the same thing constantly: 
"write it in C". The truth is that dammit, I don't want to write it in 
[C, Java], I want to write it in [Ruby, Groovy, etc]. The relative 
performance of dynlangs, especially on the JVM, is going to make or 
break their viability in the broader market. The minute you start 
telling clients or users to "write it in Java" if they want performance, 
they're going to wonder why they moved away from Java in the first 
place. I say "write it in [Ruby, Groovy], and work with us to resolve 
your performance issues." You shouldn't need to fall back on [C, Java] 
to get the job done.

> The person should redo those tests and include JRuby as well.

Oh?

> Performance has not been on the agenda so far since the primary focus
> has been making the language sensible and viable.  The next step is to
> deal with the 1.4 -> 1.5 -> 1.6 -> 1.7 issues so that Groovy can be
> sensibly useful for anyone with a post 1.4 JVM.  This is well on the way
> now.  Then there is the question of investigating performance issues. 

Don't put it off too long. On JRuby, we've had a primary focus on 
compatibility with Ruby 1.8, but we've always had it as a secondary 
(more entertaining) goal to continually improve performance. As a 
result, we've gotten closer to 100% compatibility while simultaneously 
improving performance as much as 5x over last year. And much of that 
actually came during the first three quarters of 2006, so it was 
part-time work. You can and should work on both; a lack of progress on 
either front will turn people off faster than somewhat slower progress 
on both.

- Charlie

- Charlie

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

    http://xircles.codehaus.org/manage_email

paduffy | 1 Mar 2007 05:14
Picon
Favicon

Re: RE: RE: Groovy...competitive performance?


Ed,

Re: your points...noted and agreed.

But please understand that the loop in this script was tested on a 13 GByte
(with a G) text file.  Any first pass issues are irrelevant.

Cheers

Edward Povazan wrote:
> 
> A little off topic but on topic for benchmarks ...
> I've looked at some other benchmarks which rely on using command line  
> commands to time a process etc. These are simply silly for the JVM.  
> To make it fair, C benchmarks should be timed to include part of  
> compile and link.
> 
> In my own testing, I tend to create a benchmark method, and then call  
> it repeatedly a few times before timing to warm up Hotspot. The  
> difference between the first run or two and subsequent ones is huge.  
> And of course the same will apply to Groovy. So any timing you get in  
> a script written to execute once is suspect.
> 
> -Ed
> 
> On 27-Feb-07, at 5:24 AM, paduffy wrote:
> 
>>
>> Here is the script.  Appreciate it if you could point out any  
>> glaring issues:
>>
>> // Various constants
>> //
>> inFileName = 'in.txt'
>> delim = '|'
>>
>> // Map input line prefix to output line params.
>> // Line param list format:
>> //    [0] = name of outfile
>> //    [1] = delim character
>> //    [2] = number of delim chars required.
>>
>> fileParams =
>> [
>>   'A:' : ['a.txt', delim, 4],
>>   'B:' : ['b.txt', delim, 3],
>>   'C:' : ['c.txt', delim, 5],
>>   'D:' : ['d.txt', delim, 3],
>>   'E:' : ['e.txt', delim, 7],
>>   'F:' : ['f.txt', delim, 3],
>>   'G:' : ['g.txt', delim, 4],
>>   'H:' : ['h.txt', delim, 3],
>>   'I:' : ['i.txt', delim, 11],
>>   'J:' : ['j.txt', delim, 5],
>>   'K:' : ['k.txt', delim, 6],
>>   'L:' : ['l.txt', delim, 4],
>>   'M:' : ['m.txt', delim, 2]
>> ]
>>
>> startTime = System.currentTimeMillis()
>>
>> // Open all output files.
>> //
>> Map outStreams = [:]
>> fileParams.each
>> {
>>   key, value ->
>>   PrintWriter outStream = new File(value[0]).newPrintWriter()
>>   outStreams[key] = outStream
>> }
>>
>> // Process the input file.
>> // Direct line to output file per line prefix.
>> //
>> File infile = new File(inFileName)
>> int lineCount = 0
>> for(line in infile)
>> {
>>   // Print occasional activity status.
>>   //
>>   lineCount = lineCount + 1
>>   if ((lineCount % 1000000) == 0) println "Processing line: $ 
>> {lineCount}"
>>
>>   // Strip leading and trailing spaces.
>>   // Ignore empty lines.
>>   // Ignore comment lines
>>   //
>>   line = line.trim()
>>   if (line == '') continue
>>   if (line[0] == '#') continue
>>
>>   // Split line into prefix and remainder.
>>   //
>>   String prefix = line.substring(0,2)
>>   line = line.substring(2)
>>
>>   if (outStreams[prefix])
>>   {
>>     outStreams[prefix].println(line)
>>   }
>> }
>>
>> // Close all the output files.
>> //
>> outStreams.each { key, value -> value.close() }
>>
>> duration = System.currentTimeMillis() - startTime
>>
>> println ''
>> println "Processing finished, duration: ${duration} msec"
>> println ''
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
> 
>     http://xircles.codehaus.org/manage_email
> 
> 
> 

--

-- 
View this message in context: http://www.nabble.com/Groovy...competitive-performance--tf3298331.html#a9243702
Sent from the groovy - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email

paduffy | 1 Mar 2007 05:24
Picon
Favicon

Re: Groovy...competitive performance?


Charles...well stated.  

IMO getting Groovy to a level of competitive performance (versus its JVM
peers JS, P/JYthon, etc.) is not an issue whose resolution should be long
postponed.  Builders, templating, etc. are all important plusses, but its
going to be a HARD  sell in my organization wrt performance versus its more
mature peers.

Charles Oliver Nutter-2 wrote:
> 
> Russel Winder wrote:
>> Groovy and Python are different languages with different aims and goals
>> although they are both dynamic programming languages.  Python has been
>> worked on for > 17years and the PVM has been optimized very highly.
>> Groovy has been going about 3-4 years and has just released 1.0 as the
>> reference definition of the language.  I would fully expect Groovy to
>> get a lot faster in the next 13 years :-)
> 
> If other options are faster now, do you expect people will wait 13 
> years? Don't rest on the strength of the language to save you when the 
> implementation doesn't perform like it should or could. Be aggressive.
> 
> Also, to be fair, Python is pretty darn fast. Even Ruby 1.9, which has 
> on average quadrupled performance over 1.8, isn't up to Python speeds yet.
> 
>> Currently I would expect a Groovy program doing sorting to be slow
>> compared to Java and Python.  I would therefore use Java for this rather
>> than Groovy.  And that is my real point, in a Groovy program you would
>> use Java for the bits where Java is the right language for the sub-task
>> and Groovy for the bits where Groovy is the right language for the
>> sub-task.
> 
> Don't fall into this trap...the Rubyists say the same thing constantly: 
> "write it in C". The truth is that dammit, I don't want to write it in 
> [C, Java], I want to write it in [Ruby, Groovy, etc]. The relative 
> performance of dynlangs, especially on the JVM, is going to make or 
> break their viability in the broader market. The minute you start 
> telling clients or users to "write it in Java" if they want performance, 
> they're going to wonder why they moved away from Java in the first 
> place. I say "write it in [Ruby, Groovy], and work with us to resolve 
> your performance issues." You shouldn't need to fall back on [C, Java] 
> to get the job done.
> 
>> The person should redo those tests and include JRuby as well.
> 
> Oh?
> 
>> Performance has not been on the agenda so far since the primary focus
>> has been making the language sensible and viable.  The next step is to
>> deal with the 1.4 -> 1.5 -> 1.6 -> 1.7 issues so that Groovy can be
>> sensibly useful for anyone with a post 1.4 JVM.  This is well on the way
>> now.  Then there is the question of investigating performance issues. 
> 
> Don't put it off too long. On JRuby, we've had a primary focus on 
> compatibility with Ruby 1.8, but we've always had it as a secondary 
> (more entertaining) goal to continually improve performance. As a 
> result, we've gotten closer to 100% compatibility while simultaneously 
> improving performance as much as 5x over last year. And much of that 
> actually came during the first three quarters of 2006, so it was 
> part-time work. You can and should work on both; a lack of progress on 
> either front will turn people off faster than somewhat slower progress 
> on both.
> 
> - Charlie
> 
> - Charlie
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
> 
>     http://xircles.codehaus.org/manage_email
> 
> 
> 

--

-- 
View this message in context: http://www.nabble.com/Groovy...competitive-performance--tf3298331.html#a9243772
Sent from the groovy - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email

Russel Winder | 1 Mar 2007 08:08
Picon
Gravatar

Re: Groovy...competitive performance?

On Wed, 2007-02-28 at 19:55 -0600, Charles Oliver Nutter wrote:

> If other options are faster now, do you expect people will wait 13 
> years? Don't rest on the strength of the language to save you when the 
> implementation doesn't perform like it should or could. Be aggressive.

This is the point really.  I find it hard to justify using Groovy at all
most of the time because despite my abhorrence of many of the Python
language decisions, it is the dynamic programming language of now.  For
me Perl is anathema, and Ruby is nice but slow.  Of course there are
times when Python is just too slow, then it is down to C++. OR Fortran.

So despite preferring the closure-focused languages such as Ruby and
Groovy (especially the RAII philosphy that falls out naturally), I end
up with Python.

I guess the three places Groovy works for me is making small UI centric
Java applications where the use of Swing is the main part of the
application; Grails applications; replacing the XML specifcation for Ant
builds.

But this is a personal perspective and I don't work on big Web
applications.

> Also, to be fair, Python is pretty darn fast. Even Ruby 1.9, which has 
> on average quadrupled performance over 1.8, isn't up to Python speeds yet.

Python is excellent -- despite it's bizarre look and feel as a language.

> Don't fall into this trap...the Rubyists say the same thing constantly: 
> "write it in C". The truth is that dammit, I don't want to write it in 
> [C, Java], I want to write it in [Ruby, Groovy, etc]. The relative 
> performance of dynlangs, especially on the JVM, is going to make or 
> break their viability in the broader market. The minute you start 
> telling clients or users to "write it in Java" if they want performance, 
> they're going to wonder why they moved away from Java in the first 
> place. I say "write it in [Ruby, Groovy], and work with us to resolve 
> your performance issues." You shouldn't need to fall back on [C, Java] 
> to get the job done.

I think there is an interesting difference though between Groovy/Java
than in other cases.  Groovy is designed and intended to work
symbiotically with Java.  So although it should only be very special
circumstances that require any C/C++ component in and JVM-based system,
I think saying that part of a system can be written in Java for
performance and Groovy for expressivity and dynamism is a fair design
philosophy.

It sounds as though you don't envisage JRuby as a language for mixed
source applications but as a single source language language using the
Java libraries.  That is fine, but not, I think, the right way of
viewing Groovy.

> > The person should redo those tests and include JRuby as well.
> 
> Oh?
> 
> > Performance has not been on the agenda so far since the primary focus
> > has been making the language sensible and viable.  The next step is to
> > deal with the 1.4 -> 1.5 -> 1.6 -> 1.7 issues so that Groovy can be
> > sensibly useful for anyone with a post 1.4 JVM.  This is well on the way
> > now.  Then there is the question of investigating performance issues. 
> 
> Don't put it off too long. On JRuby, we've had a primary focus on 
> compatibility with Ruby 1.8, but we've always had it as a secondary 
> (more entertaining) goal to continually improve performance. As a 
> result, we've gotten closer to 100% compatibility while simultaneously 
> improving performance as much as 5x over last year. And much of that 
> actually came during the first three quarters of 2006, so it was 
> part-time work. You can and should work on both; a lack of progress on 
> either front will turn people off faster than somewhat slower progress 
> on both.

This is really down to the roadmap that Guillaume, Jochen and Graeme put
together.  

Due to changing commitments, i.e. starting a consulting practice
focusing on advising clients on concurrency and parallelism issues in a
world where now every computing is a very parallel machine, I have less
time for actually working on Groovy per se.  I can still work on Gant,
but that is because I hate XML so much and use Ant so much :-)

--

-- 
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             russel@...
Steven Devijver | 1 Mar 2007 10:11
Picon

Using Groovy Builders to create Java3D scenes

An interesting article on how to write your own builders:

http://langexplr.blogspot.com/2007/02/using-groovy-builders-to-create-java3d.html

You can also vote for this article on dzone:

http://www.dzone.com/links/using_groovy_builders_to_create_java3d_scenes.html

Steven

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

    http://xircles.codehaus.org/manage_email

Dierk Koenig | 1 Mar 2007 10:32
Favicon
Gravatar

RE: Groovy in Action has been slashdotted

Hi Simon,

thanks a lot for the excellent review!

Yes, I liked it very much. It's very positive but by no means
"over the top". Almost every review (especially the ones at
slashdot) is done by someone who is interested in the topic and
therefore likes to read books about it. How could that be any
different?

The review received lots of comments, which is a good sign.
That some of the comments are plain crazy is just ... well,
slashdot :-)

I couldn't find more info about the rating. Does '9' mean
'9 of 10' where 10 would be best?

keep groovin'
Dierk

http://groovy.canoo.com/gina

> -----Original Message-----
> From: Simon Chappell [mailto:simonpeterchappell@...]
> Sent: Donnerstag, 1. März 2007 1:10
> To: user@...
> Subject: Re: [groovy-user] Groovy in Action has been slashdotted
>
>
> On 2/28/07, Guillaume Laforge <glaforge@...> wrote:
> > Simon P Chappell has written a review of Groovy in Action on Slashdot:
> > http://books.slashdot.org/article.pl?sid=07/02/28/1435250&from=rss
>
> Did you like it? I tried to mix as much Groovy evangelism in as I
> thought I could get away with without being too obvious. :-)
>
> Simon
>
> --
> simonpeter.org | simonpeter.com | techbook.info
>
> ---------------------------------------------------------------------
> 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

Paul King | 1 Mar 2007 10:45
Picon
Favicon
Gravatar

Re: Groovy in Action has been slashdotted

Simon Chappell wrote:
> On 2/28/07, Guillaume Laforge <glaforge@...> wrote:
>> Simon P Chappell has written a review of Groovy in Action on Slashdot:
>> http://books.slashdot.org/article.pl?sid=07/02/28/1435250&from=rss
> 
> Did you like it? I tried to mix as much Groovy evangelism in as I
> thought I could get away with without being too obvious. :-)
> 
> Simon

Like it? LOVE it!!!

Thanks for the great review!

Paul.

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

    http://xircles.codehaus.org/manage_email

Steven Devijver | 1 Mar 2007 11:56
Picon

Another GINA comment: "Groovy In Action: I Picked It Up, I Can't Put It Down!"

I'm not sure if this has already passed through this link:

http://www.weiqigao.com/blog/2007/02/07/groovy_in_action_i_picked_it_up_i_cant_put_it_down.html

Anyway, it's titled: "Groovy In Action: I Picked It Up, I Can't Put It Down!"

Steven

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

    http://xircles.codehaus.org/manage_email


Gmane