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 2025-09-02, 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 2025-09-02, 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.

DracoNihil wrote on 2025-09-02, 13:16:

Sphere478 wrote on 2025-09-02, 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...

.kkrieger is awesome.

Like any demoscene thing, however, you are limited to the kind of assets you can algorithmically generate.

There are much more degrees of freedom when you build assets by any other means and just save them to file, large as they are.

Modern “games” are anyway mostly large asset collections running on an outsourced engine like UE or Source.

st31276a wrote on 2025-09-04, 08:49:

Modern “games” are anyway mostly large asset collections running on an outsourced engine like UE or Source.

Is Source supposed to be widespread? I got impression Source was (is?) terrible to work with.

https://youtu.be/tD5NrevFtbU

UCyborg wrote on 2025-09-04, 18:59:

st31276a wrote on 2025-09-04, 08:49:

Modern “games” are anyway mostly large asset collections running on an outsourced engine like UE or Source.

Is Source supposed to be widespread? I got impression Source was (is?) terrible to work with.

Lots of steam stuff is / used to be source based. It was quite popular with the linux embracement a decade or so ago.

Unreal engine is just an engine these days, the last unreal game came out 18 years ago but the engine is still being developed and selling strong it seems.

st31276a wrote on 2025-09-04, 19:16:

https://youtu.be/tD5NrevFtbU

Interesting watch. Talk about superfluous language features.

But devs these days are often fine with wasting resources because they can, they'll say it doesn't matter because we don't use CPUs from 90s anymore. I personally disagree, fast code is fast anywhere, slow code is not.

I find that it's mostly I/O that is wasted.

All those super heavy websites, Cloud resources... LLMs with vast amount of data to produce AI slop...

The information highway has devolved into the information junkyard.

Microsoft recently released source code of Microsoft BASIC 1.1. How did they make sense of it all back then? Well, I still don't understand how they make sense of number of current day things.

UCyborg wrote on 2025-09-05, 16:35:

But devs these days are often fine with wasting resources because they can, they'll say it doesn't matter because we don't use CPUs from 90s anymore. I personally disagree, fast code is fast anywhere, slow code is not.

x2

I/O wasted just means the thing is huge, as I/O is insanely fast these days.

Huge means not only wasted memory, but usually also wasted cpu time.

Three or four cores can be pinned at 100% utilization on a modern octacore machine and you wouldn't even know it if you didn't look.

Falcosoft wrote on 2025-09-02, 14:31:

appiah4 wrote on 2025-09-02, 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. 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.

That's all fair, thanks 😀