
Ada Outperforms Assembly: A Case Study - cygwin98
http://www.seas.gwu.edu/~adagroup/sigada-website/lawlis.html
======
Stormbringer
From the article it describes the assembly programmer as an: "experienced
assembly developer"

From the article it describes the ADA programmer as: "This developer had very
limited Ada experience, having written only one Ada program, consisting of
approximately 5000 lines of code, while working for a previous employer."

One of the key points of the article is that the code produced by the
inexperienced ADA developer beat the experienced Assembly developer. I think a
lot of people will struggle with this (because they think "well, logically the
code gets turned into assembly anyway when it is compiled, so a sufficiently
advanced assembly programmer _must_ be at least as good as a compiler), but
the same claims (high level languages beating assembly) have been floating
around for years.

In this case study at least, jumping straight to assembly (for
size/performance reasons) turned out to be a premature optimisation of the
sort we should avoid.

~~~
Someone
I do not find this example convincing. The assembly was written and, I assume,
optimized for one CPU, but it was timed on a more expensive, _pipelined_
processor.

The Ada compiler was written for that processor. That could make a big
difference. For example, starting every function on a mod 16 boundary can be a
big win on some architectures.

------
zwieback
I worked with TI320 in the same time period quite a bit and remember the
Tartan compilers (not Ada, though). It's easy to believe that a compiler beats
a naive assembly code writer. The pipelining example is a good one, it can
take hours poring over the manual to figure out how to best arrange your
assembly instructions to keep the 320 pipeline flowing. The compilers at the
time knew some of the tricks but it was still usually possible to hand-
optimize the compiler output quite a bit.

------
rbanffy
Programming a DSP, like driving an F1 car or flying a F-22, is supposed to be
a very hard thing to do. Machines optimized for performance don't relate well
to humans.

A smart compiler can remember and apply a number of optimizations far greater
than I would be able to remember. The weirder the processor, the better. A
really smart development tool could even benchmark variations to find the best
one.

My 6502 assembly code was much better than what the Aztec C compiler could
spit, but the 6502 was a sweet processor to program. DSPs (as GPUs, BTW) are
anything but sweet.

And, BTW, I wouldn't try to hand tune assembly code with a modern x86 even if
my life depended on it.

~~~
russell
Back in the days I did a lot of assembly programming for the CDC 6400/6600
computers. The instruction set was simple, but processor flow wasnt. IIRC
there were 3 or so integer units and 1 floating point unit. If a result wasnt
ready when an instruction needed it, the processing flow would stall until it
was ready. So you needed to remember the instruction timings for each of the
models, how many processing unit you were using, etc. to get maximum thruput.
This is stuff that a compiler does easily, humans less so. Part of my team was
writing hand tuned libraries and part was writing the compilers to produce
optimal code. I got to see the trade-offs.

Rick James, now at Yahoo, was the king of assembly. He wrote a character move
library that was faster than the character move hardware, $100K add-on. He
kept getting poached from my projects, because, even at CDC, there weren't
many as good as he was.

Then there is the productivity issue. The HLC programmer can produce 10x the
number of instructions more than the assembly programmer.

~~~
rbanffy
I have the utmost respect for anyone who programs a computer that has two
round monitors ;-)

~~~
bitwize
I have utmore respect for that person if his name is RICK JAMES.

~~~
rbanffy
Don't get me wrong. Rick James is, well, The Rick James.

But anyone who programmed CDC supercomputers gets some serious geek points for
that.

------
chopsueyar
When I attended GWU, we were required to take two semesters of Ada.

The professor who wrote the Ada 95 book would give us cash as we found logical
or typographical errors in the book.

Not sure if there are any other universities that push Ada so hard in intro
classes. Perhaps this has changed now.

Any recent GWU compsci people care to comment?

