What *not* to use Haskell for

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Dan Piponi-2
Real time audio applications are top of my list of "crazy projects I
would work on if I had a month spare". I think it might work out
nicely. My approach wouldn't be to talk directly to audio hardware
from Haskell but instead use a framework like Lava to generate low
level code from an embedded DSL. I think that would be a really
elegant way to work at a high level and yet have the result execute
*faster* than traditionally written C++ code.
--
Dan

On Tue, Nov 11, 2008 at 7:41 PM, sam lee <[hidden email]> wrote:

> I haven't found multitrack audio recording applications written in
> Haskell. These are usually written in C++ using Jack audio or ASIO.
> This probably means that it is not a good idea to write real time
> audio applications in Haskell at the moment.
> So, probably avoid writing applications that use a high frequency
> timer and IO that should be synchronous to the timer in Haskell.
>
> On Tue, Nov 11, 2008 at 9:02 PM, wren ng thornton <[hidden email]> wrote:
>> Dave Tapley wrote:
>>>
>>> Hi everyone
>>>
>>> So I should clarify I'm not a troll and do "see the Haskell light". But
>>> one thing I can never answer when preaching to others is "what does
>>> Haskell not do well?"
>>>
>>> Usually I'll avoid then question and explain that it is a 'complete'
>>> language and we do have more than enough libraries to make it useful and
>>> productive. But I'd be keen to know if people have any anecdotes,
>>> ideally ones which can subsequently be twisted into an argument for
>>> Haskell ;)
>>
>> With the appropriate caveats about particular subdomains (see final
>> paragraph), I wouldn't use Haskell for scripting. That is, (1) for
>> Bash-style programming where 95% of the code is just invoking *nix jobs, or
>> (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often
>> used.
>>
>> Re #1: Honestly, I don't see anything other than a dedicated competitor
>> being able to unseat Bourne/Bash at this task. Certainly a competitor would
>> have much room for improvement-- what with being able to replace
>> string-rewriting semantics with term-rewriting semantics, vastly improving
>> type safety and catching innumerable bugs. However, with unsavory frequency,
>> it is exactly those type-unsafe substitutions which can make shell scripting
>> cleaner and more direct than a type-safe alternative. Having type safety as
>> well as this sort of non-compositional structure would take a good deal of
>> work to get right.
>>
>> Re #2: People often complain about spooky Perl that uses things like
>> implicit $_ or other hidden variables. While these constructs can make any
>> sizable project unmaintainable, for the quick and dirty jobs they're just
>> what's needed to get things done with clarity. While ByteString code using
>> regexes is just as fast in Haskell, it's often more than twice as long as
>> the Perl, Sed, or Awk equivalents because many of the basic control
>> structures (like Perl's -n, -p, -l,... flags) aren't already provided.
>>
>>
>> That said, this isn't necessarily a bad thing for Haskell. "Real"
>> programming languages often don't do so well in these areas (Perl being the
>> exception), and they don't feel too bad about it. Both varieties of shell
>> scripting are very much of the DSL nature; for programs with a significant
>> amount of "actual logic" instead of mere plumbing or regexing, Haskell can
>> certainly outshine these competitors. On the one hand, C and friends fight
>> dirty and much work has been done so Haskell can join in on the bit-bashing
>> glory. However, shell scripting is a whole different kind of imperative muck
>> and very little work (that I've seen) has tried to get Haskell to jump down
>> in the sewers with them.
>>
>> --
>> Live well,
>> ~wren
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Andrew Coppin
Dan Piponi wrote:
> Real time audio applications are top of my list of "crazy projects I
> would work on if I had a month spare". I think it might work out
> nicely. My approach wouldn't be to talk directly to audio hardware
> from Haskell but instead use a framework like Lava to generate low
> level code from an embedded DSL. I think that would be a really
> elegant way to work at a high level and yet have the result execute
> *faster* than traditionally written C++ code.
>  

In other words, Haskell is an excellent language for designing
special-purpose compilers and interpretters for custom languages. ;-)

If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be
tempted to try it myself...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Don Stewart-2
andrewcoppin:

> Dan Piponi wrote:
> >Real time audio applications are top of my list of "crazy projects I
> >would work on if I had a month spare". I think it might work out
> >nicely. My approach wouldn't be to talk directly to audio hardware
> >from Haskell but instead use a framework like Lava to generate low
> >level code from an embedded DSL. I think that would be a really
> >elegant way to work at a high level and yet have the result execute
> >*faster* than traditionally written C++ code.
> >  
>
> In other words, Haskell is an excellent language for designing
> special-purpose compilers and interpretters for custom languages. ;-)
>
> If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be
> tempted to try it myself...

