On Apr 8, 2006, at 9:30 PM, Daniel Fischer wrote:
Hum,
oddly, these actually slow things down.
While the new size brought the sudoku17 time from ~570s down to ~490s,
the new findMinIndex/findMaxIndex increased the time to ~515s,
although hardly
used.
Why?
Hard to say. I'd expect that if t
Hello David,
Sunday, April 9, 2006, 5:47:03 PM, you wrote:
> In an email to me, Jean-Philippe Bernardy expressed a concern that a
> large table could needlessly fill the data cache. He proposed
> checking 4 bits at a time and using a small table of 16 elements.
> Not surprisingly, it isn't
Hi Bulat,
On Apr 9, 2006, at 6:31 AM, Bulat Ziganshin wrote:
on the other side, these procedures can use the same divide-to-bytes
technique as `size`
findMinIndex 0 = undefined
findMinIndex n = case (n `shiftR` 8) of
0 -> minIndexInByte ! (n .&. 255)
b ->
Hello Robert,
Sunday, April 9, 2006, 2:54:58 AM, you wrote:
> findMinIndex :: Word -> Int
> findMaxIndex :: Word -> Int
on the other side, these procedures can use the same divide-to-bytes
technique as `size`
findMinIndex 0 = undefined
findMinIndex n = case (n `shiftR` 8) of
Hello David,
Saturday, April 8, 2006, 9:58:56 PM, you wrote:
> bitsTable :: Array Word Int
> bitsTable = array (0,255) $ [(i,bitcount i) | i <- [0..255]]
bitsTable :: UArray Word Int
bitsTable = listArray (0,255) $ map bitcount [0..255]
UArray is much faster than Array but can be used only for
Hum,
oddly, these actually slow things down.
While the new size brought the sudoku17 time from ~570s down to ~490s,
the new findMinIndex/findMaxIndex increased the time to ~515s, although hardly
used.
Why?
Cheers,
Daniel
Am Sonntag, 9. April 2006 00:54 schrieb Robert Dockins:
> On Apr 8, 2006,
On Apr 8, 2006, at 1:58 PM, David F. Place wrote:
Thanks Bulat and Robert. I implemented Bulat's idea as the
following. It tests faster than Roberts. I use Robert's to
compute the table. The performance seems satisfactory now.
size :: Set a -> Int
size (Set w) = countBits w
where
On Apr 8, 2006, at 4:24 AM, Bulat Ziganshin wrote:
foldBits can be made faster (may be) by adding strict annotations:
foldBits :: Bits c => (a -> Int -> a) -> a -> c -> a
foldbits _ z bs | z `seq` bs `seq` False = undefined
foldBits' :: Bits c => (a -> Int -> a) -> Int -> c -> a -> a
foldbit
Thanks Bulat and Robert. I implemented Bulat's idea as the
following. It tests faster than Roberts. I use Robert's to compute
the table. The performance seems satisfactory now.
size :: Set a -> Int
size (Set w) = countBits w
where
countBits w
| w == 0 = 0
| o
On Apr 8, 2006, at 4:24 AM, Bulat Ziganshin wrote:
Hello Daniel,
Saturday, April 8, 2006, 4:21:14 AM, you wrote:
Unless I overlooked something, I use foldBits only via size
(though that's
used a lot).
size of set? there is much faster method - use a table
[0..255] -> number of bits in t
Hello Daniel,
Saturday, April 8, 2006, 4:21:14 AM, you wrote:
> Unless I overlooked something, I use foldBits only via size (though that's
> used a lot).
size of set? there is much faster method - use a table
[0..255] -> number of bits in this number seen as set
then we split Word to the bytes
Am Freitag, 7. April 2006 22:57 schrieb David F. Place:
> After reading Daniel Fischer's message about trying to use EnumSet in
> his Sudoku.hs and finding that it was slower when processing a large
> data set, I decided to do some profiling. I rewrote his solver to
> use EnumSets and profiled it.
After reading Daniel Fischer's message about trying to use EnumSet in
his Sudoku.hs and finding that it was slower when processing a large
data set, I decided to do some profiling. I rewrote his solver to
use EnumSets and profiled it. The culprit turns out to be the
following function whi
13 matches
Mail list logo
