Haskell Speed

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Haskell Speed

Peter Simons
Paul Moore writes:

 > It would be interesting to see standalone code for wcIOB
 > (where you're allowed to assume that any helpers you
 > need, like your block IO library, are available from the
 > standard library). This would help in comparing the
 > "obviousness" of the two approaches.

A simple version of the program -- which doesn't need any
3rd party modules to compile -- is attached below. My guess
is that this approach to I/O is quite obvious, too, if you
have experience with system programming in C.

IMHO, the main point of the example in the article is that

  wc :: String -> (Int, Int, Int)
  wc file = ( length (lines file)
            , length (words file)
            , length file
            )

is a crapy word-counting algorithm. I'm not sure whether
conclusions about functional programming in general or even
programming in Haskell can be derived from this code. Most
people seem to have trouble with lazy-evaluation, first of
all.

Peter



-- Compile with: ghc -O2 -funbox-strict-fields -o wc wc.hs

module Main ( main ) where

import System.IO
import Foreign

type Count = Int
data CountingState = ST !Bool !Count !Count !Count
                     deriving (Show)

initCST :: CountingState
initCST = ST True 0 0 0

wc :: Char -> CountingState -> CountingState
wc '\n' (ST _     l w c) = ST True (l+1)  w   (c+1)
wc ' '  (ST _     l w c) = ST True   l    w   (c+1)
wc '\t' (ST _     l w c) = ST True   l    w   (c+1)
wc  _   (ST True  l w c) = ST False  l  (w+1) (c+1)
wc  _   (ST False l w c) = ST False  l    w   (c+1)


bufsize :: Int                  -- our I/O buffer size
bufsize = 4096

type IOHandler st = Ptr Word8 -> Int -> st -> IO st

countBuf :: IOHandler CountingState
countBuf  _  0 st@(ST _ _ _ _) = return st
countBuf ptr n st@(ST _ _ _ _) = do
  c <- peek ptr
  let st' = wc (toEnum (fromEnum c)) st
  countBuf (ptr `plusPtr` 1) (n - 1) st'

loop :: Handle -> Int -> IOHandler st -> st -> IO st
loop h n f st' = allocaArray n (\ptr' -> loop' ptr' st')
  where
  loop' ptr st = st `seq` do
    rc <- hGetBuf h ptr n
    if rc == 0
       then return st
       else f ptr rc st >>= loop' ptr

main :: IO ()
main = do
  ST _ l w c <- loop stdin bufsize countBuf initCST
  putStrLn . shows l . (' ':) . shows w . (' ':) $ show c

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

Re: Re: Haskell Speed

Tomasz Zielonka
On Sun, Dec 25, 2005 at 12:24:38PM +0100, Peter Simons wrote:

> Paul Moore writes:
>
>  > It would be interesting to see standalone code for wcIOB
>  > (where you're allowed to assume that any helpers you
>  > need, like your block IO library, are available from the
>  > standard library). This would help in comparing the
>  > "obviousness" of the two approaches.
>
> A simple version of the program -- which doesn't need any
> 3rd party modules to compile -- is attached below. My guess
> is that this approach to I/O is quite obvious, too, if you
> have experience with system programming in C.
>
> IMHO, the main point of the example in the article is that
>
>   wc :: String -> (Int, Int, Int)
>   wc file = ( length (lines file)
>             , length (words file)
>             , length file
>             )
>
> is a crapy word-counting algorithm.

I have a crazy idea: what if we computed all three length applications
concurrently, with the RTS preempting the thread when it generates too
much unreclaimable nodes?

Do you know what I mean? The ideal effect would be that the three
threads chase each other on the list, there is always only a constant
part of the list in memory (no space-leak).

Best regards
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Haskell vs. Erlang for heavy-duty network apps (was Re: Haskell Speed)

Joel Reymont
In reply to this post by Bulat Ziganshin

On Dec 25, 2005, at 10:13 AM, Bulat Ziganshin wrote:

> Hello Joel,
> [...]
> so i think that your problems is due to bad design decisions caused by
> lack of experience. two weeks ago when you skipped my suggestions
> about improving this design and answered that you will use "systematic
> approach", i foresee that you will fail and say that Haskell is a bad
> language