No need,

     http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy

Well, you still should probably know something of what you're doing..
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Dan Piponi-2
In reply to this post by Andrew Coppin
On Thu, Nov 13, 2008 at 11:08 AM, Andrew Coppin
<[hidden email]> wrote:
> In other words, Haskell is an excellent language for designing
> special-purpose compilers and interpretters for custom languages. ;-)
>
> If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be
> tempted to try it myself...

You could generate assembly language instructions directly. But if you
use the Haskell LLVM bindings your generated code will be (1) platform
independent and (2) optimised. I think there's a cool project lurking
there.
--
Dan
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

ajb@spamcop.net
In reply to this post by Lennart Augustsson
G'day all.

Quoting Lennart Augustsson <[hidden email]>:

> People have been admitting to using Haskell like that for quite a while now.
> I think it's an excellent use of Haskell as a DSEL host.

DSL is a proper superset of DSEL.  Just saying.

Cheers,
Andrew Bromage
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Henning Thielemann-4
In reply to this post by Dan Piponi-2
Dan Piponi schrieb:

> Real time audio applications are top of my list of "crazy projects I
> would work on if I had a month spare". I think it might work out
> nicely. My approach wouldn't be to talk directly to audio hardware
> from Haskell but instead use a framework like Lava to generate low
> level code from an embedded DSL. I think that would be a really
> elegant way to work at a high level and yet have the result execute
> *faster* than traditionally written C++ code.
> --
> Dan
>
> On Tue, Nov 11, 2008 at 7:41 PM, sam lee <[hidden email]> wrote:
>> I haven't found multitrack audio recording applications written in
>> Haskell. These are usually written in C++ using Jack audio or ASIO.
>> This probably means that it is not a good idea to write real time
>> audio applications in Haskell at the moment.
>> So, probably avoid writing applications that use a high frequency
>> timer and IO that should be synchronous to the timer in Haskell.


I do real time audio processing based on lazy storable vectors, however
I do not plan to implement another GUI driven program but want to
program audio algorithms and music in Haskell.
  http://www.haskell.org/haskellwiki/Synthesizer
 Although I can do some processing in real-time I don't approach the
speed of say SuperCollider so far. I must rely on GHC's optimizer and
sometimes it does unexpected things.

I know that one of Paul Hudak's students is working on something
similar, called HasSound. The DSL approach is already implemented for
CSound in Haskore (again there is also a not yet published library which
encapsulates this functionality) and you can also do real time sound
processing by controlling SuperCollider:
  http://www.haskell.org/haskellwiki/SuperCollider

See also:
  http://www.haskell.org/haskellwiki/Category:Music
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Andrew Coppin
In reply to this post by Dan Piponi-2
Dan Piponi wrote:

> On Thu, Nov 13, 2008 at 11:08 AM, Andrew Coppin
> <[hidden email]> wrote:
>  
>> In other words, Haskell is an excellent language for designing
>> special-purpose compilers and interpretters for custom languages. ;-)
>>
>> If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be
>> tempted to try it myself...
>>    
>
> You could generate assembly language instructions directly.

Yeah. I figure if I knew enough about this stuff, I could poke code
numbers directly into RAM representing the opcodes of the machine
instructions. Then I "only" need to figure out how to call it from
Haskell. It all sounds pretty non-trivial if you ask me though... ;-)

