Jeffrey Walton writes:
> On Mon, Mar 12, 2018 at 2:40 PM, Niels Möller wrote:
>> ni...@lysator.liu.se (Niels Möller) writes:
>> ...
>>
>> Now wired up for fat builds, changes pushed to the same branch.
>
> Looks good on a Celeron J3455 (https://www.amazon.com/dp/B01LYCDG4H):
>
> Without --enable
On Mon, Mar 12, 2018 at 4:23 PM, Amos Jeffries wrote:
> On 13/03/18 08:44, Jeffrey Walton wrote:
>> Check /proc/cpuinfo for the sha_ni flag. If present, then you can test
>> the SHA extensions.
>>
>> SHA extensions made their debut in Goldmont. They are also available
>> in Goldmont+. They were sc
On Mon, Mar 12, 2018 at 2:40 PM, Niels Möller wrote:
> ni...@lysator.liu.se (Niels Möller) writes:
> ...
>
> Now wired up for fat builds, changes pushed to the same branch.
Looks good on a Celeron J3455 (https://www.amazon.com/dp/B01LYCDG4H):
Without --enable-fat
md2 update
On 13/03/18 08:44, Jeffrey Walton wrote:
> Check /proc/cpuinfo for the sha_ni flag. If present, then you can test
> the SHA extensions.
>
> SHA extensions made their debut in Goldmont. They are also available
> in Goldmont+. They were scheduled for one of the lakes but they did
> not make it in.
>
Amos Jeffries writes:
> Is there anything you would like in the way of tests or benchmarking
> done with this hardware and environment?
> Just let me know what build and/or test commands you want run, and on
> which git branch.
It would be nice if you could verify the code on branch
x86_64-sha_n
On 13/03/18 07:40, Niels Möller wrote:
> nisse (Niels Möller) writes:
>
>> nisse (Niels Möller) writes:
>>
>>> I've been trying out the sha_ni instructions available on some newer
>>> x86_64 processors.
>>
>> And now that the gcc67 machine is up again, I got my sha256
>> implementation working too
ni...@lysator.liu.se (Niels Möller) writes:
> ni...@lysator.liu.se (Niels Möller) writes:
>
>> I've been trying out the sha_ni instructions available on some newer
>> x86_64 processors.
>
> And now that the gcc67 machine is up again, I got my sha256
> implementation working too. Pushed to branch x
ni...@lysator.liu.se (Niels Möller) writes:
> I've been trying out the sha_ni instructions available on some newer
> x86_64 processors.
And now that the gcc67 machine is up again, I got my sha256
implementation working too. Pushed to branch x86_64-sha_ni-sha256.
Not yet wired up in fat builds, b
On Thu, Feb 8, 2018 at 5:15 PM, Niels Möller wrote:
> Jeffrey Walton writes:
>
>> Looks good on a Celeron J3455, which is a [low-end] Goldmont machine
>> with the instructions:
>
> [...]
>
>> goldmont:nettle$ LD_LIBRARY_PATH=.lib:/usr/local/lib64/
>> ./examples/nettle-benchmark
>> sha1_compress:
Jeffrey Walton writes:
> Looks good on a Celeron J3455, which is a [low-end] Goldmont machine
> with the instructions:
[...]
> goldmont:nettle$ LD_LIBRARY_PATH=.lib:/usr/local/lib64/
> ./examples/nettle-benchmark
> sha1_compress: 84.60 cycles
85 cycles is a lot less than than 136 cycles I obse
Forwarded to the list.
-- Forwarded message --
From: Jeffrey Walton
To: "Niels Möller"
Cc: nettle-bugs@lists.lysator.liu.se
Bcc:
Date: Thu, 8 Feb 2018 16:34:43 -0500
Subject: Re: x86 sha_ni
On Thu, Feb 8, 2018 at 12:18 PM, Niels Möller wrote:
> ni...@lysator.
ni...@lysator.liu.se (Niels Möller) writes:
> Below replacement for sha1-compress.asm seems to run on roughly 2
> cycles/byte when I benchmark it on an "AMD Ryzen 7 1700X" cpu in the gcc
> compile farm. Still sligthly slower than openssl, to squeeze out a few
> more cycles, it might help to change
Hi,
I've been trying out the sha_ni instructions available on some newer
x86_64 processors.
Below replacement for sha1-compress.asm seems to run on roughly 2
cycles/byte when I benchmark it on an "AMD Ryzen 7 1700X" cpu in the gcc
compile farm. Still sligthly slower than openssl, to squeeze out a
13 matches
Mail list logo