Yes and no. The systematic approach that I used was profiling the  
serialization code and tweaking all that I could. I saved my  
profiling reports after each run and tracked the changes that I made.  
I will blog about it after Simon M. comes back and suggests how to  
squeeze the last bit out of it.

Regardless of this, it looks to me like I could easily have around  
4Mb of network traffic per second with about 4k threads and  
complicated nested structures to serialize and deserialize. Trying to  
tackle far less data suggests to me that it's not gonna happen. So I  
will try to take this as far as I can in Haskell, once I have the  
heavy artillery to back me up. If the results are good then I will  
use them in later applications of the same nature but in the meantime  
I'm rewriting this particular app in Erlang.

There are other apps to write in Haskell but my overall lesson is  
that the choice of right tool for the task at hand will help far more  
than any optimizations you can produce. Specially when the natural  
approach to the problem will just produce the results required.

I spent 3 months with this app, going from total Haskell newbie who  
has not seen Haskell before to someone who can read Haskell core code  
and tackle FFI and networking in a heavily concurrent environment. I  
still don't know what "the right thing" is.

The Erlang rewrite should take me 2-3 days with FFI being the teeth-
grinding bit. I need the FFI (which totally sucks compared to  
Haskell's) because my use of SSL and ZLib is non-standard, otherwise  
these are already provided to you. I expect that the app will just  
work. No memory or time leaks. The serialization approach that I'm  
using is based on the pickler combinators but slightly different. I  
think I'll backport it to Haskell to compare.

The next project on my plate is real-time collusion detection in  
poker. I first thought of using the Dazzle approach and Bayesian  
networks but the focus again seems to be on high-throughput  
networking and scalability. What language will I use? Haskell is no  
sure bet.

A disclaimer for those who might think that I'm a newbit  
disillutioned with Haskell... I totally love Haskell, it just seems  
that you need to be a guru to do what I'm trying to do and I have not  
yet reached this status. I will not rest until I'm able to see just  
_what_ kind of a performance can be squeezed from Haskell for my  
application. I'll also continue to seek enlightenment but I need to  
finish this project before New Year's.

        Joel

--
http://wagerlabs.com/

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

Re: Haskell Speed

Peter Simons
In reply to this post by Tomasz Zielonka
Tomasz Zielonka writes:

 >> wc :: String -> (Int, Int, Int)
 >> wc file = ( length (lines file)
 >>           , length (words file)
 >>           , length file
 >>           )
 >
 > I have a crazy idea: what if we computed all three length
 > applications concurrently, with the RTS preempting the
 > thread when it generates too much unreclaimable nodes?

That's a pretty good idea, actually. What is the state of
the 'par' primitive in GHC 6.x? Now that I think of it, it
seems that adding a proper "compute in parallel" annotation
could make a big difference in this case.

Peter

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

Re: Haskell vs. Erlang for heavy-duty network apps (was Re: Haskell Speed)

Tomasz Zielonka
In reply to this post by Joel Reymont
On Sun, Dec 25, 2005 at 12:20:38PM +0000, Joel Reymont wrote:
> A disclaimer for those who might think that I'm a newbit  
> disillutioned with Haskell... I totally love Haskell, it just seems  
> that you need to be a guru to do what I'm trying to do and I have not  
> yet reached this status.

I am pleased to hear this. I would love to be able to help you more
often, alas my job was very time demanding recently (but quite rewarding
too :-). And we have Christmas right now.

I think your work will be very important and valuable for the community.
You've shown were Haskell could be better, and I believe it will catch
up eventually, either by improvements in GHC, in libraries or simply
in documentation.

Merry Christmas!
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell vs. Erlang for heavy-duty network apps

Joel Reymont

On Dec 25, 2005, at 1:14 PM, Tomasz Zielonka wrote:

> I think your work will be very important and valuable for the  
> community.
> You've shown were Haskell could be better, and I believe it will catch
> up eventually, either by improvements in GHC, in libraries or simply
> in documentation.

Thank you Tomasz! I think eventually will come sooner than you  
think :-).

