POV-Ray : Newsgroups : povray.off-topic : Sometimes, Haskell wins Server Time
7 Sep 2024 07:24:23 EDT (-0400)
  Sometimes, Haskell wins (Message 4 to 13 of 33)  
<<< Previous 3 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Mueen Nawaz
Subject: Re: Sometimes, Haskell wins
Date: 22 Sep 2008 14:27:27
Message: <48d7e38f$1@news.povray.org>
Invisible wrote:
> This tool is written entirely in Haskell. As we all know, Haskell is 
> slower than all other programming languages. This explains how Pandoc 
> manages to outperform the Perl Markdown script:

	Eh? Compiled Haskell's not all that slow. It beats scripting languages 
easily. Comparing it with Perl is not very illustrative of much.

-- 
Atheism is a non-prophet organization.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl


Post a reply to this message

From: Orchid XP v8
Subject: Re: Sometimes, Haskell wins
Date: 22 Sep 2008 16:24:32
Message: <48d7ff00$1@news.povray.org>
Mueen Nawaz wrote:

>     Eh? Compiled Haskell's not all that slow. It beats scripting 
> languages easily. Comparing it with Perl is not very illustrative of much.

How about compiled Perl then? Cos it beat that too...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*


Post a reply to this message

From: nemesis
Subject: Re: Sometimes, Haskell wins
Date: 22 Sep 2008 17:45:00
Message: <web.48d8118556396d9e773c9a3e0@news.povray.org>
Orchid XP v8 <voi### [at] devnull> wrote:
> Mueen Nawaz wrote:
>
> >     Eh? Compiled Haskell's not all that slow. It beats scripting
> > languages easily. Comparing it with Perl is not very illustrative of much.
>
> How about compiled Perl then? Cos it beat that too...

Compiled Perl just means stored bytecode loading faster into Perl's VM/AST
/whatever.  Same for Python or Ruby.  The bytecode is still interpreted without
a JIT and those are still highly dynamic languages where code optimizations
through type analysis is very much impossible.

Haskell compiles to native code and is a static typeful language.  The
comparison is unfair.  Haskell also comes complete with a very succint syntax
reminiscent of Perl, except not quite as unreadable.  I think the time of Perl
has gone and suggest people trying Perl6 with Pugs to drop it and go Hugs
instead. :)

That said, there's no language out there to do batch flat file processing with
such ease and grace as Perl.  Not even Haskell or Ruby.  The problem, I guess,
is that it's a structured file format and handling it with regexes alone gets
ugly pretty fast... if they go for std XML processing instead, they have no
real advantage over any other languages doing the same...


Post a reply to this message

From: Darren New
Subject: Re: Sometimes, Haskell wins
Date: 22 Sep 2008 18:43:49
Message: <48d81fa5$1@news.povray.org>
nemesis wrote:
> those are still highly dynamic languages where code optimizations
> through type analysis is very much impossible.

It's not impossible. It just hasn't been applied very much to those 
languages yet. You won't get the optimization that Haskell can get, but 
you can get much better than people currently get. The trick is to use 
run-time information to improve your run-time. Build a table at the 
dynamic dispatch sites that run often and cache the lookup results, for 
example. There are a number of recent (last year or two, up to next 
year) techniques that do a significantly good job, but I can't find the 
original article that discussed lots of the recent cutting-edge advances.

One such technique is
http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf

-- 
Darren New / San Diego, CA, USA (PST)


Post a reply to this message

From: nemesis
Subject: Re: Sometimes, Haskell wins
Date: 22 Sep 2008 23:00:00
Message: <web.48d85b4f56396d9e9da6bd580@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > those are still highly dynamic languages where code optimizations
> > through type analysis is very much impossible.
>
> It's not impossible.

Nothing is impossible, just pretty much unlikely. :)

> It just hasn't been applied very much to those
> languages yet.

The best I've ever seen for any dynamically typed language is the Stalin
compiler for the Lisp dialect Scheme.  It creates, from normal, unoptimized
Scheme code, very fast native code roughly approaching that of compiled C.
It's a true little wonder.  OTOH, it compiles a pretty static subset of Scheme:
 no eval, no load, no redefinitions of functions, no metaprogramming with
syntatic extensions and, though not dynamicism related, no arbitrary precision
arithmetic allowed.  Still, mighty impressive.

It does whole program compilation and lots of type inferencing to achieve that.
The code produced is very fast and quite small (though no match to the tiny C
executables), but the compiler itself, having to do all kinds of analysis in
the absence of type declarations, is probably the slowest you've ever seen.
Good thing any error messages are spot-on.

Languages like python and ruby abuse of their dynamic nature by going beyond
just dynamic typing and allowing all kinds of funky and slow runtime
metaprogramming.  A native compiler has no chance here.

> You won't get the optimization that Haskell can get, but
> you can get much better than people currently get. The trick is to use
> run-time information to improve your run-time.

Yes, it's what Hotspot does on the Java runtime and also what goes on on .NET's
CLR.  Not available to the official C runtimes of python, ruby and perl, except
when running on such VMs... still, I think their extreme dynamic nature makes
things difficult and allows for lots of sloppy style programming just for the
sake of it...


Post a reply to this message

From: Invisible
Subject: Re: Sometimes, Haskell wins
Date: 23 Sep 2008 04:07:10
Message: <48d8a3ae$1@news.povray.org>
>>>     Eh? Compiled Haskell's not all that slow. It beats scripting
>>> languages easily. Comparing it with Perl is not very illustrative of much.
>> How about compiled Perl then? Cos it beat that too...
> 
> Compiled Perl just means stored bytecode loading faster into Perl's VM/AST
> /whatever.  Same for Python or Ruby.  The bytecode is still interpreted without
> a JIT and those are still highly dynamic languages where code optimizations
> through type analysis is very much impossible.

Well OK. But given that the Perl version is presumably just making a 
half dozen calls to the internal regex engine, you'd still expect decent 
performance...

Anyway, whatever. My point is that Haskell isn't nearly as slow as 
everybody thinks it is.


Post a reply to this message

From: nemesis
Subject: Re: Sometimes, Haskell wins
Date: 23 Sep 2008 14:15:00
Message: <web.48d9316456396d9ef48316a30@news.povray.org>
Invisible <voi### [at] devnull> wrote:
> Well OK. But given that the Perl version is presumably just making a
> half dozen calls to the internal regex engine, you'd still expect decent
> performance...

yes.  Something more is getting in the way.

> Anyway, whatever. My point is that Haskell isn't nearly as slow as
> everybody thinks it is.

It's not slow at all.  It's just not nearly as fast as C/C++, but then, few are.
 And fewer are as high level and concise as Haskell. :)


Post a reply to this message

From: Orchid XP v8
Subject: Re: Sometimes, Haskell wins
Date: 23 Sep 2008 16:12:27
Message: <48d94dab$1@news.povray.org>
nemesis wrote:

> yes.  Something more is getting in the way.

Like Warp suggested, maybe his Perl coding just sucks for some reason?

>> Anyway, whatever. My point is that Haskell isn't nearly as slow as
>> everybody thinks it is.
> 
> It's not slow at all.  It's just not nearly as fast as C/C++, but then, few are.
> And fewer are as high level and concise as Haskell. :)

Heh. The Haskell bods are currently real excited because Haskell is 
ranked 3rd is the new parallel benchmark table. (But then, most of the 
other languages haven't submitted any parallel code yet.) It's lagging 
behind C++, but just faster than C.

Of course, as somebody pointed out, the C and C++ implementations are 
using OS threads, while Haskell is using lightweight Haskell threads, 
"so it's not a fair comparison". Debate that if you will...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*


Post a reply to this message

From: nemesis
Subject: Re: Sometimes, Haskell wins
Date: 23 Sep 2008 17:55:01
Message: <web.48d9658156396d9e773c9a3e0@news.povray.org>
Orchid XP v8 <voi### [at] devnull> wrote:
> nemesis wrote:
>
> > yes.  Something more is getting in the way.
>
> Like Warp suggested, maybe his Perl coding just sucks for some reason?

ah, that's it!  The thing between the chair and the keyboard...

> Heh. The Haskell bods are currently real excited because Haskell is
> ranked 3rd is the new parallel benchmark table. (But then, most of the
> other languages haven't submitted any parallel code yet.) It's lagging
> behind C++, but just faster than C.

I read the thread in the Haskell mailing-list.  Checking it out, both g++ and
ghc are behind some newcomer:  ATS.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all

Yet Another High Level Language with C syntax and performance and functional
programming semantics.  Joining D for candidates for next C/C++.


Post a reply to this message

From: Warp
Subject: Re: Sometimes, Haskell wins
Date: 23 Sep 2008 18:08:18
Message: <48d968d1@news.povray.org>
nemesis <nam### [at] gmailcom> wrote:
> Yet Another High Level Language with C syntax and performance and functional
> programming semantics.  Joining D for candidates for next C/C++.

  Like D (and a bunch of others), also probably doomed to failure.

  Many people have attempted in making a "better" C/C++, and many have
failed. Some attempts have good ideas, but they just don't get popular,
no matter how much they are advertised. Basically nobody knows what D is.
Another good example is Objective C, which has a rather small market
(which is growing a bit due to the iPhone, though).

  Not all attempts have failed though. Java and C# are examples of
successful ones. (Although in their cases the changes from C/C++ have
been a bit more radical.)

-- 
                                                          - Warp


Post a reply to this message

<<< Previous 3 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.