Hacker News Reader

Comment by unsatchmo | Hacker News Reader

"Windows, Linux, Mac OS X, and the BSDs we have today are still built using the architecture developed when computing resources were limited even though it is no longer technically necessary."

Nonsense! Why would you waste any resources on infrastructure when you could use them for applications. Every cycle that your garbage collector runs is a cycle that the cpu could have been sleeping and saving battery life. This concept that we don't need to care about resources anymore is absolute poppycock.

View on HN

>> Why would you waste any resources on infrastructure when you could use them for applications.

For the same reason we waste them on application frameworks instead of more interesting computations - because applications are written by humans, who take a long time to do it and are notoriously bad at it. Every cycle your garbage collector runs supports the existence of software that might not exist yet, or ever, without it.

I am all for advanced memory management in application frameworks. The OS however isn't something you're going to rewrite very often so work harder and squeeze out efficiency so that your apps get them.

why not? if it's all hot swappable and development at that level is as easy as in user space

OSes are constantly in development. Making development faster and easier could very well lead to a more efficient system. Faster and easier development makes it easier to test out new ideas and spend more time on optimization since it took less time to make the actual feature. Sure, if hardware never changed and the feature set never changed then you could just write the whole thing in assembly and make it as efficient as possible but that isn't reality. When it comes to software requirements and limitations are always changing so making it easier to adapt to those may in the end be the more efficient solution.

> Nonsense! Why would you waste any resources on infrastructure when you could use them for applications. Every cycle that your garbage collector runs is a cycle that the cpu could have been sleeping and saving battery life. This concept that we don't need to care about resources anymore is absolute poppycock.

It isn't that simple. Depending on your program it can actually be slower to do manual memory management. malloc isn't free. In some cases allocating memory and performing GC is actually faster.

It's not that we don't have to care about resources at all just that we can sacrifice some of the resources to improve the situation for users and programmers. If that isn't your thing then feel free to write everything in assembly.

This isn't an either or. The reason your phone gets all day battery life is because the kernel was designed to run well on an i386. Let the app frameworks have cushy memory management but implement the OS in C.

> The reason your phone gets all day battery life is because the kernel was designed to run well on an i386

This is false. The reason your phone has the battery life it does is because the OS and libraries and applications have been written to allow the hardware of the phone to drop in to lower power states as much as possible. Unless the language you have written your OS in has some bizarre requirement to wake up all the hardware constantly then the language doesn't matter a ton when it comes to battery life. What matters is writing programs that wakeup the hardware as infrequently as possible.

CPU deep sleep states ?

> it can actually be slower to do manual memory management

> we can sacrifice some of the resources

Which one is it?

Many times it is less resource intensive to do manual memory management, it just depends. The sacrifice in performance comes more from runtime features like type checking.

The only case that I know of when manual memory management is slower is short-running programs which exit before the first GC run, therefore removing the need to do any deallocation at all.

The advantage isn't really in that resources can be wasted by adding a feature like garbage collection, but that if you are going to have features like that in your programs, building it in at the OS level is a better way to go about it, as it aggregates the resulting issues in one place, where it can be better managed(at a whole-system level).

Because the cost of achieving that level of efficiency is often not worth it.

This is an operating system. Efficiency is a feature, and this project is a bunch of hooey.

the same argument could be had against languages like Python, ruby, and JavaScript. making things easier to develop against often means that complex things exist that make things faster.

look at pypy for example: Python interpreter written in Python that's faster in many cases than cpython because they could build advanced features for optimising the underlying running code. writing an OS in C because efficiency seems like a load of hooey to me unless you have facts to back up your idea that for some reason the OS has to be the efficient thing.

software development comes down to 1 thing: delivering features. who cares if you need twice the servers to run your product of the alternative is you run out of runway and your project gets canned. hardware is cheap, engineering time is not

>who cares if you need twice the servers to run your product

I couldn't help but wince at this. I feel like this isn't a healthy attitude with respect to programming.

Okay, how about this hypothetical?

Ask yourself if the service you're trying to create would have been valuable, say, 4 years ago. Yes?

Okay, suppose you wrote it in C++ 4 years ago on four year old hardware? Is it still valuable? Yes?

Okay, now write it today in Node and run it on modern hardware. The hardware cost is the same, the service exists, and it was presumably cheaper to write and maintain in Node. Is it still valuable? Yes?

That's why it's reasonable to write apps in Node.js today: the performance and cost are the same as doing it in some "more efficient" language 4 years ago, except the cost to actually build the thing now in Node is (much?) lower.

If you were okay with the hardware costs for the service 4 years ago written in C++, you should be okay with the hardware costs for the service today written in Node.

You can use this argument to support "slow, inefficient" languages for many different kinds of projects (though not all, obviously). And I'm an efficiency nut.

Reply on news.ycombinator.com