On my TODO list for the next few weeks:

1) Set up a Haskell vs. Erlang heavily-multithreaded serialization  
shootout
2) Work Simon M. to make sure Haskell is on par and try to hack GHC  
to add whatever is needed
3) Add profiling support for STM to GHC (including retainer profiling)
4) Adapt the Zipper FileServer OS to #1. See if single-threading with  
delimited continuations is better than multi-threading with unbound  
threads.
5) If #4 is a yes then investigate why

And of course I will blog about the whole thing as I go along.

        Thanks, Joel

--
http://wagerlabs.com/





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

RE: Haskell vs. Erlang for heavy-duty network apps (wasRe: Haskel

Branimir Maksimovic-2
In reply to this post by Joel Reymont



>From: Joel Reymont <[hidden email]>
>To: Bulat Ziganshin <[hidden email]>
>CC: Peter Simons <[hidden email]>, [hidden email]
>Subject: [Haskell-cafe] Haskell vs. Erlang for heavy-duty network apps
>(wasRe: Haskell Speed)
>Date: Sun, 25 Dec 2005 12:20:38 +0000
>
>
>On Dec 25, 2005, at 10:13 AM, Bulat Ziganshin wrote:
>
>>Hello Joel,
>>[...]
>>so i think that your problems is due to bad design decisions caused by
>>lack of experience. two weeks ago when you skipped my suggestions
>>about improving this design and answered that you will use "systematic
>>approach", i foresee that you will fail and say that Haskell is a bad
>>language
>
>Yes and no. The systematic approach that I used was profiling the  
>serialization code and tweaking all that I could. I saved my  profiling
>reports after each run and tracked the changes that I made.  I will blog
>about it after Simon M. comes back and suggests how to  squeeze the last
>bit out of it.
>
>Regardless of this, it looks to me like I could easily have around  4Mb of
>network traffic per second with about 4k threads and  complicated nested
>structures to serialize and deserialize. Trying to  tackle far less data
>suggests to me that it's not gonna happen. So I  will try to take this as
>far as I can in Haskell, once I have the  heavy artillery to back me up. If
>the results are good then I will  use them in later applications of the
>same nature but in the meantime  I'm rewriting this particular app in
>Erlang.

Sounds familiar ?:)
http://www.jetcafe.org/~npc/doc/euc00-sendmail.html
Similar experience with Erlang about 5 years ago :0)

Greetings, Bane.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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

Re: Haskell vs. Erlang for heavy-duty network apps (was Re: Haskell Speed)

Joel Reymont
In reply to this post by Tomasz Zielonka
If anyone is interested, I posted the Erlang version of the pickler  
combinators at http://wagerlabs.com/erlang/pickle.erl

Orignal paper at http://research.microsoft.com/~akenn/fun/ 
picklercombinators.pdf

Notice that I did away with the "sequ" while preserving "wrap" and  
friends. Erlang does not have enums so I added support for those.

I did not test the performance of this code yet. I used the "most  
natural way of doing things", though, and I expect performance to be  
excellent. I'm most interested in whether it's possible to get the  
performance of the Haskell version on par with this one.

        Thanks, Joel

--
http://wagerlabs.com/



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

Re: Re: Haskell Speed

Paul Moore-2
In reply to this post by Peter Simons
On 25 Dec 2005 12:24:38 +0100, Peter Simons <[hidden email]> wrote:

> Paul Moore writes:
>
>  > It would be interesting to see standalone code for wcIOB
>  > (where you're allowed to assume that any helpers you
>  > need, like your block IO library, are available from the
>  > standard library). This would help in comparing the
>  > "obviousness" of the two approaches.
>
> A simple version of the program -- which doesn't need any
> 3rd party modules to compile -- is attached below. My guess
> is that this approach to I/O is quite obvious, too, if you
> have experience with system programming in C.

Hmm, I can't honestly believe that you feel that your code is as
"obvious" as the original. I'm not unfamiliar with monads and state,
and I know C well, but it took me a significant amount of time to
decipher your code (even knowing what it was intended to do), whereas
I knew what the original was doing instantly.

