Likewise, on Windows, it's 1 MB of reserved memory but only 4 KB of initially committed memory. https://learn.microsoft.com/en-us/cpp/build/reference/stack-...
From the linked Zulip thread (https://rust-lang.zulipchat.com/#narrow/channel/131828-t-com...): > We are running different workloads including rustc perf suite. In general the runtime performance is on par with llvm.…
> Currently at Google as a Sr. SWE SRE on the cloud.
Right, that's basically what I was trying to say (in so many words). I learned a lot from your dtoa blog posts and Zmij's implementation. Thank you! > has 2-3 wide multiplications compared to 1 for newer methods. As…
The upstream fmtlib dtoa-benchmark integrates uscale (https://fmtlib.github.io/dtoa-benchmark/results/). It uses C code from Russ Cox's original fpfmt repository (https://github.com/rsc/fpfmt/tree/main/bench/uscalec),…
Not mentioned: Floating-point parsing and formatting now uses Russ Cox's uscale algorithm. https://research.swtch.com/fp https://github.com/golang/go/blob/go1.27.0/src/internal/strc...
https://news.ycombinator.com/item?id=48057901#48068126 Make of that what you will.
FYI you linked to a really old version of the GCC documentation. Google apparently loves those old docs, so they often show up near the top of search results despite being ancient. For posterity, here's the latest…
Historically, it was a bit more complex than that, and applies to more than just AVX-512: https://gist.github.com/rygorous/32bc3ea8301dba09358fd2c64e0....
Zig vectors do not necessarily force data into SIMD registers; a scalar implementation would work equally well. This is not just a theoretical argument, because Zig code that uses `@Vector` also has to compile for…
It's not designed for IoT devices per se, the naming is just terrible. A comparison to OpenWrt is not warranted here, although to reiterate, the naming is terrible.
You're "supposed" to acquire LTSC through non-official means, not using the evaluation ISO.
See also: https://betawiki.net/wiki/Windows_8_build_8172
Explorer uses XAML Islands. Parts of it are WinUI, while the rest is still Win32.
C++
"Good enough" is not good enough.
There's a million and one ways to do it, here's just some of the ones I remember: - https://www.mdsec.co.uk/2022/04/resolving-system-service-num... - https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisp... -…
On modern enough x86 CPUs (Intel Broadwell, AMD Ryzen) you could also use ADX [1] which may be faster nowadays in situations where radix 2^51 representation traditionally had an edge (e.g. Curve25519). [1]…
According to the standard `realloc(NULL, size)` should already behave like `malloc(size)`. You shouldn't need that special case unless you're working on a system with a very buggy/non-compliant libc.
It just uses GDI_CLASSIC for DWRITE_MEASURING_MODE [1] and DWRITE_RENDERING_MODE [2] in that case. No actual GDI in sight. [1] https://learn.microsoft.com/en-us/windows/win32/api/dcommon/... [2]…
https://github.com/RealNeGate/Cuik/blob/5c6f6ef9bfa983eb358a...
The much dreaded Annex K functions are perhaps the worst possible example of an attempt at "fixing" anything safety related in C. A waste of ink.
Are there any benchmarks of Windows EH? The implementation is very different from DWARF/SJLJ EH and it would be interesting to see how it fares. I've seen some pretty exceptional claims for both sides of the argument…
> Is a single MOV instruction still fast when the 8 bytes begin on an odd address? On x86, yes. There is no performance penalty for misaligned loads, except when the misaligned load also happens to straddle a cache line…
I think you should be able to get rid of most of the undocumented API usage with the newer CreateFileMapping2/MapViewOfFile3 APIs. Though that does require a higher minimum OS version and the crucial NtExtendSection…
Likewise, on Windows, it's 1 MB of reserved memory but only 4 KB of initially committed memory. https://learn.microsoft.com/en-us/cpp/build/reference/stack-...
From the linked Zulip thread (https://rust-lang.zulipchat.com/#narrow/channel/131828-t-com...): > We are running different workloads including rustc perf suite. In general the runtime performance is on par with llvm.…
> Currently at Google as a Sr. SWE SRE on the cloud.
Right, that's basically what I was trying to say (in so many words). I learned a lot from your dtoa blog posts and Zmij's implementation. Thank you! > has 2-3 wide multiplications compared to 1 for newer methods. As…
The upstream fmtlib dtoa-benchmark integrates uscale (https://fmtlib.github.io/dtoa-benchmark/results/). It uses C code from Russ Cox's original fpfmt repository (https://github.com/rsc/fpfmt/tree/main/bench/uscalec),…
Not mentioned: Floating-point parsing and formatting now uses Russ Cox's uscale algorithm. https://research.swtch.com/fp https://github.com/golang/go/blob/go1.27.0/src/internal/strc...
https://news.ycombinator.com/item?id=48057901#48068126 Make of that what you will.
FYI you linked to a really old version of the GCC documentation. Google apparently loves those old docs, so they often show up near the top of search results despite being ancient. For posterity, here's the latest…
Historically, it was a bit more complex than that, and applies to more than just AVX-512: https://gist.github.com/rygorous/32bc3ea8301dba09358fd2c64e0....
Zig vectors do not necessarily force data into SIMD registers; a scalar implementation would work equally well. This is not just a theoretical argument, because Zig code that uses `@Vector` also has to compile for…
It's not designed for IoT devices per se, the naming is just terrible. A comparison to OpenWrt is not warranted here, although to reiterate, the naming is terrible.
You're "supposed" to acquire LTSC through non-official means, not using the evaluation ISO.
See also: https://betawiki.net/wiki/Windows_8_build_8172
Explorer uses XAML Islands. Parts of it are WinUI, while the rest is still Win32.
C++
"Good enough" is not good enough.
There's a million and one ways to do it, here's just some of the ones I remember: - https://www.mdsec.co.uk/2022/04/resolving-system-service-num... - https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisp... -…
On modern enough x86 CPUs (Intel Broadwell, AMD Ryzen) you could also use ADX [1] which may be faster nowadays in situations where radix 2^51 representation traditionally had an edge (e.g. Curve25519). [1]…
According to the standard `realloc(NULL, size)` should already behave like `malloc(size)`. You shouldn't need that special case unless you're working on a system with a very buggy/non-compliant libc.
It just uses GDI_CLASSIC for DWRITE_MEASURING_MODE [1] and DWRITE_RENDERING_MODE [2] in that case. No actual GDI in sight. [1] https://learn.microsoft.com/en-us/windows/win32/api/dcommon/... [2]…
https://github.com/RealNeGate/Cuik/blob/5c6f6ef9bfa983eb358a...
The much dreaded Annex K functions are perhaps the worst possible example of an attempt at "fixing" anything safety related in C. A waste of ink.
Are there any benchmarks of Windows EH? The implementation is very different from DWARF/SJLJ EH and it would be interesting to see how it fares. I've seen some pretty exceptional claims for both sides of the argument…
> Is a single MOV instruction still fast when the 8 bytes begin on an odd address? On x86, yes. There is no performance penalty for misaligned loads, except when the misaligned load also happens to straddle a cache line…
I think you should be able to get rid of most of the undocumented API usage with the newer CreateFileMapping2/MapViewOfFile3 APIs. Though that does require a higher minimum OS version and the crucial NtExtendSection…