Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Haskell-cafe
Home
+ new post
About this group
Join this group
Message from discussion Can Haskell outperform C++?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ryan Newton  
View profile  
 More options May 24 2012, 10:51 am
From: Ryan Newton <rrnew...@gmail.com>
Date: Thu, 24 May 2012 10:51:18 -0400
Local: Thurs, May 24 2012 10:51 am
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
Print | View thread | Show original | Report this message | Find messages by this author

Oops, forgot to reply-to-all.  This was a minor clarification on Wren's
behalf (he can correct me if I'm wrong).  But I agree with Bryan that it's
time for the thread to die:

> > Do bear in mind that Java doesn't optimize ---that's the JIT's job

> What are we supposed to make of that?

> Why write that and not -- Do bear in mind that Smalltalk doesn't optimize
> that's the JIT's job -- or -- Do bear in mind that C doesn't optimize
> that's the compiler's job.

I believe this was referring to the fact that javac isn't an aggressive
optimizing compiler on the way from source to bytecode, i.e. it's the
bytecode->asm leg where the optimization effort is focused.

As an outsider to things Java that's something I've had trouble
understanding, actually.  It doesn't seem like an either-or choice to me...

   -Ryan

On Wed, May 23, 2012 at 4:26 PM, Isaac Gouy <igo...@yahoo.com> wrote:
> > From: wren ng thornton <w...@freegeek.org>

> > Sent: Tuesday, May 22, 2012 9:30 PM

> -snip-
> > FWIW, that matches my expectations pretty well. Naive/standard Java
> performing
> > slower than Smalltalk; highly tweaked Java using non-standard data types
> > performing on-par with or somewhat faster than Smalltalk.

> I have no difficulty believing that if you are talking about a 1996 Java
> reference implementation and a 1996 Smalltalk JIT VM.

> I could believe that if you are comparing a naive Java program with a
> highly tweaked Smalltalk program.

> > That C is 7x faster is a bit on the high end, but for something like
> tsort I could imagine it'd be possible.

> It's possible because it's possible to write a Java program to be slower
> than it need be :-)

> > Do bear in mind that Java doesn't optimize ---that's the JIT's job

> What are we supposed to make of that?

> Why write that and not -- Do bear in mind that Smalltalk doesn't optimize
> that's the JIT's job -- or -- Do bear in mind that C doesn't optimize
> that's the compiler's job.

> -snip-
> > But even still, in my experience of using Smalltalk, the standard data
> > structures are much better done and so they will be on-par with what
> you'd
> > get from hand-tuning for Java. I've spent a lot of time trying to get
> decent
> > performance out of Java, not so much with Smalltalk; but the performance
> with
> > Smalltalk was sufficient that it wasn't needed so badly.

> Do you have a specific example that you can share?

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-C...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-C...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google