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 it?

Ah, I failed to mention this in my previous mail. I changed the test values from 128KB to 1MB to see if it would help the throughput (by lowering overhead in the framework). So I've already compensated for this in the MB/s calculations. Nice catch, though :-) -- Johan Brinch

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 wrote:

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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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 switching to gold over ld, it may help.

well, memory consumption sky-rockets while compiling "Crypto.CPoly". That behavior is probably not related to the linker.

That's more than likely linked to the huge dispatch table related to cpoly. It would probably helps to build a vector with the data instead of this. -- Vincent

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 string. I'd rather have a type specifically tailored for doing crypto-style computations and then use it. Such that the underlying implementation can be repa, bytestring, supermegavectorizationistic, or something completely different. -- J.