> IMHO, the main point of the example in the article is that
>
>   wc :: String -> (Int, Int, Int)
>   wc file = ( length (lines file)
>             , length (words file)
>             , length file
>             )
>
> is a crapy word-counting algorithm.

Dunno. It's certainly not a bad (executable!) definition of the
problem. My point is that Haskell allows me to write *very* clear
"executable pseudocode", but that code is not a good starting point
for writing production-quality code.

To me, the point of the original article was to demonstrate how to get
from the original version to an efficient version, in reasonable
steps. I'm not sure how well it achieved that - particularly as the
final code didn't clearly (to me) separate out standard libraries,
supporting (but non-standard) libraries, and application code. But the
article was specifically noted to be incomplete by the author, so
that's not unsurprising.

> I'm not sure whether
> conclusions about functional programming in general or even
> programming in Haskell can be derived from this code. Most
> people seem to have trouble with lazy-evaluation, first of
> all.

The biggest conclusion to me is that techniques for *readable* and
"obvious" code in Haskell differ significantly from techniques for
efficient code. I think that conclusion is not isolated to this one
specific example...

Back to where this came from, my view is that this is an education
issue - tutorials tend to focus on lazy, functional techniques, and
not on efficiency. This is true for C (or any other language)
tutorials as well, but in languages where the step from naive to
efficient code isn't as large, it's not such an issue (mailing list
questions in C or Java about "my code isn't fast enough" tend to
result in advice on fairly comprehensible tweaks that can be made; in
Haskell, they tend to result in monadic rewrites which bear little
relationship to the original code - so the original poster hasn't got
much chance of understanding what happened...)

But the material is available, so people *can* learn. It just needs
some effort (but possibly more than it should...)

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

Re: Re: Haskell Speed

Jared Updike
> Back to where this came from, my view is that this is an education
> issue - tutorials tend to focus on lazy, functional techniques, and
> not on efficiency.

> But the material is available, so people *can* learn. It just needs
> some effort (but possibly more than it should...)

Can anyone suggest some good tutorials, papers, or books to read for
learning how to reason about laziness, specifically, time and space
complexity? I seem to remember that Richard Bird's Introduction to
Functional Programming book has a chapter or so on this subject, but
what other material would anyone recommend for trying to understand
how to write efficient, lazy algorithms? Maybe in the spirit of
updating Wikis and such, we can collect this sort of material
together...

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

Re: Re: Haskell Speed

Branimir Maksimovic-2
In reply to this post by Daniel Carrera-2
Paul Moore wrote:

> On 25 Dec 2005 12:24:38 +0100, Peter Simons <[hidden email]> wrote:
>
>>Paul Moore writes:
>>
>> > It would be interesting to see standalone code for wcIOB
>> > (where you're allowed to assume that any helpers you
>> > need, like your block IO library, are available from the
>> > standard library). This would help in comparing the
>> > "obviousness" of the two approaches.
>>
>>A simple version of the program -- which doesn't need any
>>3rd party modules to compile -- is attached below. My guess
>>is that this approach to I/O is quite obvious, too, if you
>>have experience with system programming in C.
>
>
> Hmm, I can't honestly believe that you feel that your code is as
> "obvious" as the original. I'm not unfamiliar with monads and state,
> and I know C well, but it took me a significant amount of time to
> decipher your code (even knowing what it was intended to do), whereas
> I knew what the original was doing instantly.
>
>
>>IMHO, the main point of the example in the article is that
>>
>>  wc :: String -> (Int, Int, Int)
>>  wc file = ( length (lines file)
>>            , length (words file)
>>            , length file
>>            )
>>
>>is a crapy word-counting algorithm.
>
>
> Dunno. It's certainly not a bad (executable!) definition of the
> problem. My point is that Haskell allows me to write *very* clear
> "executable pseudocode", but that code is not a good starting point
> for writing production-quality code.

this program counts two times length of lists of strings formed by
lines, and words and third time counts again length of file.
This is not just word counting program, it creates two additional lists,
which are not used anywhere but to count :)
While it is certainly expressive, in terms of programing is pointless.
No one would write such a code for word counting.

