instead of pointer to the Symbol struct in the hope that we
can overwrite the Symbol in the object's symbol table with the
resolved Symbol later down the line.
* remove unused download page html. It's now handled in the
www.ziglang.org website repo.
* add netbsd to the downloads index.json file that we send to
the www.ziglang.org website repo.
* shallow clone the website repo to avoid downloading old copies of
data.js unnecessarily.
Implement io_uring submission queue entry preparation methods for
epoll_ctl, poll_add and poll_remove.
Poll masks are designated as 32-bit little-endian integers as
specified in liburing's definitions.
Updated io_uring_prep_rw to take in an unsigned 64-bit address instead
of an anytype. io_uring_sqe by default assumes that the address
specified in a submission queue entry is an unsigned 64-bit integer.
For stage1 ZIR instructions and stage1 AIR instructions, the instruction
op code was taking up 8 bytes due to padding even though it only needed
1 byte. This commit reduces the ref_count field from uint32_t to
uint16_t because the code only really cares if instructions are
referenced at all, not how many times they are referenced. With the
ref_count field reduced to uint16_t the uint8_t op code is now placed in
the freed up space.
Empirically, this saves 382 MiB of peak RAM usage when building the
self-hosted compiler, which is a reduction of 5%. Consequently this
resulted in a 3% reduction of cache-misses when building the self-hosted
compiler.
This was @SpexGuy's idea, committed by me because we tested it on my
computer.
* rename files to adhere to conventions
* remove unnecessary function / optionality
* fix merge conflict
* better panic message
* remove unnecessary TODO comment
* proper namespacing of declarations
* clean up documentation comments
* no copyright header needed for a brand new zig file that is not
copied from anywhere
Xoroshiro128+ is the current default non-cryptographic random
number generator.
This algorithm was designed to generate floating-point numbers, by
only using the top 53 bits. Lower bits have a significant bias, that
contradicts the documented properties for `rand.DefaultPrng`. This
also has implications on everything using `Random.fill()`, including
the way we generate random floating-point numbers.
In addition, Xoroshiro128+ has known issues. See for example:
- https://lemire.me/blog/2017/08/22/cracking-random-number-generators-xoroshiro128/
- https://www.pcg-random.org/posts/xoroshiro-fails-truncated.html
Xoshiro256++ addresses these issues, while remaining very fast.
