Hello ls-haskell-developer-2006,
Tuesday, December 19, 2006, 9:32:13 PM, you wrote:
why you (and Donald) don't want to understand me. i say that imperative
Haskell code is more efficient
Second: Bulat, I think your generalization is, that performance
matters so much and all the time
i
Hello Andy,
Tuesday, December 19, 2006, 12:35:28 AM, you wrote:
and concluded that there are only 2 tasks which speed is dependent on
Maybe it would not be a bad idea to check the number of cache misses,
branch mispredictions etc. per instruction executed for the shootout
apps, in
Hello Neil,
Monday, December 18, 2006, 11:04:59 PM, you wrote:
let's go further in this long-term discussion. i've read Shootout problems
It's more than 2 tasks that are dependant on the code generated by the
compiler.
can you give me their names, please? :)
And in my opinion, generally
Hello Tomasz,
Tuesday, December 19, 2006, 2:11:37 AM, you wrote:
no. it seems that you never tried to write such code and believe someone
else who's said that such code may be written. try to write something very
simple, like summing bytes in memory buffer, before you will do any
conclusions
why you (and Donald) don't want to understand me. i
say that imperative
Haskell code is more efficient than pure (and
especially lazy) one and that
even such code in ghc is slower than C equivalent.
I think the concern about execution speed of
algorithms is a fairly recent topic. At least,
Hello Tomasz,
Tuesday, December 19, 2006, 3:19:52 PM, you wrote:
why you (and Donald) don't want to understand me. i say that imperative
Haskell code is more efficient
Your statement is too general to deserve answering.
can you provide couter-examples, or just believe? i mean
Hello Simon,
Monday, December 18, 2006, 12:08:49 PM, you wrote:
My view is that Haskell's performance is very seldom the limiting factor
of course. when someone said about GPG i just mentioned that this project
may be hihgly speed-dependent and this case Haskell is definitely not the
solution
Hello ajb,
Monday, December 18, 2006, 4:12:01 AM, you wrote:
time. For example, for certain types of problem, Haskell minimises the
amount of time between the point where I start typing and the point where
I have the answer.
of course, we can fool any topic by changing the names. no one
Hello Henning,
Monday, December 18, 2006, 4:46:16 PM, you wrote:
Very true. I really like to know some more clean tricks for speedup.
use C. seriously :)
you can look into sources of FPS and Streams libs, speed-optimized parts
are written in the imperative way and all that you can do in
On 12/18/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Simon,
Monday, December 18, 2006, 12:08:49 PM, you wrote:
My view is that Haskell's performance is very seldom the limiting factor
of course. when someone said about GPG i just mentioned that this project
may be hihgly
10 matches
Mail list logo
