Re: [Haskell-cafe] Crypto-api performance

2011-05-10 Thread Johan Brinch
On Tue, May 10, 2011 at 11:14, Jesper Louis Andersen wrote: > On Tue, May 10, 2011 at 09:47, Johan Brinch wrote: > >> Stuff like xor'ing two bytestrings or generating a block of >> incremental IV's (for CTR mode)? > > I don't particularly like the notion of XOR on a bytestring. The > bytestring i

Re: [Haskell-cafe] Crypto-api performance

2011-05-10 Thread Jesper Louis Andersen
On Tue, May 10, 2011 at 09:47, Johan Brinch wrote: > Stuff like xor'ing two bytestrings or generating a block of > incremental IV's (for CTR mode)? I don't particularly like the notion of XOR on a bytestring. The bytestring is not a number and it does not make much sense to bitwise xor such a st

Re: [Haskell-cafe] Crypto-api performance

2011-05-10 Thread Johan Brinch
On Tue, May 3, 2011 at 22:05, Johan Brinch wrote: > Does anyone have experience with the crypto-api package? > > It seems to define a nice common API for block ciphers, hash functions > and prng's. However, I get very low performance using it. > > I ran its benchmark on a NOP block cipher, where e

Re: [Haskell-cafe] Crypto-api performance

2011-05-05 Thread Vincent Hanquez
On Thu, May 05, 2011 at 11:56:42AM +0200, Peter Simons wrote: > Hi Matthew, > > > While I haven't investigated myself, from seeing haskell build processes > > in the past this is almost certainly not crypto-api's fault and is in > > fact your linker's fault. If you are not using it already, try

Re: [Haskell-cafe] Crypto-api performance

2011-05-05 Thread Peter Simons
Hi Matthew, > While I haven't investigated myself, from seeing haskell build processes > in the past this is almost certainly not crypto-api's fault and is in > fact your linker's fault. If you are not using it already, try switching > to gold over ld, it may help. well, memory consumption sk

Re: [Haskell-cafe] Crypto-api performance

2011-05-04 Thread Matthew Ryan Maurer
While I haven't investigated myself, from seeing haskell build processes in the past this is almost certainly not crypto-api's fault and is in fact your linker's fault. If you are not using it already, try switching to gold over ld, it may help. --Matthew Maurer On 05/04/2011 04:27 AM, Peter Simons

Re: [Haskell-cafe] Crypto-api performance

2011-05-04 Thread Peter Simons
Also, it appears that crypto-api needs vast amounts of memory when compiled with optimization enabled. The latest version 0.6.1 is effectively unbuildable on my EeePC, which has only 1GB RAM. That property is fairly undesirable for a library package. Take care, Peter

Re: [Haskell-cafe] Crypto-api performance

2011-05-03 Thread Johan Brinch
On Tue, May 3, 2011 at 23:14, Daniel Fischer wrote: > did you notice that the comment says 128KB strings for ps and lps, but they > are in fact 1MB strings: > > -- 128KB strings > ps = B.replicate (2^20) 0 > lps = L.replicate (2^20) 0 > > ? If not, the throughput would look much better, wouldn't i

Re: [Haskell-cafe] Crypto-api performance

2011-05-03 Thread Daniel Fischer
On Tuesday 03 May 2011 22:05:17, Johan Brinch wrote: > Does anyone have experience with the crypto-api package? > > It seems to define a nice common API for block ciphers, hash functions > and prng's. However, I get very low performance using it. > > I ran its benchmark on a NOP block cipher, whe

[Haskell-cafe] Crypto-api performance

2011-05-03 Thread Johan Brinch
Does anyone have experience with the crypto-api package? It seems to define a nice common API for block ciphers, hash functions and prng's. However, I get very low performance using it. I ran its benchmark on a NOP block cipher, where encryptBlock k = id, and it's still very slow. After expanded