Here is what I would write in Haskell, same logic as in C++
(i don;t know standard lib ):

module Main where
import IO
import Char

main = do s <- hGetContents stdin
           putStrLn $ show $ wc s

wc :: String -> (Int , Int , Int)
wc strs = wc' strs (0,0,0)
         where wc' [] res = res
               wc' (s:str) (lns, wrds, lngth )
                   | s == '\n' =  wc' str (lns+1,wrds, lngth+1)
                   | isAlpha s = wc'' str (lns, wrds+1,lngth+1)
                   | otherwise = wc' str (lns,wrds, lngth+1)
               wc'' [] res = res
               wc'' (s:str) (lns,wrds,lngth)
                    = if isAlphaNum s
                         then wc'' str (lns,wrds,lngth+1)
                         else wc' str (lns,wrds, lngth+1)


Greetings, Bane.

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

Re: Re: Haskell Speed

Branimir Maksimovic-2



>From: Branimir Maksimovic <[hidden email]>

>
>module Main where
>import IO
>import Char
>
>main = do s <- hGetContents stdin
>           putStrLn $ show $ wc s
>
>wc :: String -> (Int , Int , Int)
>wc strs = wc' strs (0,0,0)
>         where wc' [] res = res
>               wc' (s:str) (lns, wrds, lngth )
>                   | s == '\n' =  wc' str (lns+1,wrds, lngth+1)
>                   | isAlpha s = wc'' str (lns, wrds+1,lngth+1)
>                   | otherwise = wc' str (lns,wrds, lngth+1)
>               wc'' [] res = res
>               wc'' (s:str) (lns,wrds,lngth)
>                    = if isAlphaNum s
>                         then wc'' str (lns,wrds,lngth+1)
>                         else wc' str (lns,wrds, lngth+1)
>
>
err, I've tested windows file on unix :)

              wc'' strs@(s:str) (lns,wrds,lngth)
                   = if isAlphaNum s
                        then wc'' str (lns,wrds,lngth+1)
                        else wc' strs (lns,wrds, lngth)


>Greetings, Bane.
>

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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

Re: Re: Haskell Speed

Paul Moore-2
In reply to this post by Branimir Maksimovic-2
On 12/26/05, Branimir Maksimovic <[hidden email]> wrote:

> Paul Moore wrote:
> > Dunno. It's certainly not a bad (executable!) definition of the
> > problem. My point is that Haskell allows me to write *very* clear
> > "executable pseudocode", but that code is not a good starting point
> > for writing production-quality code.
>
> this program counts two times length of lists of strings formed by
> lines, and words and third time counts again length of file.
> This is not just word counting program, it creates two additional lists,
> which are not used anywhere but to count :)
> While it is certainly expressive, in terms of programing is pointless.
> No one would write such a code for word counting.
>
> Here is what I would write in Haskell, same logic as in C++
> (i don;t know standard lib ):

Yes, that is a very reasonable way of improving performance. The
original algorithm, as you say, does 3 passes through the file, and
this does one, computing the 3 values "in parallel". So it does seem a
sensible next step. I must try timings to see how much this improves
the timings, and how much further there is to go :-)

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

Re: Re: Haskell Speed

Tomasz Zielonka
In reply to this post by Paul Moore-2
On Mon, Dec 26, 2005 at 11:58:52AM +0000, Paul Moore wrote:
> My point is that Haskell allows me to write *very* clear "executable
> pseudocode", but that code is not a good starting point for writing
> production-quality code.

It is often a good start, but not always a good end ;-)

Recently, I have written some code to do something we previously thought
would be impractical because of unacceptable performance. I did it in
Haskell in the most obvious way I could. It works, because Haskell helps
me to look at the problem itself and solve efficiency problems in the
big picture, not only in the details.

> > I'm not sure whether conclusions about functional programming in
> > general or even programming in Haskell can be derived from this
> > code. Most people seem to have trouble with lazy-evaluation, first
> > of all.
>
> The biggest conclusion to me is that techniques for *readable* and
> "obvious" code in Haskell differ significantly from techniques for
> efficient code. I think that conclusion is not isolated to this one
> specific example...

