Sebastian Sylvan wrote:
On 10/07/07, Andrew Coppin [EMAIL PROTECTED] wrote:
Hint: If you can get readable/maintainable Haskell to run on more than
one core automatically, you're onto something pretty special. ;-)
Soon, have a little patience :-)
See for example:
Hello Jon,
Sunday, July 15, 2007, 9:46:42 PM, you wrote:
This should tell you that your C++ is not very good. This is several times
faster, for example:
For some reason you were using C-style allocation rather than the C++ STL to
implement a bit vector. The STL implementation is optimized.
On 16/07/07, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Sebastian,
Sunday, July 15, 2007, 9:05:14 PM, you wrote:
As we've demonstrated there's nothing stopping you from writing
imperative C-like algorithms in Haskell (just like C#), and there
certainly wasn't any major performance
Hello Sebastian,
Sunday, July 15, 2007, 9:05:14 PM, you wrote:
As we've demonstrated there's nothing stopping you from writing
imperative C-like algorithms in Haskell (just like C#), and there
certainly wasn't any major performance difference
as Donald mentioned, this test is just limited by
Hello Sebastian,
Monday, July 16, 2007, 2:53:36 PM, you wrote:
But wouldn't you say that in general, if you spend the effort you can
write low-level imperative algorithms in Haskell that perform
reasonably well? Especially compared to e.g. C#? I think your own
libraries demonstrate this!
On Mon, 2007-07-16 at 11:53 +0100, Sebastian Sylvan wrote:
On 16/07/07, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Sebastian,
Sunday, July 15, 2007, 9:05:14 PM, you wrote:
As we've demonstrated there's nothing stopping you from writing
imperative C-like algorithms in Haskell
Ah, the secret of Haskell is to make low-level-looking code run slower
than high level code so that people write high-level code.
The secret of programming is to know which tools to use for which job.
If you're writing device drivers in Visual Basic, you've made a
strategic misstep and need
On Mon, 2007-07-16 at 17:41 +0100, Martin Coxall wrote:
Ah, the secret of Haskell is to make low-level-looking code run slower
than high level code so that people write high-level code.
The secret of programming is to know which tools to use for which job.
If you're writing device
On 16/07/07, Derek Elkins [EMAIL PROTECTED] wrote:
On Mon, 2007-07-16 at 17:41 +0100, Martin Coxall wrote:
Ah, the secret of Haskell is to make low-level-looking code run slower
than high level code so that people write high-level code.
The secret of programming is to know which tools
On 16/07/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 16/07/07, Derek Elkins [EMAIL PROTECTED] wrote:
On Mon, 2007-07-16 at 17:41 +0100, Martin Coxall wrote:
Ah, the secret of Haskell is to make low-level-looking code run slower
than high level code so that people write high-level
Well they've been written in both Haskell[1], and C#[2], so VB might
not be out of the realm of possibility (in fact, I think any language
that compiles to CIL is fine for [2])!
Ah, but that's really VB.Net rather than proper Old School VB. VB.Net
is just C# in a flowery frock.
My point
Sebastian,
Why would I write a slow, complicated algorithm in C#?
I'm not making these comparisons for some academic paper, I'm trying to get
a feel for how the languages run in practice.
And really in practice, I'm never going to write a prime algorithm using
merge and so on, I'd just use the
hughperkins:
Sebastian,
Why would I write a slow, complicated algorithm in C#?
I'm not making these comparisons for some academic paper,
I'm trying to get a feel for how the languages run in
practice.
And really in practice, I'm never going to write a prime
algorithm
Hey, guys, I just realized this test is not really fair!
I've been using the Microsoft .Net compiler ,which is a proprietary
closed-source compiler.
To be fair to Haskell, we should probably compare it to other open source
products, such as g++ and mono?
Here are the timings ;-)
Haskell
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
Sebastian,
Why would I write a slow, complicated algorithm in C#?
I'm not making these comparisons for some academic paper, I'm trying to get
a feel for how the languages run in practice.
And really in practice, I'm never going to write a
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
[me thinks he doth protest too much] ;-)
The rules of the competition are quite fair: both sides make an optimal
algorithm using their preferred language. It's ok to hardcode the first 3
or 4 primes if you must, hardcoding the entire
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
[me thinks he doth protest too much] ;-)
The rules of the competition are quite fair: both sides make an optimal
algorithm using their preferred language. It's ok to hardcode the first 3
or
hughperkins:
Hey, guys, I just realized this test is not really fair!
I've been using the Microsoft .Net compiler ,which is a
proprietary closed-source compiler.
To be fair to Haskell, we should probably compare it to
other open source products, such as g++ and mono?
Here
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
[snip] unsafeWrite[snip]
[snip]unsafeRead[snip]
Hi Donald, the idea is to use this for operational code, so avoiding unsafe
operations is preferable ;-) You'll note that the C# version is not using
unsafe operations, although to be
hughperkins:
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED]
wrote:
[snip] unsafeWrite[snip]
[snip]unsafeRead[snip]
Hi Donald, the idea is to use this for operational code, so
avoiding unsafe operations is preferable ;-) You'll note
that the C# version is not
On 15/07/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
hughperkins:
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED]
wrote:
[snip] unsafeWrite[snip]
[snip]unsafeRead[snip]
Hi Donald, the idea is to use this for operational code, so
avoiding unsafe operations is
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
What C# version are you using, by the way? (So I can check if it does
any tricks).
- csc is in the Microsoft.Net Framework 2.0 runtime, which you can download
from microsoft.com (free download).
- gmcs/mono are from Mono 1.2.2.1 ,
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
unsafe' here just means direct array indexing. Same as the other
languages. Haskell's 'unsafe' is a little more paranoid that other
languages.
Yes, I was kindof hoping it was something like that. Cool :-)
Since the goal is to flip
On 7/15/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
unsafe' here just means direct array indexing. Same as the other
languages. Haskell's 'unsafe' is a little more paranoid that other
languages.
Yes, I was kindof hoping it was
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
unsafe' here just means direct array indexing. Same as the other
languages. Haskell's 'unsafe' is a little more paranoid that other
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
Well, *I* didn't say it but yes. Unsafe disables bounds checking
(which in this case is safe). I think you can just stick an unsafe{}
in the C# version to disable them.
Oh well that's not good. Yes, you can use unsafe in C# too, but you
Hey, I just realized I can shave off another 30% in C# ;-)
So now the timings become:
Safe Haskell
=
J:\dev\haskellghc -O2 -o primechaddai.exe PrimeChaddai.hs
J:\dev\haskellprimechaddai
number of primes: 664579
Elapsed time: 26.234
Unsafe Haskell
===
J:\dev\haskellghc
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
Hey, I just realized I can shave off another 30% in C# ;-)
So now the timings become:
Safe Haskell
=
J:\dev\haskellghc -O2 -o primechaddai.exe PrimeChaddai.hs
J:\dev\haskellprimechaddai
number of primes: 664579
Elapsed time: 26.234
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
I don't see what the point of this is? Why do timings of different
algorithms? Of course you could do the same optimization in any
language, so why do you think it's relevant to change the algorithm in
*one* of the languages and then make
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
I don't see what the point of this is? Why do timings of different
algorithms? Of course you could do the same optimization in any
language, so why do you think it's relevant to change the
hughperkins:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED]
wrote:
I don't see what the point of this is? Why do timings of
different
algorithms? Of course you could do the same optimization
in any
language, so why do you think it's relevant to change the
On 15/07/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
I don't see what the point of this is? Why do timings of different
algorithms? Of course you could do the same optimization in any
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
In this case it is fine. You're setting bits in the cache. Please use the
same algorithm, or any conclusions are meaningless.
No, I'm counting prime numbers. Somewhat faster it seems ;-)
Let's put this into the real world a moment.
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
My GHC compiler is broken, I only have GHCi, but this is about twice
for me as fast as the previous version you benchmarked, btw.
Hi Sebastian,
Here are the results:
Haskell (Safe Haskell right?)
==
J:\dev\haskellghc -fglasgow-exts
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
[Argh, no way can a Microsoft language be better than Haskell]
Well, if you scan higher in the thread, there are two benchmarks. The prime
numbers benchmark was a simple 10 minute benchmark to compare the
computational speed (something
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
[Argh, no way can a Microsoft language be better than Haskell]
Well, if you scan higher in the thread, there are two benchmarks. The prime
numbers benchmark was a simple 10 minute
hughperkins:
Hey, I just realized I can shave off another 30% in C# ;-)
So now the timings become:
Ok. So do the same thing to the Haskell program. The compilers should
produce pretty much identical assembly.
{-# OPTIONS -O2 -optc-O -fbang-patterns #-}
import Control.Monad.ST
On 15/07/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
hughperkins:
Hey, I just realized I can shave off another 30% in C# ;-)
So now the timings become:
Ok. So do the same thing to the Haskell program. The compilers should
produce pretty much identical assembly.
{-# OPTIONS
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
Surely you can remove the read here, and just always do the write?
Ah you'd think so, but if it's anything like the C# version, strangely that
would be slower. In his last message Don explains that this is because the
write dirties the
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
Surely you can remove the read here, and just always do the write?
Ah you'd think so, but if it's anything like the C# version, strangely that
would be slower. In his last message Don
dons:
hughperkins:
Hey, I just realized I can shave off another 30% in C# ;-)
So now the timings become:
Ok. So do the same thing to the Haskell program. The compilers should
produce pretty much identical assembly.
Oh, and I forgot you count up by two now. Here's the Haskell
dons:
dons:
hughperkins:
Hey, I just realized I can shave off another 30% in C# ;-)
So now the timings become:
Ok. So do the same thing to the Haskell program. The compilers should
produce pretty much identical assembly.
Oh, and I forgot you count up by two now.
On 15/07/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
dons:
dons:
hughperkins:
Hey, I just realized I can shave off another 30% in C# ;-)
So now the timings become:
Ok. So do the same thing to the Haskell program. The compilers should
produce pretty much identical
On 15/07/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
Oh! Much faster. Looks like Haskell is 100x faster than C#.
Who gets fired? :)
Well, you've switched back to using unsafe operations there, Donald ;-)
Anyway, before you guys get too narked at me ;-) I'd just like to say that
I'm
Hello Chaddai,
Sunday, July 15, 2007, 3:31:12 AM, you wrote:
Due to the nature of Haskell, it's not so easy to do the same thing
(write a C program in Haskell as you wrote a C program in C#), so the
conclusion is obviously to Haskell disadvantage.
it's possible to directly rewrite C code in
On Jul 15, 2007, at 7:53 , Sebastian Sylvan wrote:
Still, I think youre methodology sucks. If you want to compare
languages you should implement the same algorithm. (...)
If this is about comparing languages, you should compare them fairly.
But is it comparing them fairly if you use an
On Jul 15, 2007, at 8:45 , Donald Bruce Stewart wrote:
main = print $( let x = pureSieve 1000 in [| x |] )
I'm reminded of the C++ expert in CMU SCS who used to amuse himself
by making template expansion do all the real work at compile time.
(Yes, including a prime sieve.)
--
On Sun, 15 Jul 2007 14:15:03 +0200, you wrote:
...a simple 10 minute benchmark to compare the computational speed...
We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.
- Donald Knuth (paraphrasing Tony Hoare)
Haskell is about
Brandon wrote:
Seems to me you get the best picture by picking two algorithms, one
which favors C# and one which favors Haskell, and implementing both
in both languages.
Sounds good to me. What is a good problem that favors Haskell?
___
hughperkins:
Brandon wrote:
Seems to me you get the best picture by picking two
algorithms, one
which favors C# and one which favors Haskell, and
implementing both
in both languages.
Sounds good to me. What is a good problem that favors
Haskell?
NO. We just
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
However, if you're keen, and agreeing to implement the same algorithm on
both systems,
Sorry, the rule is you use what's available in your chosen language,
otherwise I have to restrict myself only to use things available in Haskell,
Hello Donald,
Sunday, July 15, 2007, 8:22:33 PM, you wrote:
usually 2-4x slower. Really poor at lightweight concurrency.
both systems, I'd have a go in C# at 'chameneos', a concurrency
benchmark,
shootout contains only two or three tests that compare quality of code
generated by compiler
On 7/15/07, Hugh Perkins [EMAIL PROTECTED] wrote:
I'd have a go in C# at 'chameneos', a concurrency
benchmark,
http://shootout.alioth.debian.org/gp4/benchmark.php?test=chameneoslang=all
Errr this is kindof a strange problem, the answer is always N * 2?
And there we see why I dislike
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
However, if you're keen, and agreeing to implement the same algorithm on
both systems,
Sorry, the rule is you use what's available in your chosen language,
otherwise I have to restrict
Just for laughs, here's my solution to Chameneos.
J:\dev\haskellcsc /nologo Chameneos2.cs
J:\dev\haskellchameneos2
200
elapsed time: 0
Compares quite favorably to the Haskell solution:
J:\dev\haskellghc -fglasgow-exts -O2 -o Chameneos.exe Chameneos.hs
J:\dev\haskellchameneos
200
number
Oh wait, hmmm, might have misread the question :-D
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sunday 15 July 2007 11:19:29 Hugh Perkins wrote:
Not only does mono come close to the Microsoft .Net time, both mono and
Microsoft .Net are faster than g++ ;-) and whack Haskell.
This should tell you that your C++ is not very good. This is several times
faster, for example:
#include
On 7/15/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Hugh Perkins [EMAIL PROTECTED] wrote:
I'd have a go in C# at 'chameneos', a concurrency
benchmark,
http://shootout.alioth.debian.org/gp4/benchmark.php?test=chameneoslang=all
Errr this is kindof a strange problem,
On 7/15/07, Jon Harrop [EMAIL PROTECTED] wrote:
This should tell you that your C++ is not very good. This is several times
faster, for example:
For some reason you were using C-style allocation rather than the C++ STL
to
implement a bit vector. The STL implementation is optimized.
Yes good
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
I thought the point wasn't to compare programmer's creativity, but to
compare languages?
Sebastian, you cant directly compare languages, you can only compare the
results of a pairing between developers and those languages. There's no
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
I thought the point wasn't to compare programmer's creativity, but to
compare languages?
Sebastian, you cant directly compare languages, you can only compare the
results of a pairing
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
Hi Sebastian,
There are literally thousands of problems at http://topcoder.com. I'm
totally fine with using any of these as a benchmark.
Can you find one that shows off the strengths of Haskell?
You don't think that multiple agents
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
or maybe 'pidigits', a lazy pi generator,
http://shootout.alioth.debian.org/gp4/benchmark.php?test=pidigitslang=ghcid=0
This is I/O bound, which isnt interesting, unless you really want to
benchmark I/O to console?
We can improve
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
Hi Sebastian,
There are literally thousands of problems at http://topcoder.com. I'm
totally fine with using any of these as a benchmark.
Can you find one that shows off the strengths of
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
[Lots of stuff]
Ok, Sebastian, there's such a thing as analysing products along multiple
orthogonal axes.
At no point have I claimed that C# is better at threading than Haskell, in
fact I'm pretty sure I've mostly suggested that Haskell
On 15/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
[Lots of stuff]
Ok, Sebastian, there's such a thing as analysing products along multiple
orthogonal axes.
And yet you don't seem willing to do so? Why is that? You asked for
problems where
On Sunday 15 July 2007 11:39:32 Hugh Perkins wrote:
On 7/15/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
[snip] unsafeWrite[snip]
[snip]unsafeRead[snip]
Hi Donald, the idea is to use this for operational code, so avoiding unsafe
operations is preferable ;-)
Then you should use bounds
everyone here will recognize it.
So go and register.
- Original Message -
From: Hugh Perkins
To: Sebastian Sylvan
Cc: haskell-cafe@haskell.org
Sent: Sunday, July 15, 2007 10:39 PM
Subject: Re: Re[4]: [Haskell-cafe] In-place modification
On 7/15/07, Sebastian Sylvan
On Sunday 15 July 2007 21:57:40 Sebastian Sylvan wrote:
OpenGL is mostly written in C, so most of the code will likely run the
exact same bits. It's just an interface to a C library.
Benchmarking OpenGL is certainly of little to no interest. However, showing
how easily OpenGL can be interfaced
On Sun, 2007-07-15 at 23:05 +0100, Jon Harrop wrote:
On Sunday 15 July 2007 21:57:40 Sebastian Sylvan wrote:
OpenGL is mostly written in C, so most of the code will likely run the
exact same bits. It's just an interface to a C library.
Benchmarking OpenGL is certainly of little to no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hugh Perkins wrote:
On 7/15/07, Sebastian Sylvan [EMAIL PROTECTED] wrote:
[Lots of stuff]
blah blah blah
Can we stop this rubbish before I unsubscribe? Seriously, get a clue
before propagating nonsense across the mail clients of a large audience.
On Sunday 15 July 2007 21:26:49 Sebastian Sylvan wrote:
Can you find me a list of the contests?
No. I've been staring at that site for about 15 minutes and could only find a
single challenge that was a trivial function from graph theory.
You might like this symbolic simplifier benchmark:
So no, using the form of my argument, it is NOT possible to prove
anything about Haskell -vs- C. It is ONLY possible to make claims
about Haskell *libraries* -vs- C *libraries*.
You can claim anything you like, but if you want people to believe it you'd
be best providing the code used so that
There was some discussion about prime number generators earlier this year:
http://www.haskell.org/pipermail/haskell-cafe/2007-February/022347.html
http://www.haskell.org/pipermail/haskell-cafe/2007-February/022699.html
You can find several sources there.
Met vriendelijke groet,
Henk-Jan
On 7/14/07, Henk-Jan van Tuyl [EMAIL PROTECTED] wrote:
There was some discussion about prime number generators earlier this year:
http://www.haskell.org/pipermail/haskell-cafe/2007-February/022347.html
http://www.haskell.org/pipermail/haskell-cafe/2007-February/022699.html
Ok, so using
That's over 500 times faster ;-)
... Did you really read the Haskell code ?
You're comparing two completely unrelated algorithms, talk about a
fair comparison !
Maybe a reading of
http://en.literateprograms.org/Sieve_of_Eratosthenes_(Haskell) would
help you ?
Note that you C# code algorithm
As I say, I'm not a Haskell expert, so feel free to provide a better
implementation.
On 7/15/07, Chaddaï Fouché [EMAIL PROTECTED] wrote:
... Did you really read the Haskell code ?
You're comparing two completely unrelated algorithms, talk about a
fair comparison !
Read http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf
On Sun, 2007-07-15 at 00:38 +0200, Hugh Perkins wrote:
As I say, I'm not a Haskell expert, so feel free to provide a better
implementation.
On 7/15/07, Chaddaï Fouché [EMAIL PROTECTED] wrote:
... Did you really read the Haskell
There's really a tendency in this newsgroup to point people to huge
documents, when a small copy and paste would make the answer so much more
accessible ;-)
Anyway... so reading through the paper, it looks like its using a priority
queue? Which basically is changing the algorithm somewhat
2007/7/15, Hugh Perkins [EMAIL PROTECTED]:
There's really a tendency in this newsgroup to point people to huge
documents, when a small copy and paste would make the answer so much more
accessible ;-)
I was pointing you on a document of quite honest size in my opinion,
and not really hard to
On Sun, 2007-07-15 at 00:53 +0200, Hugh Perkins wrote:
There's really a tendency in this newsgroup to point people to huge
documents, when a small copy and paste would make the answer so much
more accessible ;-)
Anyway... so reading through the paper, it looks like its using a
priority
derek.a.elkins:
On Sun, 2007-07-15 at 00:53 +0200, Hugh Perkins wrote:
There's really a tendency in this newsgroup to point people to huge
documents, when a small copy and paste would make the answer so much
more accessible ;-)
Anyway... so reading through the paper, it looks like its
Chaddai,
Unfortunately, your program doesnt work ;-)
The function needs to take a parameter, which is the upper limit on our
sieve, and return a single value, which is the number of primes in that
interval. Complex requirements I know ;-)
___
Well, I see, it is indeed very complex requirement...
Maybe you could do the very complex following operation to at least
test the speed of this implementation : let lastPrime = primes !!
17983
--
Jedaï
___
Haskell-Cafe mailing list
On 7/15/07, Derek Elkins [EMAIL PROTECTED] wrote:
Read http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf
Ok, so switched to using the Data.Map version from this paper, which looks
like a lazy, but real, version of the sieve of Arostothenes.
This does run quite a lot faster, so we're going
2007/7/15, Chaddaï Fouché [EMAIL PROTECTED]:
Well, I see, it is indeed very complex requirement...
Maybe you could do the very complex following operation to at least
test the speed of this implementation : let lastPrime = primes !!
17983
Or if you really want a function with your
(Random observation: Hmmm, strange, in the Data.Map version of primes above,
we are missing 5 primes?)
Hi Chaddai,
Your algorithm does work significantly better than the others I've posted
here :-)
So much so, that we're going for a grid of 1000 to get the timings in an
easy-to-measure
On 14/07/07, Hugh Perkins [EMAIL PROTECTED] wrote:
As I say, I'm not a Haskell expert, so feel free to provide a better
implementation.
It's not really about providing a better implementation as that
would imply that the algorithms are the same, which they are not.
You're comparing two quite
On Saturday 14 July 2007 23:45:57 Derek Elkins wrote:
Read http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf
Wow, that is a really enlightening paper. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e
On Sunday 15 July 2007 00:31:12 Chaddaï Fouché wrote:
The HaskellWiki repertory it under primes and it's at least 170
times faster than the extra-naive sieve you used in your comparison on
my computer... (I have some doubts on the accuracy of the benchmark
and System.Time at this level of
On Sun, Jul 15, 2007 at 03:39:27AM +0100, Jon Harrop wrote:
On Sunday 15 July 2007 00:31:12 Chaddaï Fouché wrote:
The HaskellWiki repertory it under primes and it's at least 170
times faster than the extra-naive sieve you used in your comparison on
my computer... (I have some doubts on the
Hello ok,
Thursday, July 12, 2007, 3:29:25 AM, you wrote:
own simple IR engine. It's really pretty simple. My model answer
in C is two separate programs, an index builder and a query engine,
and is 804 SLOC in 1075 total lines. Each year, despite our advice,
some student does it in Java.
I wrote [student code in Java twice the size of C code, 150 times
slower].
On 12 Jul 2007, at 7:04 pm, Bulat Ziganshin wrote:
using student's work, it's easy to proof that Basic is faster than
assembler (and haskell is as fast and memory-efficient as C,
citing haskell-cafe)
This completely
On 11/07/07, brad clawsie [EMAIL PROTECTED] wrote:
Yeah, and 640K should be enough for everybody... Again, the original
statement was about 20 years down the line. Go back 20 years and
people would say similar things about C (comparing it to assembly).
but one could argue that the
Hello Alex,
Wednesday, July 11, 2007, 12:25:00 AM, you wrote:
So you think we use C because we like it? :-) When this
revolutionary tool of yours arrive that compiles Haskell to PIC
devices, I'm gonna be the first to use it.
20 years ago it was hard to imagine that $30 processor may be
Hello Hugh,
Tuesday, July 10, 2007, 11:26:43 PM, you wrote:
Just a random observation: the competition for Haskell is not
really C or C++. C is basically dead; C++ is only really useful
when you dont want people to be able to read your source code.
btw, in his HOPL paper
Jon Harrop wrote:
On Tuesday 10 July 2007 21:19:42 Andrew Coppin wrote:
Hugh Perkins wrote:
Yeah I agree with this. C# totally rocks, but threading is an
unsolved problem.
I have repeatedly attempted to discover what C# actually is...
Take Java. Make it Windows only.
Sebastian Sylvan wrote:
On 10/07/07, Jon Harrop [EMAIL PROTECTED] wrote:
Both are designed for GUI and web programming, so they don't fare
well for
massive concurrency, high-performance numerics or allocation-intensive
algorithms (e.g. idiomatic functional programming).
C# 3.0 gets it a bit
On Jul 11, 2007, at 13:37 , Andrew Coppin wrote:
(Windoze-only, you say? Perhaps I misunderstood - I thought this is
what Mono is all about...)
As someone else pointed out earlier, the real power is the libraries,
which provide a complete and powerful GUI environment. Mono provides
the
Donald Bruce Stewart wrote:
allbery:
Doesn't nhc98 target embedded devices?
It's been used on embedded arm devices the size of a credit card.
1. Where on earth do you find such a device?
2. How do you run code on one?
___
1 - 100 of 140 matches
Mail list logo
