Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> caring about the assembly output is a spectacular case of premature optimization

I don't agree! at least for operating systems.

Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case.

I also like the idea of "optimality" brought forward by zig. In the post you link, there's an ideal hello_world in asm, can we have a higher level language that doesn't sacrifice this ideal achieved by assembly?

Consider that some network cards are now capable of 400Gibps, and modern OSes are not capable of handling these linerate. I strongly believe the bottleneck should be in the hardware, if the software can't max out your hardware then your software has failed.

I like that zig focuses on optimality.



> Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case.

I would believe that most of the time of a processor is dedicated to run userspace code, not OS code (regarding to the work that must be done). At the end of the day, the OS is "only" a scheduler to share hardware resources between unrelated tasks.

> I like that zig focuses on optimality.

Optimality isn't required in many real world businesses. Optimality is often a tradeoff : with optimality you lose in flexibility. An optimal program with SISD instruction set isn't optimal anymore when SIMD instructions are introduced. Your "optimal" asm program is still optimal on x86, but also totally obsolete because it cannot use the latest NEON instructions from ARM or 64bit instructions.


> I would believe that most of the time of a processor is dedicated to run userspace code, not OS code (regarding to the work that must be done). At the end of the day, the OS is "only" a scheduler to share hardware resources between unrelated tasks.

Yeah, that's true if the OS is well-written and has had continual and extensive performance work done. Passing 200 Gbit of network traffic in software with firewalling is non-trivial and the number of cycles you get per packet is pretty modest. These things do matter.


> Passing 200 Gbit of network traffic in software with firewalling is non-trivial and the number of cycles you get per packet is pretty modest

If that's the only function of the program, are we still talking about an "Operating System" ?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: