Hacker News Reader

The statement "the software we use is up to 100 times slower than it needs to be" is not OS overhead (which is relatively small) but about user-facing application software written to optimize development speed/cost and not performance.

A reasonable game is performance focused and is spending most of the computing power directly on itself (even if perhaps not optimally and not utilizing specific GPU hardware to its full extent) and not in OS routines, so an OS providing a specific "game mode" with only the bare minimum amount of OS the game needed to run can perhaps bring a 5% or 10% performance improvement, but not 50% and definitely not 100 times performance increase.

For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software.

The example of this article about UnrealEngine and Vulkan is a good illustration - a game targeting the specific hardware directly could achieve the same performance (and more!), however, they are not going to, nobody is going to rewrite the game because that's expensive, so getting an OS abstraction layer like Vulkan - which inevitably adds some extra performance overhead, not reduces it - is the only reasonable way to go.

Maybe it's because I've been on Windows for too long, but people are always complaining about how terrible Windows 10 (and soon to be 11 is) as an experience (See recent slowdown with AMD processors). That and a little bit too much time watching all the cool things people did with 1mhz processors with no L1 cache or graphics, on 80s computers. As someone who wasn't around during that time, it's easy to get the feeling that a 1.5ghz quad core cpus +.5ghz gpu should absolutely slay any program, but in my experience using the RPI4 as a primary computer it hasn't felt that way.

> For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software.

I think this is insightful. I agree that not everything would be 100x, but I feel like at the level of an RPI 4 even a 5-10% improvement that bumps a game into 30 or 60fps territory would be noticeable. And even a 2x improvement in regular apps would have impact.

The reason you feel RPi4B aren’t performing is because it’s running software written using 2010s and 2020s software standards, languages and runtimes.

Before 2000, many many commercial games and software were written using “classical” C/C++ and had any performance critical areas written in assembly language. People would actually profile their apps and optimize their code and loops. Most any language that had large runtimes or included a garbage collector was not considered an option. Only the most complex, data oriented or GUI oriented parts of the code would be written in high level language. A good example of this mixed language code base is the Allegro 4.x Game Programming Library for DOS, Linux, and Windows.

Going back further into the 80s and 90s, many many commercial games and software were written in all assembly language. Look at the old MS DOS code bases on GitHub for a reference.

All that to say that modern software does a ton things in periphery that old software considered superfluous. We know some of it makes easier to write software, or that the software is more secure, or that it can take advantage of the features of the hardware old machines didn’t have. However, that is still extra code that needs run, often in (event) loops which multiples the amount of time dedicated to that code.

Look at codegolf or other minimal code challenges to see what could be accomplished with a different programming process.

> OS written just for the RPI4

Linux and NetBSD can be configured to be as good as if they were written just for RPI4.

Mouse and keyboard are as standard and supported as they can possibly be, and the official Raspberry Pi ones are ordinary USB ones supported everywhere. Touchscreens supported in Linux are supported well out of the box as well (e.g. my Dell ones). "100 times slower" sounds like nonsense to me; huge numbers of people are motivated to make software faster, so if there was that much room to improve, it mostly would have happened already.

Yes, I recently was investigating USB keyboard/mouse usage on a microcontroller and found out it's not too difficult to implement: https://www.networktechinc.com/usb-prots.html

>code making use of the fact that we are running on known hardware

>you focused on supporting the official raspberry pi keyboard, mouse, and touchscreen you could circumvent a lot of the pains around driver issues

I'm afraid that's how closed, non-extensible systems are born, and later inevitably die.

I agree. But the context of this is around a solo developer doing this as a hobby OS. And these constraints would help the project have reasonable scope assuming no-one else expressed any interest in it.