Hello Simon,
Thursday, January 05, 2006, 3:40:27 PM, you wrote:
SM> Sure, there's no reason why we couldn't do this. Of course, even
SM> idle Haskell processes will be ticking away in the background, so
SM> there's a reason not to make the interval too short. What do
SM> you th
Relative speed comparison below
Udo Stenzel wrote:
> Sebastian Sylvan wrote:
>
>>On 1/5/06, Chris Kuklewicz <[EMAIL PROTECTED]> wrote:
>>
>>>There is no need to beat a dead horse, though. This benchmark sets out
>>>to test fgets / atoi, and that is all. There are better benchmarks to
>>>spend t
Brent Fulgham wrote:
>
> --- Chris Kuklewicz <[EMAIL PROTECTED]>
> wrote:
>
>
>>Also about sum-file: They do not reveal what the
>>actual 8k test file contains. So there is no way
>>to reproduce the benchmark locally for testing.
>>(One can learn it totals 40, but since
>>negative numbers a
Hello
the following program fails to load in Hugs2005 with all Haskell
extensions enabled:
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-}
class (Monad m) => Stream m h where
class (Stream m h) => CharStream m h where
vGetChar :: h -> m Char
vGetContents :: h -> m String
Your "case" tweak was for an older version of Chameneos that used an
older Ch channel implementation.
But I was inspired by your improvement to use Int# instead of data
Color, and I posted a version that seems faster than the winning one
that was submitted. http://www.haskell.org/hawiki/ChameneosE
Chris Kuklewicz wrote:
Your "case" tweak was for an older version of Chameneos that used an
older Ch channel implementation.
But I was inspired by your improvement to use Int# instead of data
Color, and I posted a version that seems faster than the winning one
that was submitted. http://www.hask
On Fri, Jan 06, 2006 at 01:52:23PM +0300, Bulat Ziganshin wrote:
> the following program fails to load in Hugs2005 with all Haskell
> extensions enabled:
>
> instance (CharStream m h) => ByteStream m h where ...
> instance (ByteStream m h) => CharStream m h where ...
Looks circular to me, i.e. th
On 2006-01-06, Chris Kuklewicz <[EMAIL PROTECTED]> wrote:
> http://www.haskell.org/hawiki/ChameneosEntry
I note that
# Like the erlang entry, this uses a separate thread to match up two
# chameneos in the meeting room.
Which seems to me to be against the spirit of the benchmark, which
describes
Nice comment.
Aaron Denney wrote:
> On 2006-01-06, Chris Kuklewicz <[EMAIL PROTECTED]> wrote:
>
>>http://www.haskell.org/hawiki/ChameneosEntry
>
>
> I note that
>
> # Like the erlang entry, this uses a separate thread to match up two
> # chameneos in the meeting room.
>
> Which seems to me t
Simon Marlow wrote:
> I'm not keen on using explicit unboxed values in these benchmarks, since
> it looks so ugly. In most cases you can convince GHC to do the unboxing
> for you, and I'm pretty sure it should be the case here too. Just use
> ordinary Ints.
The syntax is not so pleasing, but it
Hello Ross,
Friday, January 06, 2006, 2:16:24 PM, you wrote:
>> the following program fails to load in Hugs2005 with all Haskell
>> extensions enabled:
>>
>> instance (CharStream m h) => ByteStream m h where ...
>> instance (ByteStream m h) => CharStream m h where ...
RP> Looks circular to me,
Hi Chris,
Rather than try to explain what I'm going on about, I decided to tweak
the code a bit myself. My version is about 10% faster than yours, and
doesn't use any explicit unboxery. I've put it in the wiki after your
version.
http://www.haskell.org/hawiki/ChameneosEntry
Could someone
Hi All,
I've been enjoying following the thread about the "shootout" programs
and trying to understand the performance of the entries, especially
the Fannkuch benchmark. I've been comparing Sebastion's and
Bertram's proposals found on the wiki. On my machine (PowerBook g4
(512M), GHC 6
On 1/6/06, David F. Place <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I've been enjoying following the thread about the "shootout" programs
> and trying to understand the performance of the entries, especially
> the Fannkuch benchmark. I've been comparing Sebastion's and
> Bertram's proposals found o
On Jan 6, 2006, at 11:48 AM, Sebastian Sylvan wrote:
Yes, Bertram's is faster. But it's also a lot less readable, IMO. It
uses explicit recursions instead of standard library functions, and
extra complexities here and there. The usage of >>= (and the list
monad) is one example,
You can substi
Simon Marlow wrote:
> Hi Chris,
>
> Rather than try to explain what I'm going on about, I decided to tweak
> the code a bit myself. My version is about 10% faster than yours, and
> doesn't use any explicit unboxery. I've put it in the wiki after your
> version.
>
> http://www.haskell.org/hawiki
The use of arithmetic to determine the chameneos compliments may be prohibited
by the shootout rules. Although the benchmark does not address the issue, the
C# code, which was written by Isaac Gouy (one of the main shootout
administrators) contains these comments before its complement code:
Hi John,
Thanks for releasing HDBC. This is probably more of a GHC question, but
is there any way to staticly link in the Sqlite3 libraries with an
application that uses HDBC.Sqlite3?
Thanks!
-Tom
John Goerzen wrote:
I've had some questions about my intentions for HDBC. The Current Plan
On Fri, Jan 06, 2006 at 03:06:07PM -0600, Tom Hawkins wrote:
> Hi John,
>
> Thanks for releasing HDBC. This is probably more of a GHC question, but
> is there any way to staticly link in the Sqlite3 libraries with an
> application that uses HDBC.Sqlite3?
Yes, you can do that. I think that usi
[EMAIL PROTECTED] wrote:
>>There is no need to beat a dead horse, though. This benchmark sets out
>>to test fgets / atoi, and that is all. There are better benchmarks to
>>spend time on.
>
>
> You can say that again!
>
Ah..sarcasm, I know that one.
Actually, I submitted a slightly faster sum-
I sent a private email and the response to it has
appeared on this mailing-list, so let me just correct
some of the interpretations that have been made.
> > You can say that again!
> Ah..sarcasm, I know that one.
No, it was emphatic agreement (the ordinary usage of
that phrase).
> > Is a perse
haskell:
> Simon Marlow wrote:
> > Hi Chris,
> >
> > Rather than try to explain what I'm going on about, I decided to tweak
> > the code a bit myself. My version is about 10% faster than yours, and
> > doesn't use any explicit unboxery. I've put it in the wiki after your
> > version.
> >
> > ht
Summary of things entered and of things being worked on.
Donald Bruce Stewart wrote:
> haskell:
>
>>Simon Marlow wrote:
>>
>>>Hi Chris,
>>>
>>>Rather than try to explain what I'm going on about, I decided to tweak
>>>the code a bit myself. My version is about 10% faster than yours, and
>>>doesn'
haskell:
> Summary of things entered and of things being worked on.
>
> Things that are on the wiki at http://haskell.org/hawiki/ShootoutEntry
> but that have not been submitted:
>
> Fannkuch entry by Bertram Felgenhauer
> Mandelbrot entry
I've done some benchmarking of the current entries for f
dons:
> haskell:
> > Summary of things entered and of things being worked on.
> >
> > Things that are on the wiki at http://haskell.org/hawiki/ShootoutEntry
> > but that have not been submitted:
> >
> > Fannkuch entry by Bertram Felgenhauer
> > Mandelbrot entry
>
> I've done some benchmarking of
haskell:
> Summary of things entered and of things being worked on.
>
> Donald Bruce Stewart wrote:
> > haskell:
> >
> >>Simon Marlow wrote:
> >>
> >>>Hi Chris,
> >>>
> >>>Rather than try to explain what I'm going on about, I decided to tweak
> >>>the code a bit myself. My version is about 10% f
dons:
> haskell:
> > Summary of things entered and of things being worked on.
> >
> > Donald Bruce Stewart wrote:
> > > haskell:
> > >
> > >>Simon Marlow wrote:
> > >>
> > >>>Hi Chris,
> > >>>
> > >>>Rather than try to explain what I'm going on about, I decided to tweak
> > >>>the code a bit myse
This pidigit program is not mine, but original authors of algorithm.
I've just added print function. It is idiomatic Haskell, pi is pure function
that generates inifinite list of digits, and on two machinas I've
tested p4 2.4 ghz and amd athlon 64 3000 it's about some
small percentage ( 5%) faste
bmaxa:
>
> This pidigit program is not mine, but original authors of algorithm.
> I've just added print function. It is idiomatic Haskell, pi is pure function
> that generates inifinite list of digits, and on two machinas I've
> tested p4 2.4 ghz and amd athlon 64 3000 it's about some
> small perc
29 matches
Mail list logo
