Hello--
I'm looking for information or rationale behind the "expansion"
that's in BUF_MEM_grow() and BUF_MEM_grow_clean(). This is where
my request to grow the buffer by x number bytes turns into a
request for x + 33% bytes.
Is there concern about a buffer overflow somewhere? paranoia?
trying
version 11/05/2015:
sha256 39017.64k87648.54k 150106.58k 183705.94k
197330.99k
version 1.8:
sha256 33560.42k73153.83k 121472.43k 167948.67k
180955.23k
It sounds like we're talking about Nehalem, as it's very close to
difference reported by Pavel:
i5 Ly
>> Now I agree ;) 1.8 version is "best-balanced" for all architectures.
>>
>
> I'm not sure I agree: I've grabbed the 1.8 version and rebuilt openssl
> 1.0.1c and tested it on an i5
i5 says exactly nothing, please don't use it. Say Nehalem, Sandy Bridge,
whatever, but not i5!
> and a Core 2 Duo;
I'm not sure I agree: I've grabbed the 1.8 version and rebuilt openssl
1.0.1c and tested it on an i5 and a Core 2 Duo; performance is better
than the non-patched version but it is WORSE compared to the original
version of the sha256-586.pl script that was posted here before on May
11th.
That's
Hi,
Pavel Semjanov wrote:
As for Sandy Bridge. I don't know... I could observe nominal variations,
2-3%, on my machine, but nothing close to 10%, so this is odd... If you
have energy, test with varying stack seed(*)...
It was my error, because I measured it in special application. It
doesn'
As for Sandy Bridge. I don't know... I could observe nominal variations,
2-3%, on my machine, but nothing close to 10%, so this is odd... If you
have energy, test with varying stack seed(*)...
It was my error, because I measured it in special application. It
doesn't know about OPENSSL_ia32cap