~~~
ahi
Maybe I'm recent enough. I enrolled and took intro courses in Fall of 2001,
graduated in 2005. My intro courses, IIRC "intro to CS" and "algos & data
structures" were Ada. 2nd year Software Engineering was Java. I think students
starting Fall of 2002 had an entirely Java curriculum. At the time I was kind
of annoyed to be learning Ada rather than Java, especially because the faculty
member who wrote the assigned Ada textbook couldn't be bothered to actually
teach the course. However, looking back on it I think Ada is a better language
for learning than Java because everything is so explicit. I still have Ada on
my resume, mostly for shits and giggles. I'd take it off if I was applying
anywhere that might ask me to prove it.

EDIT: Reconsidering. Ada pushes you toward the waterfall development process
which can be dangerous for newbs to internalize.

~~~
chopsueyar
Out of personal curiosity, what was your reasoning when deciding to attend
GWU?

Would you recommend it to others?

~~~
ahi
Location, location, location. Columbia said no thanks. CMU said "okay, but no
CS major". Case Western offered better money and athletics but it's in
Cleveland. Johns Hopkins seemed like 80% premed jackasses. I didn't consider
Georgetown because when I was looking at schools my dad didn't want to pay for
parking.

I initially wrote out a very long description of GW before I realized you had
attended. So shortened considerably:

I went to grad school at U of Michigan and have come to the conclusion that
most colleges/universities are basically the same. For such an important
decision with such wide-ranging consequences, where you go to school is
relatively hard to screw up. Undergraduate education is mostly foolish and
cult-like behavior--Go Blue!--in a pretty setting where you can find an
education and lifelong friends if you look for them. When people recommend a
school they are usually recommending the cult. I went to Freshman orientation
on my 18th birthday. I had been away from home a week and living down the
street from the State Department and the White House when the Pentagon went
boom. GW was my training ground for adulthood. The experience is so integral
to who I am, to recommend it feels a bit odd.

~~~
chopsueyar
Thurston Hall?

~~~
ahi
Lafayette at 21st and I. I don't think I would have survived Thurston.

~~~
chopsueyar
You haven't lived until you've experienced 4 people living in a 400sqft room
with one bathroom, all NAT'ing a single Ricochet wireless modem,
simultaneously downloading MP3s from UPenn student's FTP sites.

It was before Thurston had an ethernet network. All of the other dorms seemed
to have direct fiber and media converters.

1300 people in a 9 story building. Especially fun, when a block from the dorm,
somebody ran over a fire hydrant, and the water supply had to be shut off for
several blocks, including Thurston (there were no tank toilets). 8 hours of
clogged toilets on every single floor, including the public bathrooms and
study lounges.

...or the false fire alarms, where all 1300 students evacuate from only two
sets of stairwells.

...or when facilities management decides it is warm enough to enable air
conditioning.

Good memories. I have more, but this is enough for now.

------
userulluipeste
I've asked myself (like many others I think) - which is the most "efficient"
PL? From this article it can be concluded that it's not so much the language
itself like it is the compiler implementation. And programming in assembly is
just stupid, unless you work on some compiler optimization or hacking
disassembled code.

------
vlisivka
Typical success story:

We wrote program in language X and then _rewrote_ it in language Y, so Y is
better language than X, because our program is much better after _rewrite_.

------
chrisjsmith
Bollocks.

~~~
bediger
I was inclinded towards that view myself, based on the date: 1992 was when the
US DoD was still pushing Ada pretty darn hard. I personally found the story
hard to believe, but I have no experience with DSP assembly.

~~~
_mhp_
I have got experience of DSP assembly (mostly 320C25 stuff, a little 'C50),
and I initially doubted the story. DSPs like the 'C25 were pretty easy to work
with since the instructions were all the same length (ignoring memory wait
states for the moment). But with the 'C50 (and the 'C30 from the article),
delayed branching was introduced. Whilst you can optimise for that in your
head, it becomes a pain and often results in hard-to-maintain code. Adding a
couple of NOPs makes it much easier!

The article highlighted common sub-expression elimination too, which again can
be done manually. But (and this is the crux IMHO) writing optimal code
continuously at this level is mentally tiring (leading to bugs) and often
gives brittle unmaintainable code. A compiler never needs to worry about this
as it generates fresh code every time rather than maintaining the code from
the last build. But a human will learn to avoid brittle code and hence won't
be able to take advantage of the possible optimisations.

