Hacker News Reader

Comment by NeveHanter | Hacker News Reader

About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect the memory layout.

About the second one, performance should be crucial everywhere, if some application eats all the resources then I can't have other applications working in the background doing their stuff. That's the problem with i.e. "modern" communication apps (I'm talking about you, slack) where my four core CPU is on it's knees when doing simple things like switching the team or even channel, not mentioning starting the app itself. Another one is when I'm on the Google Meet chat, my browser eats 80% of CPU, I can't do anything reliably in that time, running anything makes chat to loose audio, lag a much, etc.

Going back some years ago, I was able to run Skype, AQQ, IDE, Chrome browser and Winamp at the same time on archaic (in today's standards) i3-350M and 4 GiB of RAM.

View on HN

> About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect the memory layout.

It's the same for almost all hardware: graphics cards, sound cards, all use their own register map (which, to make the matter worse, is often kept secret). Even USB stuff, which is supposed to be already homogeneized (i.e USB classes) often requires sending vendor-specific "quirk" strings to get the hardware working (e.g the list of 'quirks' in the snd-usbmidi Linux kernel module).

The hardware diversity isn't a detail here. It's the root of the "too many abstractions" problem, and I don't think this is something you can avoid. This is why device drivers exist. This is why operating systems try hard to impose APIs on device drivers (ALSA, Direct3D, etc.) so Firefox, MS Word, Half-Life ... can run on future hardware.

This is one reason why the abstraction layers exist (I'm not even talking about memory protection / safety here) : because you don't want to re-release your app every time some vendors makes a new sound card, graphics card, MIDI interface, wi-fi chip, etc. And you don't want to code the support for all this hardware yourself.

> That's the problem with i.e. "modern" communication apps (I'm talking about you, slack) where my four core CPU is on it's knees when doing simple things like switching the team or even channel, not mentioning starting the app itself. Another one is when I'm on the Google Meet chat, my browser eats 80% of CPU, I can't do anything reliably in that time, running anything makes chat to loose audio, lag a much, etc.

Again, this is a problem with programming design, not programming language. It is very possible to make good, performant programs in fancy dynamic languages, and awful, leaky, slow ones in 'high-performance' compiled languages. The impact of the language itself is really not as high as it's made out to be. Yes, python is 100x slower than c at multiplying numbers, but so what? Your program doesn't spend most of its time multiplying numbers. If you design a python program in a non-stupid way, for an application like a chat app, the performance hit compared to c is negligible.

Reply on news.ycombinator.com