Intel keeps changing the latency & throughput of the aes* and clmul
instructions every time they release a new model.
Adjust `optimal_parallel_blocks` accordingly, keeping 8 as a safe
default for unknown data.
It seems that Apple has finally got rid of the 32bit versions of
`fstat` and `fstatat`, and instead, only 64bit versions are available
on BigSur and Apple Silicon.
The tweak in this commit is required to make Zig stage1 compile on
BigSur + aarch64.
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.
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
* Smaller startup sequence for ppc64
* Terminate the frame-pointer chain when executing _start
* Make the stack traces work on ppc64
* Make the stack traces coloured on ppc64, some ioctls numbers are
different and the whole set of constants should be audited.