[Don't some OS versions implement execution-prevention? Presumably you'd
also have to bypass that in some platform-dependent way too...]

> But if you
> use the Haskell LLVM bindings your generated code will be (1) platform
> independent and (2) optimised. I think there's a cool project lurking
> there.
>  

Never heard of LLVM, but from the Wikipedia description it sound like
warm trippy goodness. Pitty there's no Haddock. :-(

[From the build log, it looks like it failed because the build machine
doesn't have the LLVM library installed. Is that really necessary just
for building the docs?]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Austin Seipp
Excerpts from Andrew Coppin's message of Fri Nov 14 14:13:01 -0600 2008:
> Yeah. I figure if I knew enough about this stuff, I could poke code
> numbers directly into RAM representing the opcodes of the machine
> instructions. Then I "only" need to figure out how to call it from
> Haskell. It all sounds pretty non-trivial if you ask me though... ;-)

Save yourself some time:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy

Using harpy, you can generate x86 assembly /inside/ your code and
execute it, using a DSL. This makes it excellent for code generators
and playing around with code generation.

Here's a calculator I wrote using it:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/calc

For more information, http://uebb.cs.tu-berlin.de/harpy/

> Never heard of LLVM, but from the Wikipedia description it sound like
> warm trippy goodness. Pitty there's no Haddock. :-(

It's a pretty excellent little system, to be honest. One of the
cleanest APIs I've ever used, too (especially for C++.)

> [From the build log, it looks like it failed because the build machine
> doesn't have the LLVM library installed. Is that really necessary just
> for building the docs?]

It's necessary to even get through the 'cabal configure' step, since
the configure script bundled with the haskell llvm bindings is run
then, which checks for the llvm-c headers.

Austin.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

tphyahoo
In reply to this post by wren ng thornton
I've been using HSH with good results for sysadmin tasks, and recently
uploaded HSHHelpers to hackage.

Of course with Cpan a lot of stuff has already been done for you, but
that's a library issue.

Nothing beats bash for a quicky of course, but there a lot of ways to
shoot yourself in the foot (eg global variables, hard to remember
quoting rules) that haskell protects me from. Like perl protects you,
but better.

thomas.

2008/11/12 wren ng thornton <[hidden email]>:

> Dave Tapley wrote:
>>
>> Hi everyone
>>
>> So I should clarify I'm not a troll and do "see the Haskell light". But
>> one thing I can never answer when preaching to others is "what does
>> Haskell not do well?"
>>
>> Usually I'll avoid then question and explain that it is a 'complete'
>> language and we do have more than enough libraries to make it useful and
>> productive. But I'd be keen to know if people have any anecdotes,
>> ideally ones which can subsequently be twisted into an argument for
>> Haskell ;)
>
> With the appropriate caveats about particular subdomains (see final
> paragraph), I wouldn't use Haskell for scripting. That is, (1) for
> Bash-style programming where 95% of the code is just invoking *nix jobs, or
> (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often
> used.
>
> Re #1: Honestly, I don't see anything other than a dedicated competitor
> being able to unseat Bourne/Bash at this task. Certainly a competitor would
> have much room for improvement-- what with being able to replace
> string-rewriting semantics with term-rewriting semantics, vastly improving
> type safety and catching innumerable bugs. However, with unsavory frequency,
> it is exactly those type-unsafe substitutions which can make shell scripting
> cleaner and more direct than a type-safe alternative. Having type safety as
> well as this sort of non-compositional structure would take a good deal of
> work to get right.
>
> Re #2: People often complain about spooky Perl that uses things like
> implicit $_ or other hidden variables. While these constructs can make any
> sizable project unmaintainable, for the quick and dirty jobs they're just
> what's needed to get things done with clarity. While ByteString code using
> regexes is just as fast in Haskell, it's often more than twice as long as
> the Perl, Sed, or Awk equivalents because many of the basic control
> structures (like Perl's -n, -p, -l,... flags) aren't already provided.
>
>
> That said, this isn't necessarily a bad thing for Haskell. "Real"
> programming languages often don't do so well in these areas (Perl being the
> exception), and they don't feel too bad about it. Both varieties of shell
> scripting are very much of the DSL nature; for programs with a significant
> amount of "actual logic" instead of mere plumbing or regexing, Haskell can
> certainly outshine these competitors. On the one hand, C and friends fight
> dirty and much work has been done so Haskell can join in on the bit-bashing
> glory. However, shell scripting is a whole different kind of imperative muck
> and very little work (that I've seen) has tried to get Haskell to jump down
> in the sewers with them.
>
> --
> Live well,
> ~wren
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Go Haskell!

Simon Marlow-7
In reply to this post by Claus Reinke
Claus Reinke wrote:
>> Do you have an example of a mutable state/ IO bound application, like,
>> hmm, a window manager or a revision control system or a file system...?
>
> If you're looking for a challenge, how about this one (there used to
> be lots of Haskellers into this game, any of you still around?-):
>
> http://computer-go.org/pipermail/computer-go/2008-October/016680.html

[ catching up with old haskell-cafe email ]

Interestingly, I did this a while ago.  Here's my results:

$ ./Bench 1 100000
b: 14840, w: 17143 mercy: 67982
elapsed time: 3.42s
playouts/sec: 29208


so, nearly 30k/sec random playouts on 9x9.  That's using a hack that stops
the game when the score is heavily in favour of one player, it drops to
around 20k/sec with that turned off.

Not bad, but probably I'd guess an order of magnitude worse than you can do
in tightly-coded C.  The Haskell implementation isn't nice, as you
predicted.  Also the code is derived from some non-free internal MS code,
so unfortunately I can't share it (but I could perhaps extract the free
bits if anyone is really interested).

