Gives a ~40% speedup on x86_64.
However, the generic code remains faster on aarch64.
This is still processing only one block at a time for now.
I'm pretty confident that processing more blocks per round
will eventually give a substantial performance improvement on
all platforms with vector units.
The bcrypt function intentionally requires quite a lot of CPU cycles
to complete.
In addition to that, not having its full state constantly in the
CPU L1 cache causes a massive performance drop.
These properties slow down brute-force attacks against low-entropy
inputs (typically passwords), and GPU-based attacks get little
to no advantages over CPUs.
The NaCl constructions are available in pretty much all programming
languages, making them a solid choice for applications that require
interoperability.
Go includes them in the standard library, JavaScript has the popular
tweetnacl.js module, and reimplementations and ports of TweetNaCl
have been made everywhere.
Zig has almost everything that NaCl has at this point, the main
missing component being the Salsa20 cipher, on top on which NaCl's
secretboxes, boxes, and sealedboxes can be implemented.
So, here they are!
And clean the X25519 API up a little bit by the way.
of https://github.com/BarabasGitHub/zig into
BarabasGitHub-improve-windows-networking
Conflicts:
lib/std/os.zig
This commit resolves conflicts with the changes to std.os which removed
the EAGAIN error handling interactions with the event loop. The solution
to the conflict was to apply EAGAIN => return error.WouldBlock into the
improved windows networking branch.
The fix for #6715 introduced a new compiler error when attempting to use
wWinMain as the application entry-point.
The Windows API often relies on implicit casts between signed and
unsigned variables. In this case, wWinMain returns an INT despite the
fact this value is intended to feed into ExitProcess, which expects a
UINT, so I've restored the bitcast from #5613.
In this commit, the code samples in the language reference have been changed to
use `std.testing.expect` rather than `std.debug.assert` when they are
written in `test` code. This will teach Zig learners best practices when
they write their own test code.
Not all uses of `std.debug.assert` have been replaced. There are examples where
using `assert` fits the context of the sample.
Using `std.debug.assert` in test code can lead to errors if running tests in
ReleaseFast mode. In ReleaseFast mode, the `unreachable` in `assert` is
undefined behavior. It is possible that `assert` always causes `zig test` to
pass thus possibly leading to incorrect test code outcomes. The goal is to
prevent incorrect code from passing test cases.
Closes#5836
Calling @panic made the executable ~30x times bigger, use a simple
`abort()` and let the user figure out what went wrong.
Supporting ARMv6 (and earlier?) platforms is not a priority.
Closes#6676
Andrew Kelley
Yanis Zafirópulos
Frank Denis
mlarouche
johnLate
dec05eba
Sébastien Marie
Vincent Rischmann
Jakub Konka
Timon Kruiper
DixiE
Paul Espinosa
chwayne
xackus
LemonBoy
heidezomp
frmdstryr
Frank Denis
Rocknest
John Burton