That's not my experience. I have often been surprised that I was
able to transform the "obvious", inefficient code into an efficient
version in a short sequence of small steps. The best way to do this is
to first modularize the code, splitting it to smaller functions, perhaps
introducing some type-classes, non-IO monads, etc. If you know what you
are doing, you can later optimize the code locally, modularly.

Also, you say that "monadic rewrites bear little relationship to the
original code". I often start writing my *pure* code in monadic
form, so I have this problem much less often.

A good intro to modularizing functional programs is in the "Why
Functional Programming Matters" article:
    http://www.md.chalmers.se/~rjmh/Papers/whyfp.html
I've read it when I was learning Haskell a couple of years ago, but now
I know I didn't get it back then. When I read it again this week and
compared it to my experiences, I thought "Wow, this man knows what he's
taking about!". I daresay that if you don't say something like "Wow"
while reading the article, then you didn't get it ;-)

> Back to where this came from, my view is that this is an education
> issue - tutorials tend to focus on lazy, functional techniques, and
> not on efficiency.

If you want to focus on efficiency from the start, you write an
assembler tutorial ;-)

Well, you have some point. We need "Efficient Haskell" tutorials, for
people who have already gone through basic tutorials. I think there even
is one or two.

> This is true for C (or any other language) tutorials as well, but in
> languages where the step from naive to efficient code isn't as large,
> it's not such an issue (mailing list questions in C or Java about "my
> code isn't fast enough" tend to result in advice on fairly
> comprehensible tweaks that can be made;

On the other hand, in those languages it is often difficult to
write high level, specification-like code. No wonder the step is
so small ;-)

> in Haskell, they tend to result in monadic rewrites which bear little
> relationship to the original code - so the original poster hasn't got
> much chance of understanding what happened...)

You don't have that problem, if your obvious code is monadic (not
neccesarily IO!) from the start ;-)

Best regards
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Haskell Speed

Tomasz Zielonka
In reply to this post by Branimir Maksimovic-2
On Mon, Dec 26, 2005 at 09:10:56PM +0100, Branimir Maksimovic wrote:
> this program counts two times length of lists of strings formed by
> lines, and words and third time counts again length of file.
> This is not just word counting program, it creates two additional lists,
> which are not used anywhere but to count :)
> While it is certainly expressive, in terms of programing is pointless.
> No one would write such a code for word counting.

Come on! Sometimes the only thing you want is a simple, *correct*
solution for the problem, for example just to test the ugly,
efficient version.

Best regards
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Haskell Speed

haskell-2
In reply to this post by Paul Moore-2
Paul Moore wrote:

> On 12/26/05, Branimir Maksimovic <[hidden email]> wrote:
>
>>Paul Moore wrote:
>>
>>>Dunno. It's certainly not a bad (executable!) definition of the
>>>problem. My point is that Haskell allows me to write *very* clear
>>>"executable pseudocode", but that code is not a good starting point
>>>for writing production-quality code.
>>
>>this program counts two times length of lists of strings formed by
>>lines, and words and third time counts again length of file.
>>This is not just word counting program, it creates two additional lists,
>>which are not used anywhere but to count :)
>>While it is certainly expressive, in terms of programing is pointless.
>>No one would write such a code for word counting.
>>
>>Here is what I would write in Haskell, same logic as in C++
>>(i don;t know standard lib ):
>
>
> Yes, that is a very reasonable way of improving performance. The
> original algorithm, as you say, does 3 passes through the file, and
> this does one, computing the 3 values "in parallel". So it does seem a
> sensible next step. I must try timings to see how much this improves
> the timings, and how much further there is to go :-)
>
> Thanks,
> Paul.
> _______________________________________________
> 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: Haskell Speed

Isaac Gouy-2
In reply to this post by Daniel Carrera-2
Simon Marlow wrote:
> Also, I would like to draw your attention to the
fact that GHC
> wipes the floor with nearly everyone in the
concurrency
> benchmark

SmartEiffel is so much faster that I'm still trying to
figure out if it's doing something different :-)