W wins slightly more often I think because komi 5.5 on a 9x9 board is a tad
high.

It does parallelise too, of course:

$ ./Bench 8 100000 +RTS -N8
b: 14872, w: 17488 mercy: 67584
elapsed time: 1.00s
playouts/sec: 99908

though still room for improvement there.

Cheers,
        Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Claus Reinke
>>> Do you have an example of a mutable state/ IO bound application, like,
>>> hmm, a window manager or a revision control system or a file system...?
>> If you're looking for a challenge, how about this one (there used to
>> be lots of Haskellers into this game, any of you still around?-):
>> http://computer-go.org/pipermail/computer-go/2008-October/016680.html
> Interestingly, I did this a while ago.  Here's my results:
>
> $ ./Bench 1 100000
> b: 14840, w: 17143 mercy: 67982
> elapsed time: 3.42s
> playouts/sec: 29208
>
> so, nearly 30k/sec random playouts on 9x9.  That's using a hack that stops
> the game when the score is heavily in favour of one player, it drops to
> around 20k/sec with that turned off.

Nice!-) 20k playouts/sec (without  the early cutoffs) is the rough number
usually mentioned for these light playouts, reachable even in Java. My own
Haskell code for that was a factor of 5 slower:-(

> Not bad, but probably I'd guess an order of magnitude worse than you
> can do in tightly-coded C.  

Yes, a few people have reported higher rates, but most hobby coders
seem happy with 20k/sec - after that, it seems more interesting to move
towards heavy playouts and combinations with tree-based search instead
of light playouts with simple statistics alone. But if you don't get at least
those 20k/sec, it is difficult to run the number of experiments needed to
test presumed improvements in playing strength.

> The Haskell implementation isn't nice, as you predicted.  

What is really annoying for me is that I'm no longer used to this low-level
style of coding, so every time I add something, performance goes down,
and I have to work to get it back (I modified my playout code to match
that reference bot specification - my bot does get the expected 50% wins
against jrefbot, but is now a factor of 8 slower (still using only half the
memory, though)). Not to mention that I'm throwing away many of the
advantages of Haskell. That is one reason why I mentioned this challenge.

> Also the code is derived from some non-free internal MS code,
> so unfortunately I can't share it (but I could perhaps extract the free
> bits if anyone is really interested).

