uecker

12 ms·

271.
by uecker 5mo ago
Yes, and CreateProcess needs special facilities to make this possible while in the UNIX model you don't.
272.
by uecker 5mo ago
Yes, threads are a complication, but this still not "the opposite".
273.
by uecker 5mo ago
I meant the value of running syscalls in another process from the parent process in contrast to (v)forking and running them in the child directly.
274.
by uecker 5mo ago
If you use pipe() you get two ends in the same process, then you fork and child and parent can communicate. This is how a unix shell setups up pipes and it is rather elegant.
275.
by uecker 5mo ago
Maybe, a few people proposed this. It is a lot better than a single spawn call. But how often would one actually need this? And what are the semantics? Refer arguments (e.g. file descriptors) to the current process or the other one? How ar
276.
by uecker 5mo ago
A lot of features of UNIX shells are build around pipe and dup and the fork + exec model. One can certainly implement in differently, but it is - like UNIX in general - very nice and elegant.
277.
by uecker 5mo ago
A ptrace_syscall would be interesting and would seem to be a full replacement for having the pid argument everywhere. But frankly, I am not really seeing the value.
278.
by uecker 5mo ago
Weren't there enough parallel paths of development in this world?
279.
by uecker 5mo ago
Well, a lot of the power of the UNIX shell comes form this and I see this as a major advantage over Windows. So no, I do not think Windows got it right. Any kind of replacement should aim for the same conceptual simplicity and power. Sadly,
280.
by uecker 5mo ago
Maybe, I am not saying fork() + exec() model couldn't be improved, but most people saying it is "terrible" and it needs to die seem to go on to propose something substantially worse.
281.
by uecker 5mo ago
The elegance of the fork() + exec() model is that every kind of configuration can be done after the fork using all the usual APIs. Every attempt to replace it with a combined call that I have seen so far seemed fundamentally poorer becaus
282.
by uecker 5mo ago
This is how I designed my vector in C. Note it is still not frozen as you can use realloc just fine (even with good performance) and/or external tracking of the capacity in tight loops. https://uecker.codeberg.page/2025
283.
by uecker 5mo ago
I think this hits the nail on the head. All the features of C++ help you write a code which you should have written in a much simpler way in the first place.
284.
by uecker 5mo ago
The world screwed itself by not investing in renewables earlier. Germany paid a high price for being early, but we all should be thankful for Germany creating an economy of scale and bringing cost down. And while the extreme right wing prop
285.
by uecker 5mo ago
As far as I have been told, they were not made optional because of any issues with VLAs (which exist also in many other languages, including Ada) but because adoption of C99 was slow, so some parts were made optional in C11. Later VLAs wer
286.
by uecker 5mo ago
No, you did not address my argument. You need to show that it is impossible (or hard) to do function cloning when using interprocedural constant-propagation in a situation where monomorphism does this. But nothing you said contradicts this
287.
by uecker 5mo ago
This does not have much to do with my point, but, anyway, basically any C compiler supports them. MSVC does not, but it also does not support a recent standard so you can not use MSVC to compile C, just some outdated subset.
288.
by uecker 5mo ago
VLA usage can also be analyzed (e.g. when bounded in a simple way by a function argumen) and then may allow reduced stack usage compared to fixed-size arrays sized for a worst case.
289.
by uecker 5mo ago
But your example did not show that the compiler lacks the contextual information. My argument is exactly that in all cases where one can do monomorphization, this contextual information is trivially available because it simply a small part
290.
by uecker 5mo ago
Both C and C++ compilers (in fact, they share this part) very aggressively exploited undefined behavior for performance. But I this was certainly not adversarial. Programmers also regularity picked optimizations over safety. I think nowada
291.
by uecker 5mo ago
In don't think this is required in C++ either.
292.
by uecker 5mo ago
It is trivial to see that the compiler could do inlining also in this case. Your modification does not "break" inlining in the sense of making it impossible. In fact, just making the vtables "const" is enough and it doe
293.
by uecker 5mo ago
The thing is that I rewrite high performance numerical code on GPUs and the CUDA part is what sucks most. And the moment one uses templates, the compilation times make it insufferable. I really do not understand why people put up with this
294.
by uecker 5mo ago
Here is my proposal with a lot of similarities: https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3212.pdf
295.
by uecker 5mo ago
I see, this is what you meant. GCC can not currently do this. But this also not something that would correspond to a monomorphic version. A polymorphic function over a generic array would be specialized to one member type via monomorphizati
296.
by uecker 5mo ago
I see that they spend time making their hardware run general software, but I can't see anything specific in GPU hardware to std::mdspan. I respect Ada but I would not want to use it. But I have a choice between C++ with hmdspan and C99
297.
by uecker 5mo ago
I does not work fine in C++ when N and M are not compile-time constants, which is basically always the case in any interesting numerical algorithm. Also not in Rust. It works fine in C though, or FORTRAN, or Ada, or ALGOL 60, ...
298.
by uecker 5mo ago
I don't see why it would easy to lose type information in circumstances where you can do monomorphization. Note that I do not assume "perfect deductive ability". The practical observation is simply that it is far more effort
299.
by uecker 5mo ago
You are telling me what my point was?
300.
by uecker 5mo ago
Maybe, but also irrelevant to the discussion because whether you write mat[b * A + a] by hand or mat[b][a] and let the compiler frontend expand then makes no difference to the optimizer.

More ›