xcomcmdr wrote on 2025-08-26, 20:18:

And from the 2nd time this app call happens, it has already been compiled natively by the JIT, so it's even faster.
And *then* dynamic PGO kicks in, which optimizes the app over time, making it even faster.

Yeah, modern .NET is amazing, and 4 calls deep in the call stack is nothing compared to I/O delays anyway... 😁

Doing JIT and optimizations at run time are (very elaborate) mitigations for the drawbacks of not having produced native code in the first place. Having to load .NET components from disk is a cause of I/O delays. None of this is really a win from the user perspective.

Nevermind the security implications, and the performance impact, and the fact that strings are *hard* ...

There was a publicized case where a library function for user input validation was sending every string to Google servers. So... yeah.

BTW, if strings are hard, why is there an epidemic of text-based data formats? 😦

bakemono wrote on 2025-08-30, 10:14:

xcomcmdr wrote on 2025-08-26, 20:18:

And from the 2nd time this app call happens, it has already been compiled natively by the JIT, so it's even faster.
And *then* dynamic PGO kicks in, which optimizes the app over time, making it even faster.

Yeah, modern .NET is amazing, and 4 calls deep in the call stack is nothing compared to I/O delays anyway... 😁

Doing JIT and optimizations at run time are (very elaborate) mitigations for the drawbacks of not having produced native code in the first place. Having to load .NET components from disk is a cause of I/O delays. None of this is really a win from the user perspective.

The JIT compilation is done once and then cached.
The standard library is loaded are program startup, just like with a any other program.
By the time of the 'string function' we are talking about is called, there is no I/O.

.NET can be compiled AOT now. Guess what, it only reduces startup time. It does not make your program magically faster.

Because a .NET app was already a compiled program (just compiled into bytecode), and the standard library is already natively compiled.

In fact, since AOT'd code can't benefit from Dynamic PGO, an AOT'd .NET app can be a little bit slower.

bakemono wrote on 2025-08-30, 10:14:

Nevermind the security implications, and the performance impact, and the fact that strings are *hard* ...

BTW, if strings are hard, why is there an epidemic of text-based data formats? 😦

You are comparing apples and oranges.

Using libraries as intended is not really the problem.

String manipulation is part of most language standard libraries. The regex library is also available separately and can be used where needed. Strings are not hard, but we did manage to break it with all these extended character modes and escapes (think about the iconv debacle with the extended chinese character set for example)

The heaviest weighing problem is not libraries, but frameworks instead.

Frameworks are for those who don't want to code themselves and rely on others' concept of what is in vogue. Start stacking these things on top of each other, and you end up with what the modern UI / modern web convergence fuckup essentially is. That's why you need 8GB and plenty o' cpu for a couple of tabs or windows.

.NET is a framework... formerly known as .NET Framework... 😁

I've been saying this for years.

There have been proofs of concept programs that crammed full FPS games into less than 100Kb

If you're telling me an operating system or game needs to be tens to hundreds of GB. absolute nonsense.

This is where I'm wondering if one day we might be able to feed old software into AI engines and out would pop the same software that not only ran faster but was a fraction the size.

Oh that's easy.
You just use the original version from the 90s.
Aside from output format there's not a huge amount of improvements for the vast majority of users between Word 97 and today's. Given the format issue, doc vs docx, the oldest that can realistically be used is word 2003.

As for games, if you look closely at the exe/dll sizes, you should see they haven't grown that markedly, but it is the maps/textures which have grown enormously.
Eg the core executable code might be 10x the size, but the assets are more like 500x.

This is largely a function of detail and isn't really possible to prevent without cutting the detail.
A monster in quake might have been 100 triangles with a 1mb texture wrapped over it.
A contemporary game could easily be 100k triangles and 200mb textures uncompressed.
Then add the animation instructions.

Then consider the map detail and uniqueness of each asset. A game like bf1942 had maybe 6 different trees and 3 rocks in the whole game and the maps were an 8 bit 256x256 bitmap interpreted as a heightmap with variable but generally pretty sizable distances between points.
Modern maps, if/when they are heightmaps are many times more granular.

So yeah... Modern games to an extent have to be the size they are because the detail is much higher.

Falcosoft wrote on 2025-05-28, 04:52:

Pipelined FPU was not a 'feature' but a microarchitecture implementation detail. There was no CPUID feature bit associated to it […]
Show full quote

myne wrote on 2025-05-28, 00:18:

Back in the day Carmack and even Microsoft would have multiple code paths depending on feature support.

Pipelined FPU was not a 'feature' but a microarchitecture implementation detail. There was no CPUID feature bit associated to it. You could detect the the presence of an FPU and Cyrix/AMD CPUs reported they had one.
Some FPU instructions like FXCH were virtually free on the Pentiums and Quake's code used these very extensively. But they were not free on any other x87 units. Of course id Software could write alternative code paths using a dispatcher based on e.g. CPU vendor string (like Intel compilers have done it for a long time). But in this case when the Athlon was released with an even superior pipelined FPU it would have used the inferior/slower code because of the 'unfair' dispatcher based on CPU vendor string detection...
BTW, some may argue that thanks to Quake 1/2 all later FPU implementations had to make the FXCH instruction virtually free 😀

To be fair they could distinguish between not only the CPU vendor but also the CPU model and speed, so they could easily tell whether it was a K5/6 or an Athlon, and make then use different paths. It's just.. They never bothered. To be honest, K5/6 probably never really had a significant marketshare anyway.

Sphere478 wrote on Yesterday, 04:19:

There have been proofs of concept programs that crammed full FPS games into less than 100Kb

If you're talking about demoscene productions like ".kkrieger", I highly suggest you look at the memory usage after it fully "decrunches", I think you'll be surprised how much resources that is actually taking up compared to the size of the EXE you run.

Not to mention the amount of time it takes until the game is actually fully loaded and usable...

appiah4 wrote on Yesterday, 11:26:

Falcosoft wrote on 2025-05-28, 04:52:

Pipelined FPU was not a 'feature' but a microarchitecture implementation detail. There was no CPUID feature bit associated to it […]
Show full quote

myne wrote on 2025-05-28, 00:18:

Back in the day Carmack and even Microsoft would have multiple code paths depending on feature support.

Pipelined FPU was not a 'feature' but a microarchitecture implementation detail. There was no CPUID feature bit associated to it. You could detect the the presence of an FPU and Cyrix/AMD CPUs reported they had one.
Some FPU instructions like FXCH were virtually free on the Pentiums and Quake's code used these very extensively. But they were not free on any other x87 units. Of course id Software could write alternative code paths using a dispatcher based on e.g. CPU vendor string (like Intel compilers have done it for a long time). But in this case when the Athlon was released with an even superior pipelined FPU it would have used the inferior/slower code because of the 'unfair' dispatcher based on CPU vendor string detection...
BTW, some may argue that thanks to Quake 1/2 all later FPU implementations had to make the FXCH instruction virtually free 😀

To be fair they could distinguish between not only the CPU vendor but also the CPU model and speed, so they could easily tell whether it was a K5/6 or an Athlon, and make then use different paths. It's just.. They never bothered. To be honest, K5/6 probably never really had a significant marketshare anyway.

When Quake was written/released there was no Athlon (model number was also unknown) . So id software could not have written a fair dispatcher for a hypothetical AMD CPU with pipelined FPU that should have been handled differently than K5/6. Since no dispatcher was present in the code when the Athlon was released it was fast with Quake/Quake2 without needing any patches.
If an AMD specific code path was implemented when Quake's code was written most likely the Athlon would have been a victim and would have run slower when it was released.