Interesting, can you tell what kind of code those internal bits are?
Of course, the fun is implementing it oneself, but it is very useful to
have reference points, such as the refbot spec, or the Java implementation
to play against. Your Haskell reference point will spur me to have another
look at my bot's performance!-)

The Go programming folks have a lot of useful infrastructure, btw,
including a server just for bot-vs-bot competition: http://cgos.boardspace.net/ 
Not to mention monthly tournaments, competions, etc.
 
> It does parallelise too, of course:
>
> $ ./Bench 8 100000 +RTS -N8
> b: 14872, w: 17488 mercy: 67584
> elapsed time: 1.00s
> playouts/sec: 99908
>
> though still room for improvement there.

That is the other reason why I mentioned this challenge: the specs
people use for their competition bots are interestingly parallel. One
example, this year's Computer Go Olympiad results:

http://www.grappa.univ-lille3.fr/icga/tournament.php?id=181

Many Faces of Go, winner, currently maxes out at 32 cores, a
limitation its author would like to remove (he's working with the
Microsoft HPC group, btw).

For the exhibition game against a pro that made the news this year,
MoGo used a cluster of 800 cores:

http://www.mail-archive.com/computer-go@.../msg08692.html
http://www.mail-archive.com/computer-go@.../msg08710.html

Of course, the simple reference bot implementations are a far cry
from MoGo or ManyFaces, but I thought this would be an interesting
non-trivial-but-doable challenge for Haskell performance and parallelism
fans, especially since there are still many people interested in Go here;-)

