Hi all,
Thanks Bryan, reading your clean code was good for my Haskell health :)
I took your code and did some more research. I think I have found the
answer. I have written an extensive analysis in my blog post
http://cfc.kizzx2.com/index.php/in-search-of-performance-in-haskell/(comments
are
Hi Chris,
On Tue, Aug 9, 2011 at 12:47 PM, Chris Yuen kizzx2+hask...@gmail.com wrote:
1. Why are bangs needed on the length arrays?
If I remove them from below, performance drops 10%. I thought `unsafeIndex`
is straight in both arguments, no?
wordLength i = go i
where
go n
|
On Tue, Aug 9, 2011 at 9:47 AM, Chris Yuen kizzx2+hask...@gmail.com wrote:
- I was using GHC 32-bit. Int is 32-bit there, so I needed Int64. It turns
out 64-bit operations in 32-bit programs are just darn slow. Maybe it's a
Windows problem.
No, GHC calls out to C for 64-bit integer ops on
It's cheaper again to use quotInt# and remInt# as I did in my code.
Just want to point out that this is actually surprisingly less of an impact
than I thought. As I did the step-by-step break down (you can see my blog
post), this one (changing `quotRem` to `quotInt#` and `remInt#`) yielded
Where is the `unsafeAt` function? I can't seem to find it (
http://haskell.org/hoogle/?hoogle=unsafeat).
For reference I have asked the same question on StackOverflow. One person
suggested that the reason might be that Int64 on Windows is broken (
On Monday 08 August 2011, 18:24:45, Chris Yuen wrote:
Where is the `unsafeAt` function?
Data.Array.Base
I can't seem to find it (
http://haskell.org/hoogle/?hoogle=unsafeat).
Data.Array.Base is not haddocked (there's a reason for that), so hoogle
doesn't know about its functions.
For
On Mon, Aug 8, 2011 at 9:24 AM, Chris Yuen kizzx2+hask...@gmail.com wrote:
For reference I have asked the same question on StackOverflow. One person
suggested that the reason might be that Int64 on Windows is broken (
On 9 August 2011 10:06, Bryan O'Sullivan b...@serpentine.com wrote:
On Mon, Aug 8, 2011 at 9:24 AM, Chris Yuen kizzx2+hask...@gmail.comwrote:
For reference I have asked the same question on StackOverflow. One person
suggested that the reason might be that Int64 on Windows is broken (
On 7 August 2011 06:15, Chris Yuen kizzx2+hask...@gmail.com wrote:
I am mainly interested in making the Haskell version perform
comparatively to the C# version. Right now it is at least 5x slower so
obviously I am missing something obvious)
You have a map call which is immediately consumed by
On Sunday 07 August 2011, 10:52:20, Max Bolingbroke wrote:
In short I don't see how to get further without changing the algorithm
or doing some hacks like manual unrolling. Maybe someone else has some
ideas?
Well, the C# implementation uses arrays for lookup while the Haskell
version uses
Here is an updated version using Data.Array.Unboxed http://ideone.com/YXuVL
And the profile http://hpaste.org/49940
Still taking 5+ minutes...
Chris
On Sun, Aug 7, 2011 at 5:20 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
On Sunday 07 August 2011, 10:52:20, Max Bolingbroke
What about using unsafe array indexing operations? (i.e. array `unsafeAt` index)
2011/8/7 Chris Yuen kizzx2+hask...@gmail.com:
Here is an updated version using Data.Array.Unboxed http://ideone.com/YXuVL
And the profile http://hpaste.org/49940
Still taking 5+ minutes...
Chris
On Sun, Aug
Hello Cafe,
I was trying to solve ITA Software's Word Nubmers puzzle (
http://www.itasoftware.com/careers/puzzle_archive.html) using a brute force
approach.
Here's a my version of a quick recap of the problem:
A wordNumber is defined as
wordNumber 1 = one
wordNumber 2 = onetwo
wordNumber 3
13 matches
Mail list logo
