Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

I made my own DOS implementation (Announce)

posted by Rugxulo Homepage, Usono, 30.03.2024, 10:16

> Nowadays many developers want to drop support of CPUs that don't have SSE2
> instructions, and they are basically using those new instruction set
> extensions as a tool to bully people who have an "old" computer that still
> has more than enough computing power for their use.
Those kinds of people upgrade every few years, maybe because of their workplace forcing them. They probably don't have the same import taxes or high shipping costs as you.

Also, when a compiler (or library) drops support for a certain OS or cpu family, someone else has to take up that burden or leave it abandoned. If one piece is missing, it's easy for the whole thing to crumble. "Tier 1" is almost always AMD64 (v2?) and maybe ARM64.

> They are reasoning it
> by saying that the new instruction set extensions make the program run
> faster, when the reality is that every new version of the program is always
> more bloated than the previous one. This culture is especially visible
> amongst the Rust gang and the developers of many graphical desktop
> libraries in the FOSS world.
CLMUL (circa 2010) claims to be faster. Have I ever used it? No.

I did, years ago, find 2x speedups in PAQ8 with his SSE2 patches. Actually, at that time, MMX or SSE2 was roughly the same speed. SSE2 improved more later. But my fork wasn't locking anyone in to specific OSes or cpus. (His default build was MinGW G++ 3.4 targeting MMX using MVSCRT.DLL that had a stupid tmpfile() bug on non-Admin Vista, so I rebuilt with newer DJGPP using CPUID. And I wanted CWSDPMI support so that it could swap to disk if needed. OpenWatcom/Causeway also worked but much less efficiently [worse malloc, slower swapping].).

Oscar Wilde said, "A cynic is someone who knows the cost of everything and the value of nothing."

> They are purposely writing code that breaks when sizeof(long) is not 64,
> and are writing makefiles that override the CFLAGS that the user has set,
> resulting in a binary that has a different CPU target than was intended by
> the user. This type of behaviour is unacceptable. When the program has zero
> lines of assembly, there is absolutely no reason to artificially limit its
> portability by preventing building it to certain CPU targets.
While I 100% agree, strict ISO C has never been meant to be portable. They explicitly allow non-portable things. (Heck, PAQ8 was pre-C++11 and didn't compile on AMD64 due to such bugs. It was also single core only and very slow but still very good.)

Actually, even ISO C only mandated that "long double" equal double, which is what MSVCRT does (or did, in the old days), same with OpenWatcom (unlike GCC). And I don't think AMD64 supports beyond "double" directly anyways. So FPC's Extended type is unsupported on AMD64. (AVX probably fixes that, but that's yet another can of worms.)

I believe the Linux kernel is roughly C11 (without VLAs) with GCC extensions of course.

> And my example shows that using those new instruction set extensions like
> MMX and SSE2 does not always even make the code faster. SSE2 can do 64-bit
> math natively, so there is less code involved in adding 64-bit numbers, and
> it should be faster in theory, but not always in practice. The user must
> always have the option to build and optimize the code for their own
> computer, even when the computer is "old" or something else than intended
> by the original developer of the software.
Old also means a lot of things. I remember my P4. It was single core only (mainly noticeable during antivirus scans, ugh). It had some USB 1.1 (slower) and some USB 2 ports. It was using a traditional hard drive (non-SSD). The 512 MB of RAM was probably DDR2. You can compare cpus from 2004 to 2020 to see a difference.

> I just find it weird when a software developer, who doesn't even write
> assembly, suddenly says that someone else's computer is "too old" or "too
> slow" and must not be "supported" anymore. If we consider that that "someone > else's computer" is a turing-complete machine that has enough memory to run
> the program in question, and has enough computing power that its owner does
> not consider it "too slow", the software developer should not have the right > to say that it is.
IIRC, the PlayStation 5 and XBox Series X are both Ryzen 2 with 16 GB of RAM. Compare that to 2013-era PS4 and XBoxOne. My point is that nothing is ever good enough for some people. (But they do try to do a lot more with HD/UHD/4k/whatever.)

> The job of the software developer is to just maintain the program, and
> generally when we are speaking of relatively high-level userspace programs or > their libraries, they compile to older x86 hardware just fine, unless
> something is actively preventing it from happening. Breaking compatibility
> with 32-bit x86 CPUs and/or pre-SSE2 CPUs will most likely also break
> compatibility with many non-x86 targets.
For many years the world has already tried to deprecate and kill IA-32. Ubuntu doesn't support it anymore (since 2019?). Like I said, people are arguing over whether x64 v3 should be the new baseline or not.

They don't really sympathize with people who don't upgrade every few years. (I would say every five years would be nice, but it's usually shorter than that.) A lot of software won't work on Win7 or 8 anymore. Heck, for laughs, I sent my mother an email about Cygwin. They used to support Win9x. Then it was XP (for Unicode). Then they dropped IA-32. Then they dropped older OSes (like Win7/8).

Linux is all about choice. But often that choice is "not invented here!" or "UNIX only!" or "we don't care about anything before 2017!". Roll your own, develop your own ... easier said than done. Face it, "portability" is not a priority for most people.

To some people, RAM unused is wasted. You know, ulimit says their stack is "unlimited", and virtual memory and AMD64's 48-bit addresses just encourage wasteful practice. (Granted, trying to do everything in 64 kb is unrealistic. But a home user REALLY shouldn't need 64 GB of RAM for anything!) I'm not saying we should all target 286s or use 486s to identify our algorithms' bottlenecks. But meh, the modern world is not optimal. ("We don't have time! It costs money! We don't have a test setup!")

You know what's slow? Recompiling headers over and over again. (But C++20 fixed that. "Just throw more cores at it!") Garbage collection. Bytecode. Quadratic algorithms. Cpu cache thrashing. AutoTools/Configure under Cygwin. Slow software emulation (because xyz isn't supported anymore). Bugs. Limits.

The whole point of "computer science", I thought, was to not be tied to any specific technology. In other words, don't rely too heavily on any cpu or OS or compiler or language dialect. They don't last. You have to do everything yourself. (Well, sometimes other people help.)

But yes, talk is cheap, and "upgrade!" is never useful advice.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 23 users online (0 registered, 23 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum