On Wed, 2006-01-04 at 19:25 +, John Goerzen wrote:
> I hope that HDBC can be a community effort. Towards that end, I hope to
> be able to get some trac pages going on somebody's server and perhaps a
> mailing list where ideas and implementations for future enhancements can
> be discussed.
I've added an entry on the hawiki[1] for the regex-dna benchmark, and
posted a smaller (down to 15 lines), faster entry for
[2]reverse-complement, using string indexing from Alex.
Cheers,
Don
[1] http://haskell.org/hawiki/ShootoutEntry
[2] http://haskell.org/hawiki/ReverseComplementEntry
On Wed, Jan 04, 2006 at 09:48:05AM -, Simon Peyton-Jones wrote:
> Ah, now I see what you mean. I had not thought of doing that, but it'd
> make sense, esp if there were lots of 4-byte-non-pointer types. But
> there are only a couple (Int# and Word32#) so I'm not sure it's worth
> the effort.
Hello Joel,
Wednesday, January 04, 2006, 11:31:48 PM, you wrote:
>> 3) i also placed lock around `unstuff` call to decrease GC times
JR> This sort of invalidates the test. We have already proven that it
JR> works much better when you do this but it just pushes the delays
JR> upstream.
as i
On 1/4/06, Scherrer, Chad <[EMAIL PROTECTED]> wrote:
> > --- Sebastian Sylvan <[EMAIL PROTECTED]>
> > wrote:
> > Some of the problems seem to be heavily geared towards an
> > imperative *implementation*, meaning that a Haskell version
> > is hardly idiomatic Haskell (and as such I , and I suspect
>
Hi all,
How would you compare Haskell and Clean? It looks like they are both
pure functional languages with very similar syntax. It also appears that
Clean is faster than Haskell, it appears to be fairly fast. I'm curious
to learn about relative advantages and disadvantages of each.
Thanks f
Bulat,
On Jan 4, 2006, at 7:57 PM, Bulat Ziganshin wrote:
3) i also placed lock around `unstuff` call to decrease GC times
This sort of invalidates the test. We have already proven that it
works much better when you do this but it just pushes the delays
upstream.
I will profile your ver
Hello Joel,
use enclosed unstuff.hs
ghc -O2 --make unstuff.hs -o unstuff -lz
./unstuff trace.dat +RTS -s -A10m
analysis:
1) are you really don't use -O2 switch? :)
2) your origianl program spend 2/3 of it's time in GC. so i used
-A10m to reduce GC times
3) i also placed lock around `unstuff` c
Hello Simon,
Wednesday, January 04, 2006, 7:33:22 PM, you wrote:
The minimum time between context switches is 20 milliseconds.
>> 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 re
> --- Sebastian Sylvan <[EMAIL PROTECTED]>
> wrote:
> Some of the problems seem to be heavily geared towards an
> imperative *implementation*, meaning that a Haskell version
> is hardly idiomatic Haskell (and as such I , and I suspect
> otehrs, really have no inclination to work on it).
This ma
On 1/4/06, Brent Fulgham <[EMAIL PROTECTED]> wrote:
> --- Sebastian Sylvan <[EMAIL PROTECTED]>
> wrote:
> > My point here was that even though you _can_
> > generate this data in Haskell, there's no point in
> requiring
> > (because the order doesn't matter for the benchmark
> itself).
>
> We do ne
--- Sebastian Sylvan <[EMAIL PROTECTED]>
wrote:
> My point here was that even though you _can_
> generate this data in Haskell, there's no point in
requiring
> (because the order doesn't matter for the benchmark
itself).
We do need to agree on which 30 permutations should be
used
in the validati
I've had some questions about my intentions for HDBC. The Current Plan
is:
Release 1.0.0 next week. Before that happens, I want to have a stable
and useful API. I have one feature request to implement yet (examinine
properties of arbitrary tables in the database). I also want to finish
the ODB
On 1/4/06, Brent Fulgham <[EMAIL PROTECTED]> wrote:
> But I think Haskell may face real-world cases where
> data must
> be produced in some known order. For Haskell to be a
> contender
> in "real world" use, it sometimes has to confront ugly
> requirements.
I must respectfully note that you cont
--- Sebastian Sylvan <[EMAIL PROTECTED]>
wrote:
> Some of the problems seem to be heavily geared
> towards an imperative *implementation*, meaning that
a Haskell
> version is hardly idiomatic Haskell (and as such I ,
and I
> suspect otehrs, really have no inclination to work
on it).
I agree that
Bulat Ziganshin wrote:
Tuesday, January 03, 2006, 7:43:21 PM, you wrote:
The minimum time between context switches is 20 milliseconds.
Is there any good reason why 0.02 seconds is the best that you can get
here? Couldn't GHC's internal timer tick at a _much_ faster rate (like
50-100µs or so)
On 1/4/06, Scherrer, Chad <[EMAIL PROTECTED]> wrote:
> Several people on this list have said that the shootout favors imperative
> code. Is this really the case? Why is it Clean seems to have no trouble (for
> the incomplete set of benchmarks that are written in it)?
>
> http://shootout.alioth.de
This is my latest version. Based on Don's tweaks.
{-# INLINE sequ #-}
sequ :: (b -> a) -> PU a -> (a -> PU b) -> PU b
sequ a b c | a `seq` b `seq` c `seq` False = undefined
sequ f pa k = PU fn1 fn2 fn3
where
{-# INLINE fn1 #-}
fn1 ptr b =
case f b of
a -> ca
Bulat Ziganshin wrote:
Tuesday, January 03, 2006, 7:43:21 PM, you wrote:
The minimum time between context switches is 20 milliseconds.
Is there any good reason why 0.02 seconds is the best that you can get
here? Couldn't GHC's internal timer tick at a _much_ faster rate (like
50-100µs or so)
Hello Joel,
Wednesday, January 04, 2006, 12:42:24 AM, you wrote:
JR> contribute to my delays and timeouts. There are also quite a few
JR> unanswered questions at the moment (why is 'sequ' slow?
are you tried to inline it? and all other pickling combinators
the problem is what when you write
pu
Joel Reymont wrote:
I don't think CPU usage is the issue. An individual thread will take a
fraction of a second to deserialize a large packet.
It's a combination of CPU usage by the pickler and GC load.
Those 50k packets take 0.03 seconds to unpickle (version of unstuff.hs
to measure that i
Several people on this list have said that the shootout favors imperative code.
Is this really the case? Why is it Clean seems to have no trouble (for the
incomplete set of benchmarks that are written in it)?
http://shootout.alioth.debian.org/clean.php
How difficult would it be to translate the
On Jan 4, 2006, at 8:11 AM, Chris Kuklewicz wrote:
Krasimir Angelov wrote:
...
In this particular case the flop function is very slow.
...
It can be optimized using a new mangle function:
mangle :: Int -> [a] -> [a]
mangle m xs = xs'
where
(rs,xs') = splitAt m xs rs
splitAt :: Int
On Jan 4, 2006, at 5:30 AM, Simon Marlow wrote:
On 30 December 2005 01:23, Jan-Willem Maessen wrote:
Probably. The minimum table chunk size was rather large. I have
been experimenting (tests are running even as I type) with alternate
implementations of Data.HashTable. So far the winning im
On 1/4/06, Chris Kuklewicz <[EMAIL PROTECTED]> wrote:
> Sebastian Sylvan wrote:
> > On 1/4/06, Josh Goldfoot <[EMAIL PROTECTED]> wrote:
> >
> >>Keep in mind that the shootout requires that the first 30 permutations
> >>printed out by the Fannkuch benchmark to be exactly those given in the
> >>"ex
On 1/4/06, Chris Kuklewicz <[EMAIL PROTECTED]> wrote:
> Sebastian Sylvan wrote:
> > On 1/4/06, Josh Goldfoot <[EMAIL PROTECTED]> wrote:
> >
> >>Keep in mind that the shootout requires that the first 30 permutations
> >>printed out by the Fannkuch benchmark to be exactly those given in the
> >>"ex
Christian Maeder wrote:
http://www.isi.edu/~hdaume/htut/tutorial.pdf
4.5 Data Types 47
8 Advanced Types 103
8.1 Type Synonyms
Thanks!
Daniel.
--
/\/`) http://oooauthors.org
/\/_/ http://opendocumentfellowship.org
/\/_/
\/_/I am not over-weight, I am under-tall.
/
_
Ketil Malde wrote:
I'm trying to figure out how 'data' and 'type'.
How data and type...what? :-)
oops... "work" :)
Generally, 'type' introduces type synonyms, i.e. just gives a new name
to an existing type, while 'data' defines new (algebraic) types.
So you can use
type Name = String
Hello Josh,
Wednesday, January 04, 2006, 6:00:16 AM, you wrote:
JG> I was able to significantly speed up the code by replacing the flip
function with a function that relies entirely on pattern matching (no splitAts
or reverses). It looks ugly, though:
JG> mangle list@(1:xs) = list
JG> mangle
Hello Sebastian,
Wednesday, January 04, 2006, 5:13:57 AM, you wrote:
>> complArr = array ('A','Z') (self ++ complAssoc)
UArray, indexed starting from '\0', will work faster
SS> Oops! Apologies to whoever wrote the orignal version! Apparently I
SS> didn't read the spec carefully enough, the sequ
Hello Simon,
Tuesday, January 03, 2006, 7:43:21 PM, you wrote:
>> The minimum time between context switches is 20 milliseconds.
>>
>> Is there any good reason why 0.02 seconds is the best that you can get
>> here? Couldn't GHC's internal timer tick at a _much_ faster rate (like
>> 50-100µs or so
Daniel Carrera wrote:
Hello all,
I'm trying to figure out how 'data' and 'type'. I haven't read any
documentation because I can't find any. Could someone point me to a
document explaining these? I'm happy to RTFM, I just need to know where
the FM is :)
http://www.isi.edu/~hdaume/htut/tutori
Daniel Carrera <[EMAIL PROTECTED]> writes:
> I'm trying to figure out how 'data' and 'type'.
How data and type...what? :-)
Generally, 'type' introduces type synonyms, i.e. just gives a new name
to an existing type, while 'data' defines new (algebraic) types.
So you can use
type Name = Strin
Sebastian Sylvan wrote:
> On 1/4/06, Josh Goldfoot <[EMAIL PROTECTED]> wrote:
>
>>Keep in mind that the shootout requires that the first 30 permutations
>>printed out by the Fannkuch benchmark to be exactly those given in the
>>"example."
>
>
> Well I'm one step closer to just not caring about
Hello all,
I'm trying to figure out how 'data' and 'type'. I haven't read any
documentation because I can't find any. Could someone point me to a
document explaining these? I'm happy to RTFM, I just need to know where
the FM is :)
Cheers,
Daniel.
--
/\/`) http://oooauthors.org
/\/_/
On 1/4/06, Josh Goldfoot <[EMAIL PROTECTED]> wrote:
> Keep in mind that the shootout requires that the first 30 permutations
> printed out by the Fannkuch benchmark to be exactly those given in the
> "example."
Well I'm one step closer to just not caring about the shootout anymore.
The spec say
Krasimir Angelov wrote:
> 2006/1/3, Chris Kuklewicz <[EMAIL PROTECTED]>:
>
>> And finially, the haskel entry for
>>http://shootout.alioth.debian.org/benchmark.php?test=fannkuch&lang=all
>> is currently the *slowest* entry out of 28 languages. It is 813x
>>slower than the c-code, 500x slower than
2006/1/3, Chris Kuklewicz <[EMAIL PROTECTED]>:
> And finially, the haskel entry for
> http://shootout.alioth.debian.org/benchmark.php?test=fannkuch&lang=all
> is currently the *slowest* entry out of 28 languages. It is 813x
> slower than the c-code, 500x slower than OCaml. Should be easy to mak
I have a clarification below:
Simon Peyton-Jones wrote:
> | Given that actually controlling priorities is not an option, adding
> | blocking like that makes sense. One can make a ring buffer instead of
> a
>
> Concerning priorities and scheduling (which affect both this shootout
> thread, and pe
Chris Kuklewicz wrote:
> Could you post your code to this mailing list or to the wiki at
> http://haskell.org/hawiki/FannkuchEntry ?
I added it to the wiki. (I added it at the top - if anyone feels
put down by this, I apologize. Feel free to move it.)
Enjoy,
Bertram
_
Could you post your code to this mailing list or to the wiki at
http://haskell.org/hawiki/FannkuchEntry ?
Bertram Felgenhauer wrote:
>>And for sanity's sake, I wish one of the entries would have documentated
>>a clear way to understand the permutation generator. The PHP and Lua
>>versions are al
Summarizing:
I collected all of the code snippets posted to this thread into the wiki
under http://haskell.org/hawiki/ShootoutEntry including old haskell code
already on the shootout.
The Fannkuch benchmark drew a lot of interest, but a new entry that
creates the correct permutation order (for th
> And for sanity's sake, I wish one of the entries would have documentated
> a clear way to understand the permutation generator. The PHP and Lua
> versions are almost legible.
Here's a neat Haskell version:
-- rotate initial n elements of the list left by one place
rotate n (x:xs) = rot' n xs
| Given that actually controlling priorities is not an option, adding
| blocking like that makes sense. One can make a ring buffer instead of
a
Concerning priorities and scheduling (which affect both this shootout
thread, and perhaps Joel's timeleak program), one can take two
approaches
1. Ask
Yes, that _is_ obvious but then puts the burden on the programmer to
define the getters. It also misses the setters issue entirely.
Each field can definitely be made into a class and records can be
composed dynamically, HList-style. I think HList is _the_ facility
for doing this.
How do y
On 03 January 2006 17:32, Chris Kuklewicz wrote:
> Thanks for the answer, but I should I written a longer comment. I have
> added such a longer comment below:
>
> Simon Marlow wrote:
>> Chris Kuklewicz wrote:
>>
>>> Another comment: between 1000's of threads and writing a custom
>>> continuation
Sure. Type classes, as Ketil Malde has suggested.
On Jan 4, 2006, at 2:09 AM, Dylan Thurston wrote:
Looking at this code, I wonder if there are better ways to express
what you really want using static typing. To wit, with records, you
give an example
data Pot = Pot
{
pProfit :: !Wor
On 03 January 2006 12:03, Chris Kuklewicz wrote:
> STM* is usually slower than IO/MVar. STM has to do the transactional
> record keeping and throws away work (i.e. CPU cycles and speed) when
> it aborts. The Chameneos benchmark has 4 writers working *very*
> quickly, so the contention is high.
On 30 December 2005 01:23, Jan-Willem Maessen wrote:
> Probably. The minimum table chunk size was rather large. I have
> been experimenting (tests are running even as I type) with alternate
> implementations of Data.HashTable. So far the winning implementation
> is one based on multiplicative h
| > You'd still need several versions of the code for a polymorphic
function, one
| > for pointer values, one for 4-byte non-pointers, one for 8-byte
non-pointers
| > etc.
|
| Yes, but that's up to the user. A type variable always has a
particular
| kind, so for instance one might want an array ov
In article
<[EMAIL PROTECTED]
ft.com>,
"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote:
> You'd still need several versions of the code for a polymorphic function, one
> for pointer values, one for 4-byte non-pointers, one for 8-byte non-pointers
> etc.
Yes, but that's up to the user. A type v
Dylan Thurston <[EMAIL PROTECTED]> writes:
>> http://wagerlabs.com/articles/2006/01/01/haskell-vs-erlang-reloaded
| Compare Erlang
|
| -record(pot, {
| profit = 0,
| amounts = []
|}).
> [...] complain about "having to explain to the customer how xyFoo is
> really differen
[Moving to haskell-café]
You'd still need several versions of the code for a polymorphic function, one
for pointer values, one for 4-byte non-pointers, one for 8-byte non-pointers
etc.
That's what .net does, I believe, but via runtime code generation.
Simon
| -Original Message-
| From
53 matches
Mail list logo
