noooooooooooooo
ugh. Chase sent me this today...
Longhorn
@never-released.mastodon.social.ap.brid.gy
66 followers 0 following 324 posts
🌉 bridged from ⁂ mastodon.social/@never_released, follow @ap.brid.gy to interact
🌉 bridged from ⁂ mastodon.social/@never_released, follow @ap.brid.gy to interact
![doug@edge.UUCP (04/11/87)
> If one writes portable C, does it have to be less efficient
> than non-portable C ?
>
> My project is looking at the "cost of portability"...
I can think of few cases where you can write non-portable but more-efficient
C code. Generally you will find that if you write efficient code, the code
will be portable /but the efficiency will not/. In other words, you can
tune your code to the particular compiler and machine you're running on, and
although that code /will/ run on another machine, it won't be fast.
The standard areas here are: Register variables, of course. Subscripting
versus pointers ( a[i++] versus *pa++ ). Pre/post increment/decrement,
especially in subscripts ( a[i]=0; a[i+1]=0; i+=2; versus a[i++]=0; a[i++]=0;).
Size of integers ( on a 68000 system, integers are usually 32-bit, but if
you multiply them you'll want 16-bit ints ). On some machines, "char"s are
slow to access and "short"s would be better; vice versa on other machines.
"Unrolling" loops may be advantageous on one machine, but will defeat the
instruction cache on another.
Now for a more general thought. Hope this doesn't start a flame war.
If you are more concerned about efficiency than about portability, then
consider this: There are 4 basic reasons for writing a particular program
in C instead of in assembler:
a) If efficiency is of little consequence -- the program is only going to
be run once or twice;
b) If portability is important;
c) If the programmer is ignorant of assembler; or
d) If the boss wants "BIC lighter" programmers: cheap, disposable, and
easily replaceable.
Thus (from the point of view of an outsider) if you're willing to scrap
portability in return for efficiency, you should be programming in assembler
instead of C. From the point of view of the programmer, reason (c) might
be an overriding consideration. From the point of view of the management,
reason (d) might be an overriding consideration.
-- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:4c6mk7xhclk6sgkph24kkotb/bafkreif6r3nzsxstz3jswtwwaocs2axkhdiifczdefbj65ghdcf3mllvu4)
