[ExI] Weird new way to do physics

Tomasz Rola rtomek at ceti.pl
Sun Nov 6 22:45:39 UTC 2011


On Sun, 6 Nov 2011, Stefano Vaj wrote:

> 2011/11/4 Tomasz Rola <rtomek at ceti.pl>:
> > Ouch. If you want to stay high-level so much, consider learning a language
> > that has better compiler (I may be not current but last time I checked,
> > Python's compilers didn't impress me too much, which was probably my
> > fault).
> 
> What's wrong with dear, old Assembly for performance-sensitive tasks?

Nothing is wrong with that. Except few things.

One is, there is no point to do trivial things faster. Like, 15 yrs ago 
one buddy of mine (or maybe his buddy) did directory listing routine that 
performed 20-something times faster than original DOS command. I imagine 
he spent considerable amount of time to design, write and debug this 
thing. Now, today, this kind of stuff is simply fast enough. I could even 
write my own "dir", or rather, "ls" on Linux, in Perl or Python (I mean, 
reading physical blocks from a disk etc), throw computing of some lower 
Fibonacci number in between the lines, and I guess it would still perform 
with acceptable speed. Thanks to cpu speed increase.

There would still be some speedup if I did 'ls' in assembly, but while 15 
years ago it was comparing 0.1s to 2s, nowadays it takes no more than few 
thousandth of second (and this is in case of very big directory). In 
simpler cases, there is no way to tell any difference between C and 
assembly without specialised utilities to measure their times.

Next, in case of modern well written OS I would expect C routine to 
outperform an assembly one. Because a modern OS is expected to cache disk 
blocks in RAM. One can, of course, replicate all those mechanisms in 
assembly, and after years (maybe months) of debugging, maybe there would 
be a noticeable difference. But chances are, nobody would care or take 
notice.

Not to forget - cpus are changing. With out of order execution and other 
hardware optimisations, one can get 2x-3x speedup by properly ordering 
instructions in one's code (not always, mind you). But since there are so 
many different cpu models, what speeds work on one will slow it on 
another. The best bet, I think, is to write in C and wait for compiler 
developers to take care of it. After that you can just recompile with 
newer compiler.

Even more, as GPU computing enters a scene and one can have graphical 
cores integrated into cpu, it is easy to imagine program written in OpenCL 
(a C-like language for graphical cores) outperforming the best possible 
classical (say, x86) assembly ran on the same cpu (again, this doesn't 
mean that every code will outperform).

Last but not least, non-trivial problems are getting harder and harder to 
understand. Thirty years ago it could be algorithm for cache or hashtable 
management. Today it's proving program correctness, for example. Compiling 
a code to optimal assembly is another nice problem. If one is going to 
write theorem prover, one should better choose a language that is easy to 
debug, because we don't need false theorems even if this means we get good 
ones after a month rather than after two days.

It is not that assembly is bad. It's just that number of problems where 
using it had sense had shrinked a lot. There is still some place for it, 
like smaller computers, and even if the whole program is written in C 
sometimes it makes sense to have alternative, special hand optimised 
assembly version of some functions.

Also, it is perhaps worth noting, that number of people who have any wits 
and are able to program working code in their memory does not grow, IMHO. 
Even though demand grows (probably). Sure you can get programmers of 
todays-most-popular-lang dozen a dime, but they are only as good as their 
IDE. It is ok, because there is umpteen thousand problems that such 
primitive tools can solve and one doesn't need Einstein for this. Not even 
Edison. However, I wouldn't like to see some type of folks meddling with 
code on nuclear submarine or managing air traffic. And now we have drones 
and they are going to be more and more autonomous. One day nuc subs will 
autonomously lay on the ocean floor, waiting for their day.

So it makes sense to give those who have wits the best tools that maximize 
their ability of turning idea into code. Cpu time is expendable. Human 
time is not. Thus assembly slowly goes out of the picture, even though 
there will always be guys using it. There should be.

P.S. The fact that some guy does click his way around his code in IDE does 
not necesarilly mean that he has no wits mentioned above. But if he cannot 
say how big is his program (in lines, in megabytes, or in hours), turn 
your doubts on. Or if umteen years pass and he doesn't learn something 
better (actually, I would start worrying after um years rather than after 
umteen).

All of the above is my holly-schmolly opinion, excepts from fake blogs and 
fake news etc. Maybe even fake anecdotes.

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola at bigfoot.com             **



More information about the extropy-chat mailing list