The last few times I reserved a table at a restaurant, I only gave my first name. They never asked for my full name, would be hard for them to find me on social media. However, I'm an immigrant with a locally uncommon first name, YMMV.
6,400 karma · joined March 2, 2015
http://const.me/
Windows didn’t run on these other systems, why would Microsoft care about them?
> x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it
For publicly accessible web servers, Linux overtook Windows around 2005. Then in 2006 Amazon launched EC2, and the industry started that massive transition to the clouds. Linux is better suited for clouds, due to OS licensing and other reasons.
The technical decision Microsoft made initially worked well for over two decades. I don’t think it was lame; I believe it was a solid choice back then.
Sadly, C++ standard library API designers made it impossible to directly access the array of integers stored inside std::vector<bool>. This made serialization/de-serialization of these vectors very inefficient, sometimes prohibitively so.
The search is less than ideal. Search for FMA, it will find multiple pages of NEON intrinsics, but no AMD64 like _mm256_fmadd_pd
Don’t feed many pages of code to AI, it works best for isolated functions or small classes with little dependencies.
In 10% of cases when I ask to generate or complete code, the quality of the code is less than ideal but fixable with extra instructions. In 25% of cases, the quality of generated code is bad and remains so even after telling it what’s wrong and how to fix. When it happens, I simply ignore the AI output and do something else reasonable.
Apart from writing code, I find it useful at reviewing new code I wrote. Half of the comments are crap and should be ignored. Some others are questionable. However, I remember a few times when the AI identified actual bugs or other important issues in my code, and proposed fixes. Again, don’t copy-paste many pages at once, do it piecewise.
For some niche areas (examples are HLSL shaders, or C++ with SIMD intrinsics) the AI is pretty much useless, probably was not enough training data available.
Overall, I believe ChatGPT improved my code quality. Not only as a result of reviews, comments, or generated codes, but also my piecewise copy-pasting workflow improved overall architecture by splitting the codebase into classes/functions/modules/interfaces each doing their own thing.
Pretty good laptop, the screen is great even, colour-calibrated 2880×1800 IPS configurable to 60 Hz refresh rate. However, the up/down arrow keys are not full size, their height is smaller.
For example, AMD Ryzen 7 8840U or 7840U can be configured for the same 15W TDP as Apple M1. At 15W, the overall performance going to be about the same as M1.
Intel 80486 with 1.2M transistors delivered 0.128 flops / cycle.
nVidia 4070 Ti Super with 45.9B transistors delivers 16896 flops / cycle.
As you see, each transistor became 3.45 times more efficient at delivering these FLOPs per cycle.
Enables debugging binaries and crash dumps without complete source codes, like DLLs shipped with Windows or third-party DLLs. Allows to understand what compilers (both traditional and JIT) did to your source codes, this is useful when doing performance optimizations.
That type is not for characters anymore; all these languages treat these values as UTF-16 units. Unlike C++, their standard libraries provide functions to convert strings between UTF-8 and UTF-16, apply Unicode normalization, decode strings into a sequence of code points, etc.
> That's what iostreams are
iostreams tried to implement binary streams, text streams, and object formatting with the same API. Predictably failed all these tasks, the features are too different. A minimalistic C++ API for a stream of bytes might look something like that:
struct iStream
{
virtual ~iStream() { }
virtual void read( std::span<uint8_t> buffer ) = 0;
virtual void write( std::basic_string_view<uint8_t> buffer ) = 0;
};
Can you elaborate? When I write string content = File.ReadAllText( path ) in C#, the standard library does exactly the same thing as some C++ library could do: open file for read access, read it to the end, and because C# strings are UTF-16 convert the bytes from UTF-8 to UTF-16.
> Async interfaces are all the rage these days. Meanwhile browsers have moved from TCP to QUIC
I think both points are exotic stuff. Not sure I would want to see them in C++ standard library. Also going to be hard to design a useful platform-agnostic abstractions. OTOH, Unicode strings, file systems, and streams of bytes are literally everywhere in software.
Standard libraries of Java, JavaScript, and C# are counter-examples.
> you can just use that from C++ if you want to
Technically, C++ standard could feature an abstract interface for a stream of bytes. Would be useful not only for TCP sockets, also for files and pipes.
BTW I’ve been programming C++ for living for decades now, and I never saw production code to use C++ <iostream> header. Instead, C++ developers I worked with have been using either <cstdio> or OS-specific APIs.
> applications are better off handling the differences directly
Many other languages have managed to design high-level platform agnostic abstractions over these things, and implemented them in the standard libraries.
> reserved for truly ossified OS interfaces
By now this applies to files, file systems, pipes, and TCP sockets. While there’re some features hard to abstract away (examples include controlling file permissions, and probably asynchronous I/O), many real-world applications don’t need them. They just need basic stuff like read and write bytes from binary streams, concatenate paths, create/open/delete files, listen and accept TCP sockets.
About non-Unicode WinAPI functions, I don’t use them at all in the software I’m developing, nor the TCHAR conditional typedef. VC++ compiler defines wchar_t as a built-in type for the UTF16 strings used in WinAPI functions.
CreateFileA API thing is only available for compatibility with prehistoric software written for Win9x from the nineties. Also, the SDK comes with CAtlFile class which wraps CreateFileW / ReadFile / CloseHandle and guarantees closing handle in the destructor.
They are using a raw pointer in OMMSet structure which leaks memory. I would replace the raw pointer with std::unique_ptr<D3D12_RAYTRACING_OPACITY_MICROMAP_HISTOGRAM_ENTRY[]>
As for the _alloca, I think it’s OK however I usually assert() the size being allocated is reasonable, like under 256kb.
Mostly agree about the algorithms. Another good thing in C++ are low-level mathematic parts of the standard library in <cmath> and <complex>.
Containers are OK, but neither usability nor performance are IMO great. Node-based containers like red-black trees and hash maps come with a contract which says pointers are stable, by default this means one malloc() per element, this is slow.
However, there’re large areas where C++ standard library is lacking.
File I/O is questionable to say the least. Networking support is missing. Unicode support is missing, <codecvt> deprecated in C++17 because they found out it no longer implements current Unicode standard and instead of fixing the standard library they dropped the support. Date and calendars support only arrived in C++/20. No built-in way to represent money amount, e.g. C# standard library has fixed-size 16 bytes type for decimal floating-point numbers, Java standard library has arbitrary-precision integers and decimals.
If your data format contains multiple streams inside, consider ZIP for the container. Enables standard tools, and libraries available in all languages. The compression support is built-in but optional, can be enabled selectively for different entries.
The approach is widely used in practice. MS office files, Java binaries, iOS app store binaries, Android binaries, epub books, chm documentation are all using ZIP container format.
The use case they had is saving minidumps when the app crashes. Windows error reporting OS component is flexible enough to support the feature without hacks, they just need to write couple values to registry in the installer of their software. See details on per-application settings in that article: https://learn.microsoft.com/en-us/windows/win32/wer/collecti...
If they want better UX and/or compress & uploads the dump as soon as the app crashes (as opposed to the next launch of the app) – I would solve by making a simple supervisor app which launches the main binary with CreateProcess, waits for it to exit, then looks for the MainApp.exe.{ProcessID}.dmp file created by that WER OS component.
An overview article: https://blog.applied-algorithms.tech/a-sub-millisecond-gc-fo...
Long discussion thread with many graphs with measurements: https://github.com/dotnet/runtime/discussions/115627
I don’t yet have hands-on experience with that Satori GC, though.
Yeah, I observed that too. As far as I remember, that code did many small memory allocations, and .NET GC was faster than malloc.
However, last time I tested (used .NET 6 back then), for code which churches numbers with AVX, my C++ with SIMD intrinsics was faster than C# with SIMD intrinsics. Not by much but noticeable, like 20%. The code generator was just better in C++. I suspect the main reason is .NET JIT compiler doesn’t have time for expensive optimisations.
Yeah, and that model is rather old: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule In practice, complex software systems have been written in multiple languages for decades. The requirements of performance-critical low-level components and high-level logic are too different and they are in conflict.
> you give the compiler an opportunity to optimise across those unsafe usages
One workaround is better design of the DLL API. Instead of implementing performance-critical outer layers in C#, do so on the C++ side of the interop, possibly injecting C# dependencies via function pointers or an abstract interface.
Another option is to re-implement these smaller functions in C#. Modern .NET runtime is not terribly slow; it even supports SIMD intrinsics. You are unlikely to match the performance of an optimised C++ release build with LTO, but it’s unlikely to fall significantly short.
Most of my applications are written in C#.
C# provides memory safety guarantees very comparable to Rust, other safety guarantees are better (an example is compiler option to convert integer overflows into runtime exceptions), is a higher level language, great and feature-rich standard library, even large projects compile in a few seconds, usable async IO, good quality GUI frameworks… Replacing C# with Rust would not be a benefit.
A trivial example is multiplication of large square matrices. An implementation needs to leverage all available CPU cores, and a traditional way to do that you’ll find in many BLAS libraries – compute different tiles of the output matrix on different CPU cores. A tile is not a continuous slice of memory, it’s a rectangular segment of a dense 2D array. Storing different tiles of the same matrix in parallel is trivial in C++, very hard in Rust.
One reason why async-await is trivial in .NET is garbage collector. C# rewrites async functions into a state machine, typically heap allocated. Garbage collector automagically manages lifetimes of method arguments and local variables. When awaiting async functions from other async functions, the runtime does that for multiple async frames at once but it’s fine with that, just a normal object graph. Another reason, the runtime support for all that stuff is integrated into the language, standard library, and most other parts of the ecosystem.
Rust is very different. Concurrency runtime is not part of the language, the standard library defined bare minimum, essentially just the APIs. The concurrency runtime is implemented by “Tokio” external library. Rust doesn’t have a GC; instead, it has a borrow checker who insists on exactly one owner of every object at all times, makes all memory allocations explicit, and exposed all these details to programmer in the type system.
These factors make async Rust even harder to use than normal Rust.
Just because some of the C++ code I write heavily relies on ISA-specific SIMD intrinsics doesn’t replace the language with some other one, it’s remains to be C++. Compared to solving the general problem by making a sufficiently smart automatically vectorizing C compiler, learning SIMD intrinsics is way more manageable.
BTW, a few years ago I wrote an article about SSE 1-4 and AVX 1-2 ISA extensions, as exposed to C and C++ languages: http://const.me/articles/simd/simd.pdf
In Windows, the APIs provided by the OS are IMO better than these C standard headers.
WinAPI date/time is more precise, the kernel keeps int64 number of 100 nanosecond ticks. WinAPI supports arbitrary timezones, has functions to convert between timezones, has functions to deal with daylight saving.
About strings, WinAPI can convert strings between encodings, case-insensitive comparisons (including a version to use arbitrary locale), Unicode normalization, etc.
As for the generic things, I think C# is the only mainstream language which has small vectors, 3x2 and 4x4 matrices, and quaternions in the standard library.
Personally, I have reproduced the bug on Windows 10 running on AMD64 processor. BTW, the code in the question only communicates to localhost address i.e. doesn’t need any networking on the computer.
Not all questions which seem duplicate to a non-expert are actual duplicates. An example question which took 2 lines to answer, then a page of text in that answer to restore the question after being closed as a duplicate: https://stackoverflow.com/q/65025858/
The complete source code of the server is in the question.