Claus

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Claus Reinke
>>> http://computer-go.org/pipermail/computer-go/2008-October/016680.html
>> Interestingly, I did this a while ago.  Here's my results:
>>
>> $ ./Bench 1 100000
>> b: 14840, w: 17143 mercy: 67982
>> elapsed time: 3.42s
>> playouts/sec: 29208
>>
>> so, nearly 30k/sec random playouts on 9x9.  That's using a hack that stops
>> the game when the score is heavily in favour of one player, it drops to
>> around 20k/sec with that turned off.
>
> Nice!-) 20k playouts/sec (without  the early cutoffs) is the rough number
> usually mentioned for these light playouts, reachable even in Java. My own
> Haskell code for that was a factor of 5 slower:-(

actually, that 5x is relative to jrefbot on my machine (Pentium M760, 2Ghz),
which doesn't quite reach 20k/sec, so if your code would run at 20k/sec on
my laptop, it would be 10x as fast as my bot:-(( Since you can't release your
code, could you perhaps time the jrefbot from the url above on your machine
as a reference point, so that I know how far I've yet to go? Something like:

    $ time ((echo "genmove b";echo "quit") |
        d:/Java/jre6/bin/java -jar refbots/javabot/jrefgo.jar 20000)
    = E5

    real    0m2.539s
    user    0m0.030s
    sys     0m0.031s

Btw, I just realised where my bot dropped from 5x to 8x: to work around

    http://hackage.haskell.org/trac/ghc/ticket/2669

all my array accesses were wrapped in exception handlers, to get
useful error messages while I adapted my code to the refbot spec..

That's not the only bug that got in the way:

    http://hackage.haskell.org/trac/ghc/ticket/2727

forced me to move from functional to imperative arrays much sooner
than I wanted, and due to

    http://hackage.haskell.org/trac/ghc/ticket/1216

I did not even consider 2d arrays (the tuple allocations might have gotten
in the way anyhow, but still..).

What do those folks working on parallel Haskell arrays think about the
sequential Haskell array baseline performance?

Claus

-- my slow bot's current time (for 20k playouts on a 2Ghz laptop):

    $ time ((echo "genmove b";echo "quit") | ./SimpleGo.exe 20000)
    TEXT e5 - amaf-score: 0.127
    TEXT e6 - amaf-score: 0.126
    TEXT d5 - amaf-score: 0.126
    TEXT f5 - amaf-score: 0.118
    TEXT d6 - amaf-score: 0.116
    TEXT f4 - amaf-score: 0.115
    TEXT e7 - amaf-score: 0.115
    TEXT f6 - amaf-score: 0.114
    TEXT d4 - amaf-score: 0.110
    TEXT d3 - amaf-score: 0.108
    TEXT e5 - amaf-score: 0.127
    = e5

    =

    real    0m10.711s
    user    0m0.030s
    sys     0m0.031s


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Don Stewart-2
claus.reinke:

> >>>http://computer-go.org/pipermail/computer-go/2008-October/016680.html
> >>Interestingly, I did this a while ago.  Here's my results:
> >>
> >>$ ./Bench 1 100000
> >>b: 14840, w: 17143 mercy: 67982
> >>elapsed time: 3.42s
> >>playouts/sec: 29208
> >>
> >>so, nearly 30k/sec random playouts on 9x9.  That's using a hack that
> >>stops the game when the score is heavily in favour of one player, it
> >>drops to around 20k/sec with that turned off.
> >
> >Nice!-) 20k playouts/sec (without  the early cutoffs) is the rough number
> >usually mentioned for these light playouts, reachable even in Java. My own
> >Haskell code for that was a factor of 5 slower:-(
>
> actually, that 5x is relative to jrefbot on my machine (Pentium M760, 2Ghz),
> which doesn't quite reach 20k/sec, so if your code would run at 20k/sec on
> my laptop, it would be 10x as fast as my bot:-(( Since you can't release
> your
> code, could you perhaps time the jrefbot from the url above on your machine
> as a reference point, so that I know how far I've yet to go? Something like:
>
>    $ time ((echo "genmove b";echo "quit") |
>        d:/Java/jre6/bin/java -jar refbots/javabot/jrefgo.jar 20000)
>    = E5
>
>    real    0m2.539s
>    user    0m0.030s
>    sys     0m0.031s
>
> Btw, I just realised where my bot dropped from 5x to 8x: to work around
>
>    http://hackage.haskell.org/trac/ghc/ticket/2669
>
> all my array accesses were wrapped in exception handlers, to get
> useful error messages while I adapted my code to the refbot spec..
>
> That's not the only bug that got in the way:
>
>    http://hackage.haskell.org/trac/ghc/ticket/2727
>
> forced me to move from functional to imperative arrays much sooner
> than I wanted, and due to
>
>    http://hackage.haskell.org/trac/ghc/ticket/1216
>
> I did not even consider 2d arrays (the tuple allocations might have gotten
> in the way anyhow, but still..).
>
> What do those folks working on parallel Haskell arrays think about the
> sequential Haskell array baseline performance?

Try using a fast array library like uvector? (With no serious overhead for
tuples too, fwiw)...

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Claus Reinke
>> What do those folks working on parallel Haskell arrays think about the
>> sequential Haskell array baseline performance?
>
> Try using a fast array library like uvector? (With no serious overhead for
> tuples too, fwiw)...

I downloaded uvector a while ago, but haven't got round to trying it
(yet another array API?). Mostly, I'd like to know a little more than just
"fast array lib":

- in which ways is it supposed to be faster? why?
- for which usage patterns is it optimised? how?
- if it is faster in general, why hasn't it replaced the default arrays?

In general, I think Haskell has too many array libraries, with too
many APIs. And that doesn't even take account the overuse of
unsafe APIs, or the non-integrated type-level safety tricks - if
array accesses were properly optimized, there should be a lot
less need for the extreme all-or-nothing checks or home-grown
alternative special-purpose APIs:

- type-level code for watermarking indices belonging to certain
    index sets is one step to eliminate index checks, but hasn't been
    integrated into any of the standard libs
- one could also associate index subsets with operations that do
    not leave the index superset belonging to an array (eg, if
    min<i<max, then min<=i+-1<=max, still safe without checks)
- GHC does seem to common up index checks only if they are
    identical, but if min<i<i+1<i+2<..<i+j<max, only the outer checks
    are really necessary (as long as we know about '+')
- whole-array ops allow to avoid index checks without type-level
    tricks, leaving the indexing implicit; but the corresponding ops
    in Data.Array.MArray claim to construct new arrays, contrary
    to the intended inplace updating for which one uses MArrays?
- etc. etc.

At least, uvector seems to take multi-element ops more seriously.
But with so many people working on sequential and parallel Haskell
array libraries, I was hoping for someone to take a big ax and clear
out all that sick and half-dead wood, to give a small number of healthy
arrays libs room to grow. Would be a lot easier for us poor naive
Haskell array users who otherwise tend to get lost in that forrest!-)

Just my 2c,-)
Claus


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Andrew Coppin
Claus Reinke wrote:

> In general, I think Haskell has too many array libraries, with too
> many APIs. And that doesn't even take account the overuse of
> unsafe APIs, or the non-integrated type-level safety tricks - if array
> accesses were properly optimized, there should be a lot less need for
> the extreme all-or-nothing checks or home-grown
> alternative special-purpose APIs:
>
> - type-level code for watermarking indices belonging to certain    
> index sets is one step to eliminate index checks, but hasn't been
>    integrated into any of the standard libs
> - one could also associate index subsets with operations that do    
> not leave the index superset belonging to an array (eg, if    
> min<i<max, then min<=i+-1<=max, still safe without checks)
> - GHC does seem to common up index checks only if they are
>    identical, but if min<i<i+1<i+2<..<i+j<max, only the outer checks
>    are really necessary (as long as we know about '+')
> - whole-array ops allow to avoid index checks without type-level
>    tricks, leaving the indexing implicit; but the corresponding ops
>    in Data.Array.MArray claim to construct new arrays, contrary
>    to the intended inplace updating for which one uses MArrays?
> - etc. etc.
>
> At least, uvector seems to take multi-element ops more seriously.
> But with so many people working on sequential and parallel Haskell
> array libraries, I was hoping for someone to take a big ax and clear
> out all that sick and half-dead wood, to give a small number of
> healthy arrays libs room to grow. Would be a lot easier for us poor naive
> Haskell array users who otherwise tend to get lost in that forrest!-)

+3

The current array situation is unecessarily messy - and I prefer
mathematical elegance to ad-hoc mess. (And you think I use Haskell, why
exactly?)

Of course, it's all very well complaining about it... somebody still has
to *do* all this wonderful stuff. :-/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Jason Dagit-2
In reply to this post by Claus Reinke


On Thu, Nov 27, 2008 at 1:20 PM, Claus Reinke <[hidden email]> wrote:
What do those folks working on parallel Haskell arrays think about the
sequential Haskell array baseline performance?

Try using a fast array library like uvector? (With no serious overhead for
tuples too, fwiw)...

I downloaded uvector a while ago, but haven't got round to trying it
(yet another array API?). Mostly, I'd like to know a little more than just "fast array lib":

- in which ways is it supposed to be faster? why?
- for which usage patterns is it optimised? how?
- if it is faster in general, why hasn't it replaced the default arrays?

In general, I think Haskell has too many array libraries, with too
many APIs. And that doesn't even take account the overuse of
unsafe APIs, or the non-integrated type-level safety tricks - if array accesses were properly optimized, there should be a lot less need for the extreme all-or-nothing checks or home-grown
alternative special-purpose APIs:

- type-level code for watermarking indices belonging to certain   index sets is one step to eliminate index checks, but hasn't been
  integrated into any of the standard libs
- one could also associate index subsets with operations that do   not leave the index superset belonging to an array (eg, if   min<i<max, then min<=i+-1<=max, still safe without checks)
- GHC does seem to common up index checks only if they are
  identical, but if min<i<i+1<i+2<..<i+j<max, only the outer checks   are really necessary (as long as we know about '+')
- whole-array ops allow to avoid index checks without type-level
  tricks, leaving the indexing implicit; but the corresponding ops
  in Data.Array.MArray claim to construct new arrays, contrary
  to the intended inplace updating for which one uses MArrays?
- etc. etc.

This library would satisfy most of your requirements I suspect:

My understanding is that the author's code could be turned into a real library fairly easily if it hasn't been already.  I only read the paper; I didn't go looking for the library on hackage, but the author does provide the code for the library.

The author also says their Haskell code is faster than the same algorithm in Matlab.

But, I have to say.  Whenever you're faking dependent types in Haskell things get harder to understand for the programmer.  Checkout the section in the above paper about type checking.  Dependent types, even simulated ones, come with lots of cool static guarantees but understanding how to program with them comes with a high barrier to entry.  I think this cognitive load is even higher in Haskell where dependent types have to simulated by doing seemingly bizarre things.  I think it is this usability aspect that prevents the techniques from becoming more common in Haskell.
 


At least, uvector seems to take multi-element ops more seriously.
But with so many people working on sequential and parallel Haskell
array libraries, I was hoping for someone to take a big ax and clear
out all that sick and half-dead wood, to give a small number of healthy arrays libs room to grow. Would be a lot easier for us poor naive
Haskell array users who otherwise tend to get lost in that forrest!-)

Sometimes a good library design is an evolutionary process.  Maybe it's time to apply a fitness function.

Jason

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Manuel M T Chakravarty
In reply to this post by Claus Reinke
Claus Reinke:
> What do those folks working on parallel Haskell arrays think about the
> sequential Haskell array baseline performance?

You won't like the answer.  We are not happy with the existing array  
infrastructure and hence have our own.  Roman recently extracted some  
of it as a standalone package:

   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector

In the longer run, we would like to factor our library into DPH-
specific code and general-purpose array library that you can use  
independent of DPH.

Manuel
 
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Simon Marlow-7
Manuel M T Chakravarty wrote:

> Claus Reinke:
>> What do those folks working on parallel Haskell arrays think about the
>> sequential Haskell array baseline performance?
>
> You won't like the answer.  We are not happy with the existing array
> infrastructure and hence have our own.  Roman recently extracted some of
> it as a standalone package:
>
>   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector
>
> In the longer run, we would like to factor our library into DPH-specific
> code and general-purpose array library that you can use independent of DPH.

So we have two vector libraries, vector and uvector, which have a lot in
common - they are both single-dimension array types that support unboxed
instances and have list-like operations with fusion.  They ought to be
unified, really.

The main difference between these libraries and Haskell's arrays is the Ix
class.  So perhaps Haskell's arrays should be reimplemented on top of the
low-level vector libraries?  The Ix class is the root cause of the problems
with optimising the standard array libraries.

Cheers,
        Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Johan Tibell-2
On Fri, Nov 28, 2008 at 10:04 AM, Simon Marlow <[hidden email]> wrote:
> Manuel M T Chakravarty wrote:
>> In the longer run, we would like to factor our library into DPH-specific
>> code and general-purpose array library that you can use independent of DPH.
>
> So we have two vector libraries, vector and uvector, which have a lot in
> common - they are both single-dimension array types that support unboxed
> instances and have list-like operations with fusion.  They ought to be
> unified, really.

Yes please! Could we please have a ByteString style interface with
qualified imports instead of using ad-hoc name prefixes/suffixes as a
namespacing mechanism if we're going to merge the two libraries?

Cheers,

Johan
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Go Haskell! -> array libraries

Henning Thielemann
In reply to this post by Simon Marlow-7

On Fri, 28 Nov 2008, Simon Marlow wrote:

> Manuel M T Chakravarty wrote:
>> Claus Reinke:
>>> What do those folks working on parallel Haskell arrays think about the
>>> sequential Haskell array baseline performance?
>>
>> You won't like the answer.  We are not happy with the existing array
>> infrastructure and hence have our own.  Roman recently extracted some of it
>> as a standalone package:
>>
>>   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector
>>
>> In the longer run, we would like to factor our library into DPH-specific
>> code and general-purpose array library that you can use independent of DPH.
>
> So we have two vector libraries, vector and uvector, which have a lot in
> common - they are both single-dimension array types that support unboxed
> instances and have list-like operations with fusion.  They ought to be
> unified, really.

It's worse:
    http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storablevector
  :-)
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345