Re:Red Hat Expecting X.org to “Go into Hard Maintenance Mode...
by hedora on Friday June 28, 2019 @11:10AM
(#20305081)
Let’s compare the alternatives to forking for a floating point op (ignoring the fact that it would be easy to add this to the shell if it were common enough):
The Unix way pays to fork a process for a floating point operation in shell, then delegates the expensive work to something written in an appropriate (probably compiled, maybe vectorized/gpu optimized) language. Forking the process took 10-100s of usec. If the hard work is comparable to this, the prompt returns immediately, so it is fast enough. If the hard work is non-trivial, the fork for the floating point op is << 1% of the runtime. Either way, the fork is effectively free.
The “modern” ways (which Unix mostly killed off in the 70’s, but that are currently in revival), are to write the hard work in a high-level, and usually interpreted language or write the process control logic in a lower level language.
In the case of the high level language, the hard work is now ~2-10x slower than unoptimized logic in a compiled language, so you spend ~50-90% of your time in useless overhead.
If you move the process control to a low level language, then it is more verbose, and you also have to recompile (or jit) the bulk of the program, which is much more expensive than forking a process. It likely takes 10s or even 10,000s of milliseconds!
There is a reason Unix won back when machines were orders of magnitude more expensive than they are now. (And why is it still more usable than its competitors today.)
The Unix way pays to fork a process for a floating point operation in shell, then delegates the expensive work to something written in an appropriate (probably compiled, maybe vectorized/gpu optimized) language. Forking the process took 10-100s of usec. If the hard work is comparable to this, the prompt returns immediately, so it is fast enough. If the hard work is non-trivial, the fork for the floating point op is << 1% of the runtime. Either way, the fork is effectively free.
The “modern” ways (which Unix mostly killed off in the 70’s, but that are currently in revival), are to write the hard work in a high-level, and usually interpreted language or write the process control logic in a lower level language.
In the case of the high level language, the hard work is now ~2-10x slower than unoptimized logic in a compiled language, so you spend ~50-90% of your time in useless overhead.
If you move the process control to a low level language, then it is more verbose, and you also have to recompile (or jit) the bulk of the program, which is much more expensive than forking a process. It likely takes 10s or even 10,000s of milliseconds!
There is a reason Unix won back when machines were orders of magnitude more expensive than they are now. (And why is it still more usable than its competitors today.)