 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Some guy invented a language which he calls "Markdown":
http://daringfireball.net/projects/markdown/
It's a markup langauge that looks almost like plain text, but he wrote a
Perl script that can transform it into HTML with pretty formatting.
(Stuff like lines prefixed with "-" become bullet points, words unclosed
with "*" become italic, URLs become links, etc.)
That's pretty neat. But then a bunch of Haskell hackers came along and
developed a program called Pandoc:
http://johnmacfarlane.net/pandoc/
This translates Markdown into HTML, LaTeX (and therefore PDF),
Micro$oft's Rich Text format, DocBook XML, OpenDocument XML, OpenOffice
ODT, Texinfo or groff man, or even MediaWiki markup. It also adds a few
new syntax constructs [which can be disabled for compatibility], and it
follows the written Markdown language spec more closely than the Perl
version does.
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:
Perl Markdown: 15 seconds
Compiled Perl Markdown: 10 seconds
Pandoc (compiled Haskell): 0.9 seconds
So, in summary:
- Pandoc handles Markdown more correctly than the author's own Perl
implementation.
- Pandoc handles many more output formats than the author's own Perl
implementation.
- Pandoc handles more syntax constructs than the author's own Perl
implementation.
- Pandoc is approximately 10x faster than the author's own Perl
implementation.
So it's more correct, has more features, and runs faster. I call that a win!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> So it's more correct, has more features, and runs faster. I call that a win!
But is it better specifically because it was made in Haskell, or is it
better simply because they made it better?
If I make a Java version which supports a few more formats and is faster
than the Haskell version, does that mean that Java wins Haskell, or does
it mean I spent more time making it better? And if I make a C++ version
which is even faster, does that mean C++ wins all?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> But is it better specifically because it was made in Haskell, or is it
> better simply because they made it better?
This is the operative question.
First, notice that this application consists entirely of processing text
strings in a complex way - which is practically what the entire Perl
language was *designed* for from the very beginning. This is what many
people consider to be Perl's greatest strength, and what Perl is
supposedly highly optimised to do efficiently.
And yet, Haskell outperformed it, and matches the spec more exactly.
All of this *suggests* many things - significantly, that Haskell matches
the spec more closely hints that Haskell makes complex algorithms
"easier" to express, and so a closer match could be achieved.
But what does it *prove*? Well, strictly, nothing. Maybe the Perl
implementation just sucks? Maybe the Perl version could easily be
modified to be faster. Maybe there are bugs that could easily be fixed
to make it fit the spec better too.
Actually, I take that back. It does prove one thing worth knowing: some
people used Haskell to build a real-world tool that people who know
nothing about Haskell actually use to do stuff. That's not an
earth-shattering result, but it's an important one none the less.
> And if I make a C++ versionwhich is even faster, does that mean C++ wins all?
I was about to say "I'd be interested in seeing something like that",
but then I realised that in my current state of learning, I wouldn't
understand a word of it. :-S
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