Be interesting to see GHC on the other concurrency
benchmark...
http://shootout.alioth.debian.org/benchmark.php?test=chameneos&lang=all

> Seriously, it's very difficult to draw any
meaningful
> conclusions from these benchmarks.

Is it any easier to draw meaningful conclusions about
the relative performance of programming languages from
some other benchmarks?



               
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com

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

Re: Haskell Speed

Isaac Gouy-2
In reply to this post by Daniel Carrera-2
Jared Updike wrote:

> What that means is the results are completely
subject to
> (1) how good the submission for that tests was

Contribute faster more-elegant programs
http://shootout.alioth.debian.org/gp4/faq.php#contribute

>(2) the choice of tests in the first place

Suggest better tests
http://shootout.alioth.debian.org/gp4/faq.php#newbench

> (3) startup times for loading the binaries into
memory (GHC
> makes big binaries that are arguably much faster if
you do
> things in "daemon" mode, for example).

Is that just speculation? (Erlang is an application
server starting-up and that really is noticeable.)

-snip-
> it is pretty much a game created to make C win---it
already
> wins!

Which C do you mean - gcc, Intel C, Tiny C?

And, no! It is not a game created to make C win
(although it is a
game).

And, no! C does not already win all the games -
astonishingly it
doesn't even "win" the basic loop and array test
nsieve.



               
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com

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

Re: Haskell Speed

Isaac Gouy-2
In reply to this post by Daniel Carrera-2
Branimir Maksimovic wrote:
> Of course, first example uses [String] instead of
Data.HashTable
> as other languages do. Imagine C program does not
use
> hash,rather list, how it will perform:)

And the author comments his program
-- This is a purely functional solution to the
problem.
-- An alternative which keeps a mutable table of
occurences would
-- be faster.

We'll be happy to also show a Haskell program that
uses Data.HashTable - first, someone needs to
contribute that program.


> I didn't look further after that.

Ideal - you may criticize without the risk that others
will criticize what you do.


       
               
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Haskell vs. Erlang for heavy-duty network apps

Simon Peyton Jones
In reply to this post by Joel Reymont
I've already said to Joel (off-list) how valuable I think his experience
of using Haskell for a new kind of real application is.  I see no reason
in principle why Haskell shouldn't work just fine for his kind of
application.  But he's pushing hard on parts of the system (both
run-time-system and libraries) that have not been as thoroughly
exercised as (say) list processing.

Quite a few people on the mailing list have helped a lot.  My sense is
(though I have not followed all the twists and turns) that Joel's
experience has exposed immaturity in many of the networking libraries.
I hope that people on this list may feel motivated to help improve them.

Simon

| -----Original Message-----
| From: [hidden email]
[mailto:[hidden email]] On Behalf Of Joel
| Reymont
| Sent: 25 December 2005 13:35
| To: Tomasz Zielonka
| Cc: [hidden email]; Peter Simons; Bulat Ziganshin
| Subject: Re: [Haskell-cafe] Haskell vs. Erlang for heavy-duty network
apps
|
|
| On Dec 25, 2005, at 1:14 PM, Tomasz Zielonka wrote:
|
| > I think your work will be very important and valuable for the
| > community.
| > You've shown were Haskell could be better, and I believe it will
catch
| > up eventually, either by improvements in GHC, in libraries or simply
| > in documentation.
|
| Thank you Tomasz! I think eventually will come sooner than you
| think :-).
|
| On my TODO list for the next few weeks:
|
| 1) Set up a Haskell vs. Erlang heavily-multithreaded serialization
| shootout
| 2) Work Simon M. to make sure Haskell is on par and try to hack GHC
| to add whatever is needed
| 3) Add profiling support for STM to GHC (including retainer profiling)
| 4) Adapt the Zipper FileServer OS to #1. See if single-threading with
| delimited continuations is better than multi-threading with unbound
| threads.
| 5) If #4 is a yes then investigate why
|
| And of course I will blog about the whole thing as I go along.
|
| Thanks, Joel
|
| --
| http://wagerlabs.com/
|
|
|
|
|
| _______________________________________________
| 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
123