On 7/15/07, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote:
>
> Oh, and I forgot you count up by two now. Here's the Haskell
> transliteration (again).
>
>
> {-# OPTIONS -O2 -optc-O -fbang-patterns #-}
>
> import Control.Monad.ST
> import Data.Array.ST
> import Data.Array.Base
>
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:
http://research.microsoft.
On Jul 15, 1:25 pm, "Hugh Perkins" <[EMAIL PROTECTED]> wrote:
> > or maybe 'pidigits', a lazy pi generator,
> This is I/O bound, which isnt interesting, unless you really want to
> benchmark I/O to console?
a) output is redirected to /dev/null - read the FAQ
b) the I/O is cheap
delete
PiDi
> 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 s
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 writ
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 w
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 d
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 to
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" algorit
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!
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 limite
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 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 optimize
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:
ht
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hugh Perkins wrote:
> On 7/15/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote:
> [Lots of stuff]
Can we stop this rubbish before I unsubscribe? Seriously, get a clue
before propagating nonsense across the mail clients of a large audience.
"Just ign
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
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 interface
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 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 u
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 wh
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 mig
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 o
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=pidigits&lang=ghc&id=0
This is I/O bound, which isnt interesting, unless you really want to
benchmark I/O to console?
We can improv
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 inte
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 pairin
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
ab
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, 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=chameneos&lang=all
> >
> >
>
>
Errr this is kindof a
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
#inc
Nope, the answer really is 200...
http://shootout.alioth.debian.org/gp4/iofile.php?test=chameneos&lang=all&file=output
On 7/15/07, Hugh Perkins <[EMAIL PROTECTED]> wrote:
Oh wait, hmmm, might have misread the question :-D
___
Haskell-Cafe mailing l
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
Just for laughs, here's my solution to Chameneos.
J:\dev\haskell>csc /nologo Chameneos2.cs
J:\dev\haskell>chameneos2
200
elapsed time: 0
Compares quite favorably to the Haskell solution:
J:\dev\haskell>ghc -fglasgow-exts -O2 -o Chameneos.exe Chameneos.hs
J:\dev\haskell>chameneos
200
numbe
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 res
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=chameneos&lang=all
>
Errr this is kindof a strange problem, the answer is always N * 2?
And there we see why I dis
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, 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,
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
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?
___
Haskell-Cafe
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 abo
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.)
--
b
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 algori
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 i
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
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 prett
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 cou
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
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
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, 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.
{-# OPTI
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.
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 be
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 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\haskell>ghc -fglasgow-ex
On 15/07/07, Hugh Perkins <[EMAIL PROTECTED]> wrote:
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
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 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 optimizati
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 c
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 chan
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 c
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\haskell>ghc -O2 -o primechaddai.exe PrimeChaddai.hs
J:\dev\haskell>primechaddai
number of primes: 664579
Elapsed time: 26.23
Hey, I just realized I can shave off another 30% in C# ;-)
So now the timings become:
Safe Haskell
=
J:\dev\haskell>ghc -O2 -o primechaddai.exe PrimeChaddai.hs
J:\dev\haskell>primechaddai
number of primes: 664579
Elapsed time: 26.234
Unsafe Haskell
===
J:\dev\haskell>ghc -fgl
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
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 paran
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
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
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 , wh
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 ope
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# versio
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 fa
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?
>
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
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 resul
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 pr
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
==
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
>alg
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
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 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 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 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 qui
(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 rang
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 requiremen
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 goin
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
Haskell-Cafe@haskell
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 ;-)
___
Haskell-
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
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
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 r
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 compar
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 H
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 !
___
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 cou
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
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 van
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 o
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
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 Jav
On 11 Jul 2007, at 9:56 pm, Bulat Ziganshin wrote:Java comes close to
being competition, but it's slow and eats memory
never checked it myself, but people say that modern Java
implementations are as fast as C# and close to C++ speeds
People will say anything, but before believing this particu
... still talking about "In-place modification" ?
yes. in the time-honoured tradition of demonstrating
concepts by means of meta-circular arguments.
;-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/h
On Tue, 10 Jul 2007, 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.
1 - 100 of 151 matches
Mail list logo
