Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!hpislx!hplvli!boyne
From: boyne@hplvli.HP.COM (Art Boyne)
Newsgroups: comp.sys.ibm.pc
Subject: Re: High- vs. low-level languages (Was: Re: Why unix doesn't catch on)
Message-ID: <360016@hplvli.HP.COM>
Date: 22 May 89 14:34:13 GMT
References: <664@tukki.jyu.fi>
Organization: Loveland Inst. Div
Lines: 49

gph@hpsemc.HP.COM (Paul Houtz) writes:
>I think the original point of this posting was someone trying to put forward 
>the ridiculous idea that you should use assembler instead of a high level
>language?
>
>   Sort of like using a spoon to cultivate a cornfield.
>
>   Look.   Code size reductions are becoming less and less important anywhere
>   on computers.

	Ah, I can see that multi-megabyte HP-PA machines have spoiled you forever.
	Have you no sympathy for those of us who still use 8051's with 256 bytes
    of RAM and 4K of ROM?

>   99% of all computer code is not performance bottlenecked.

	Well, probably 90+%, anyway.  But I'm the guy they assign the other 10-%
    to, because I *do* know how to use assembly code effectively, and most
    other programmers prefer not to get their hands dirty.

>   Use a high level language and write good, straightforward code, and don't
>   worry so much about performance.    

	Obviously the attitude too many OS people have taken on too many systems.
	Anyway, try telling that to my boss who set performance goals for me.

>   Then, analyze the code at run-time, and figure out where the bottle necks
>   are.   You can then really leverage a small amount of time re-coding those
>   bottle necks in assembler, if necessary.  
 
	True.

>   Does it make sense to code a routine in assembler so that it runs blindingly
>   fast, if all it does is block on a terminal I/O  operation?

	Sometimes *YES*!!!  For a real-life example:  integrating voltmeters are
    typically slow.  One could argue "Why put a lot of effort into GP-IB
    performance when the voltmeter will take many milliseconds to take a
    reading?"  Reason: because GP-IB bandwidth is a shared resource between
    many instruments, and performance-conscious users want to maximize
    throughput by sending groups of commands quickly to many instruments,
    then letting them parse/execute in parallel.  A slow handshaker on the
    GP-IB slows the whole test system down.

    Besides, who says that there is a terminal out there on the end of that
    line you are talking about.  Perhaps there is a PC wanting to talk long
    distance at 9600+ baud.  You slow him down and you are costing him real $$.

Art Boyne, boyne@hplvla.hp.com