Re: A little first-hand about the Orbiter development

[Rick DeNatale]

On Fri, 27 Jun 2003 00:27:13 +0000, rk wrote:

> For any program of significant size, I would want at a least a
> rudimentary assembler so one can jump to symbolic addresses, have
> reasonable names for constants, registers, etc. Of course, this
> wouldn't affect the size or runtime of the program. I remember even in
> the '70s and early '80s some rather slow FORTRAN compilers. I don't
> know about the speed of the assemblers back in the '60s. I know there
> were some programmers from back there in the group (added .history) and
> perhaps they can chime in with their $0.02.

There was a time, which ended in the early 1970s when I was in college, in
which computer programming textbooks tended to be machine specific and
covered machine language, Fortran II, and assembly language in that order.

In the old days, computer programs tended to be carefully "desk checked"
before they ever saw the machine, computer time was more precious than
programmer time, so manually producing machine code was de rigeur.

I beleive that the machine which gave the impetus to using assembly
language rather than machine code was the IBM 605. This machine had
instructions which had a field which held the address of the next
instruction to be executed. This is because it fetched instructions for
execution directly from a rotating drum memory. The trick was to arrange
the instructions so that the next instruction was under the read head when
it was needed. This lead to SOAP or the Share Optimizing Assembly Program.
The optimization was the allocation of the 'right' address to each
instruction.

[James Oberg]

We were doing assembly language programming for the IBM 1620 in the summer
of 1963, and it was just magnetic core memory. As they say, that was when
ships were wood and men were iron -- and so was their memory.

"Rick DeNatale" > wrote in message
...
> On Fri, 27 Jun 2003 00:27:13 +0000, rk wrote:
>
> > For any program of significant size, I would want at a least a
> > rudimentary assembler so one can jump to symbolic addresses, have
> > reasonable names for constants, registers, etc. Of course, this
> > wouldn't affect the size or runtime of the program. I remember even in
> > the '70s and early '80s some rather slow FORTRAN compilers. I don't
> > know about the speed of the assemblers back in the '60s. I know there
> > were some programmers from back there in the group (added .history) and
> > perhaps they can chime in with their $0.02.
>
> There was a time, which ended in the early 1970s when I was in college, in
> which computer programming textbooks tended to be machine specific and
> covered machine language, Fortran II, and assembly language in that order.
>
> In the old days, computer programs tended to be carefully "desk checked"
> before they ever saw the machine, computer time was more precious than
> programmer time, so manually producing machine code was de rigeur.
>
> I beleive that the machine which gave the impetus to using assembly
> language rather than machine code was the IBM 605. This machine had
> instructions which had a field which held the address of the next
> instruction to be executed. This is because it fetched instructions for
> execution directly from a rotating drum memory. The trick was to arrange
> the instructions so that the next instruction was under the read head when
> it was needed. This lead to SOAP or the Share Optimizing Assembly Program.
> The optimization was the allocation of the 'right' address to each
> instruction.

[John Gilmer]

>
> My first computer experience was Fortran-IV on an IBM-360. I can
> remember typing for hours at the terminal, submitting the thick stack of
> punch cards to the computer operator, only to find (hours later) that
> the program had bugs. Then it was back to the keyboard terminal to type
> some more. I definately don't miss those days. Little did I know that
> the first computer system with a monitor (video user interface) was
> being developed.

Oh, folks coded usng punch card input well up to the mid to late 70s. Even
when the transition to terminals began IBM (in particular) "pretended" that
the input was a punched deck of tab cards. The end of each 80 column line
was a sequence number. If you used a terminal for input, it automatically
skipped 10 numbers between lines to give you "room" to add lines without
haveing to resequence.

[Reed Snellenberger]

"John Gilmer" > wrote in
:

>
>
>>
>> My first computer experience was Fortran-IV on an IBM-360. I can
>> remember typing for hours at the terminal, submitting the thick stack
>> of punch cards to the computer operator, only to find (hours later)
>> that the program had bugs. Then it was back to the keyboard terminal
>> to type some more. I definately don't miss those days. Little did I
>> know that the first computer system with a monitor (video user
>> interface) was being developed.
>
> Oh, folks coded usng punch card input well up to the mid to late 70s.
> Even when the transition to terminals began IBM (in particular)
> "pretended" that the input was a punched deck of tab cards. The end
> of each 80 column line was a sequence number. If you used a terminal
> for input, it automatically skipped 10 numbers between lines to give
> you "room" to add lines without haveing to resequence.
>
>

Yep... we used 'em at Michigan State up through 1980 or so -- one of the
advantages of working in the Chemistry building is that they had a remote
terminal for the CDC 6500, and you didn't have to punch and feed cards with
the hoi polloi. ;-)

My thumb *still* has its 029 macro that spaces to column 7 with
authority...


--
Reed Snellenberger

[David Higgins]

Reed Snellenberger wrote:

> My thumb *still* has its 029 macro that spaces to column 7 with
> authority...

Once a Fortran programmer, always ...

[Ron]

>
> Yep... we used 'em at Michigan State up through 1980 or so -- > --
> Reed Snellenberger
>

Same at the University of Nebraska, and then we got the mighty VAX 11/780
"the most powerful computer ever", or so we thought at the time.


R

[Reed Snellenberger]

David Higgins > wrote in news:CeKQa.54686
:

>
>
> Reed Snellenberger wrote:
>
>> My thumb *still* has its 029 macro that spaces to column 7 with
>> authority...
>
> Once a Fortran programmer, always ...
>

Yep, although arithmetic IF statements get very tiring when you’re using
Java...

--
Reed Snellenberger

Many of the early Apollo Fortran orbital calculations were done on an IBM
1401.


"Ron" > wrote in message
rthlink.net...
|
| >
| > Yep... we used 'em at Michigan State up through 1980 or so -- > --
| > Reed Snellenberger
| >
|
| Same at the University of Nebraska, and then we got the mighty VAX 11/780
| "the most powerful computer ever", or so we thought at the time.
|
|
| R
|
|

[Kegwasher]

John Gilmer wrote:

>
>
>>
>> My first computer experience was Fortran-IV on an IBM-360. I can
>> remember typing for hours at the terminal, submitting the thick stack of
>> punch cards to the computer operator, only to find (hours later) that
>> the program had bugs. Then it was back to the keyboard terminal to type
>> some more. I definately don't miss those days. Little did I know that
>> the first computer system with a monitor (video user interface) was
>> being developed.
>
> Oh, folks coded usng punch card input well up to the mid to late 70s.
> Even when the transition to terminals began IBM (in particular)
> "pretended" that
> the input was a punched deck of tab cards. The end of each 80 column
> line
> was a sequence number. If you used a terminal for input, it
> automatically skipped 10 numbers between lines to give you "room" to add
> lines without haveing to resequence.

It was not in aerospace but my first job was the night shift computer
operator for a large oil company, Shell. in 84 we still used a tape drives
boot-strapped by the punch cards when we did a reboot on the IBM360. Those
chain printers commanded respect and a little fear.

[OM]

On Tue, 15 Jul 2003 22:45:16 +0200, Kegwasher >
wrote:

>It was not in aerospace but my first job was the night shift computer
>operator for a large oil company, Shell. in 84 we still used a tape drives
>boot-strapped by the punch cards when we did a reboot on the IBM360. Those
>chain printers commanded respect and a little fear.

....Try getting damn near strangled by one when your tie-on tie gets
caught in the roller during a full page feed. *That* will invoke fear.


OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

[Kent Betts]

I had the pleasure of working on the Burroughs TC500, the first intelligent data
terminal. It contained a sealed aluminum disk about the size of an LP record
with a R/W head for each track and turning about 3000 or 6000 RPM. The rotating
disk was synchronized with the processor, and provided the comm software as well
as the microcode required for the processor to complete its instructions. The
TC500 was a big seller at about 50,000 units at around $50,000 each. A big
market for the things was with banks, a traditional Burroughs market. I figure
in the early 60s that one TC500 would be enought to handle the transactions of
your hometown bank or savings and loan. The wide carriage on the thing was
sized to accomodate ledger pages in use at the time. Burroughs kept them in the
field thru the late 80s on various lease contracts, long after they were
economically viable. Then again, dumb glass terminals in the late 80s were not
cheap, but jeez. I think DEC or Burroughs had a nice dot matrix terminal
available during this time. Made me appreciate the California school of
engineering design vs Pennsylvania.

> "Rick DeNatale"
> > I beleive that the machine which gave the impetus to using assembly
> > language rather than machine code was the IBM 605. This machine had
> > instructions which had a field which held the address of the next
> > instruction to be executed. This is because it fetched instructions for
> > execution directly from a rotating drum memory. The trick was to arrange
> > the instructions so that the next instruction was under the read head when
> > it was needed. This lead to SOAP or the Share Optimizing Assembly Program.
> > The optimization was the allocation of the 'right' address to each
> > instruction.
>
>

[Kevin Willoughby]

Jay Windley said:
> "rk" > wrote in message
> ...
> | I found out that some schools are no longer teaching
> | even assembly language and machine organization any more
> | for the Computer Science majors.
>
> Along those lines, compiled languages are on the way out in academia.
> JIT-compiled Java is becoming the de facto standard for core algorithm

uh, how isn't "JIT-compiled" not compiled?

While Java isn't the pedagogically best language, it is better than its
predecessors. How much time in how many University classes has been
wasted explaining the obscurities of C pointers or C++ multiple
inheritance?


> Unfortunately it doesn't occur to a lot of these
> professors that there are still computing applications that can't
> accommodate (and shouldn't) a 20-megabyte optimizing multi-pass JVM.

The SE (Java Standard Edition) can run in less than 20 Mbyte. The
mobile edition of Java can run in environments much smaller than you
might expect. Fun factoid: in 2003, worldwide, there will be more Java
platforms delivered to paying customers than Windows platforms. (Hint:
many new cell phones in the USA and most new cell phones in Europe will
run Java, but are too resource constrained to run Windows.)

OBspace: one of the recently launched Martian rovers is Java powered.


> The running joke is that when flight control software starts being written
> in Java we'll have to add an extra 1,000 feet of runway for getting the
> JVM-laden aircraft off the ground.

If the alternative is a Windows FCS that crashes one time in a
thousand...


> I'm running into more and more mechanical engineers who CAN'T DRAW!

I'm running into a lot of young C.S. graduates who can't do a back-of-
the-envelope calculation to save their lives. It isn't pretty.

Heck, I still use one of my slide rules every now and then.


> There
> is a definite correlation between design ability in the abstract sense, and
> the capability of expressing oneself graphically with nothing more than a
> stick and a flat spot of dirt. I've seen it myself.

Myself, I like blackboard and chalk.
--
Kevin Willoughby

We'd spend the remaining time trying to fix the engine.
-- Neil Armstrong

[Mike Speegle]

In news:Kevin Willoughby > typed:
> Jay Windley said:

> > I'm running into more and more mechanical engineers who CAN'T DRAW!
>
> I'm running into a lot of young C.S. graduates who can't do a back-of-
> the-envelope calculation to save their lives. It isn't pretty.

Even with calculators kids struggle. Last week at the movies I
bought something at the counter for $3.25. Gave the kid 3 ones and
while I'm fishing in my pocket for change he enters $3.00 tendered and
the display reads $.25 still due. I give him 3 dimes and he keys in
$3.30 tendered with $3.05 in change. ??? He actually counted out 3
ones but I saved his butt and just took the nickel shaking my head.
Sheesh. So even with electonic help some of these kids are seriously
polluting the gene pool. :-(
--
Mike
__________________________________________________ ______
"Colorado Ski Country, USA" Come often, Ski hard,
Spend *lots* of money, Then leave as quickly as you can.

[Jay Windley]

"Kevin Willoughby" > wrote in message
...
| Jay Windley said:
| >
| > Along those lines, compiled languages are on the way out
| > in academia. JIT-compiled Java is becoming the de facto
| > standard for core algorithm ...
|
| uh, how isn't "JIT-compiled" not compiled?

Wow, that came out wrong, didn't it? In many ways JIT compilation is better
than static compilation, what with profiling and all. I shifted mental
gears between those two sentences. By "compiled language" I meant static
compilation (C, C++, FORTRAN, etc.) versus "interpreted" languages such as
Java. But then of course I had to consider that JITs aren't as rare as they
used to be and can produce stellar object code. Java isn't necessarily an
interpreted language.

I don't necessarily want to make the argument about speed of resulting code.
JITs can produce code that in the general case will run within 10% of the
speed of statically compiled code, and in specific cases will run
significantly faster. C-ish programmers have always had standalone
profilers and optimizers, but don't always use them.

| While Java isn't the pedagogically best language, it is
| better than its predecessors.

Considering that I started in FORTRAN IV, I tend to agree. The problem is
that pedagogical languages tend to make their way into production
environments whether they belong or not, simply because it's what
inexperienced graduates are most comfortable using. Pascal, if I'm
correctly informed, was never intended to be a "production" language; it was
intended chiefly for teaching regimented techniques. My attempts to do
anything useful in Pascal were certainly hampered by the sort of
bondage-and-discipline approach it used.

I don't have any problems with Java used in the classroom. I just don't
want it used where it's not the best solution.

| How much time in how many University classes has been
| wasted explaining the obscurities of C pointers or C++
| multiple inheritance?

Ugh, none of my software engineers uses C++ multiple inheritance, by choice.
However, the "obscurities" of C pointers are still important concepts, not
just to get around convoluted syntax that is more error-prone than helpful,
but because many applications today still benefit from programmer-controlled
memory management over garbage collection. (Besides, someone has to write
those garbage collectors :-).

It's not always that the language prevents you from being efficient by
denying you tools and techniques that older languages supplied. It's
frequently simply that the abstractions keep you from knowing the
repercussions of what you're doing, such as copying objects rather than
passing addresses.

| The SE (Java Standard Edition) can run in less than 20 Mbyte.

But it doesn't on the platforms my guys are currently working on. The 20 MB
figure is the result of my Java team's benchmark on a certain platform we're
working on. That's after their best efforts to make it small.

When you start stripping down the JVM in order to make it fit, you have to
get rid of the features that make Java viable in a production environment.
My point is not that Java is worthless everywhere. It's that Java isn't
automatically best everywhere. To make the decision whether or not Java is
good in your application, you have to know what makes Java tick, and how
computers work in general. Kids who don't know how to work outside a
garbage-collected universe are useless for what I do.

| (Hint: many new cell phones in the USA and most new cell phones
| in Europe will run Java, but are too resource constrained to
| run Windows.)

Well, let's not make this a Windows argument. I believe your statement, but
this isn't about whether to run Windows or not. Windows has its own
problems that make it unsuitable for a lot of applications.

Right now Java costs me time. My Java programmers have to wait until a JVM
becomes operational on platforms I build. That has to wait until the C/C++
environment is ready, at which point my C/C++ guys are off and running. Our
business depends on getting bleeding-edge architecture in customers' hands
as shortly as possible after it goes on the market. Right now my C
"dinosaurs" are beating the pants off of my Java team in terms of speed
(both code development and runtime efficiency), space, and correctness.

Java isn't intended for all applications, and my applications are generally
those in which Java doesn't work better than other solutions.

ObSpace: I am, however, interested in Java being used on the new Mars
probes. Is it written up anywhere in more detail?

| > The running joke is that when flight control software starts
| > being written in Java we'll have to add an extra 1,000 feet of
| > runway for getting the JVM-laden aircraft off the ground.
|
| If the alternative is a Windows FCS that crashes one time in a
| thousand...

It isn't. This isn't about Windows. This is about choosing the right tool
for the right job irrespective of "religious" adherence to certain ways of
doing things. It is possible to program highly reliable, highly efficient
systems, but not according to the knowledge that results from overly
abstracting the problem, which is what I'm getting from new grads. If
today's computer science graduates are being increasingly insulated from the
intricacies of how the machinery actually works, then it will be harder for
them to understand all the constraints that may apply.

| I'm running into a lot of young C.S. graduates who can't do a
| back-of- the-envelope calculation to save their lives. It isn't
| pretty.

No it isn't. I think that's just following the general trend of society. I
know accountants who can't make change.

| Heck, I still use one of my slide rules every now and then.

I still have mine somewhere. One place where I worked it was a running
joke. I'm not that old, but I still had the reputation as an old-timer
because everyone else was fresh out of college. We had a new building with
a central UPS, and one day the building power failed INCLUDING the allegedly
protected circuits. Everyone's computer ground to a halt. Amid the groans
I said, "Tee hee, I can still work."

| Myself, I like blackboard and chalk.

Just TRY to find an honest-to-goodness chalkboard anymore. I hate
whiteboards; not enough resistance to the stroke.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[jeff findley]

Kevin Willoughby > writes:
> While Java isn't the pedagogically best language, it is better than its
> predecessors. How much time in how many University classes has been
> wasted explaining the obscurities of C pointers or C++ multiple
> inheritance?

That's because such understanding is necessary, depending on where you
get your job after college...

Java has its place, but it isn't at the heart of engineering
software. I ought to know, considering I work on CAE (finite element)
software. We've still got lots of Fortran, C, and some C++ in
performance critical code. Java doesn't cut it in the guts of code
that has to deal with one million plus finite elements (and their
nodes and etc).

To be fair, my current project is in Java, but it's largely user
interface that has no direct contact with any of the "guts" of the
code. This is where Java works well, at least where I work. Rapid
development of a user interface level code is well suited to a high
level language (or a GUI builder).

Jeff
--
Remove "no" and "spam" from email address to reply.
If it says "This is not spam!", it's surely a lie.

[Jay Windley]

"jeff findley" > wrote in message
...
|
| That's because such understanding is necessary, depending on where you
| get your job after college...

That's exactly my point. Why would I hire a BSCS if some guy who has read
"Java For Dummies" can do just as good a job and charge me less?

I remember once calling some programmer into my office to have him explain
why his project was ridiculously behind. He said he was working around a
bug in the JVM and it wasn't easy to do. "Why don't you just fix the JVM?"
I asked. (We had the source code to it.) He looked at me like I was crazy.
I was entirely serious. The guy was a CS grad, not just some wannabe. It
took only a day or so to fix the JVM. I just had a hard time dealing with
his attitude that "all that JVM stuff" was under the hood and he thought he
had no business violating the abstraction.

One of my most talented embedded-systems programmers in a former job was the
guy who had written IBM's JVM. This guy *knew* Java, but didn't try to
evangelize it. He used Java where it was appropriate, and C/C++ where
appropriate.

(ObSpace: This guy also worked on the AP-101 project, IBM's computer used
on the space shuttle.)

I understand there is a tremendous market right now for Java programmers. A
lot of stuff in the commerce end of things is being written in Java, and I
don't see anything wrong with that. The Java of today is not the Java of
six or seven years ago, and I don't think a lot of computer people realize
this. I see a lot of invalid criticism of Java based on arguments that have
been resolved.

| I ought to know, considering I work on CAE (finite element)
| software.

Heh heh, you're precisely the type of person my company sells computers to.
Boeing, Ford, and other big engineering types use our computers for funky
computational structural and fluid dynamics, heat transfer, and other
problems without closed forms that require fine-grained discretization. I
saw a presentation in Baltimore last year where someone had used one of our
competitor's computers to do a CSD analysis of an entire aircraft carrier at
an obscene level of detail.

ObSpace: In the same session there was a presentation of n-body gravitation
simulations for the Kuiper Belt, where n was in the thousands or tens of
thousands. (For some reason they didn't include Neptune, though.)

| Java doesn't cut it in the guts of code that has to deal with
| one million plus finite elements (and their nodes and etc).

Agreed, but even that gap is narrowing.

The exciting principle behind modern JITs is runtime profiling. They run
your byte code for a few iterations and gather runtime metrics, and then
they compile and aggressively optimize the portions that are responsible for
most of the running time.

The classic bad example is

for (i=0; i<SOME_HUGE_NUMBER; i++)
{
foo = 0;
}

A good JIT will optimize this loop away entirely regardless of what the
programmer specifies, while the GNU C/C++ compilers will generally leave it
there even if they move the invariant outside. So the Java version runs
instantly while the C version often spins through the loop even though it's
not doing anything useful in the body.

The key is recognizing the invariant. The best JITs have very good
optimizers and can optimize not only on the static structure of a program
but also on the runtime behavior. Many C compilers have good optimizers
too, but runtime optimization is limited to a separate step. The GNU
compilers are frequently used for benchmarks, but most people who need good
performance use commercial compilers that have optimizers tuned for the
specific architectures for which they generate code.

It's a bad example above because it simply tests one feature of
optimization, and so nobody really accepts it as a valid benchmark. But
this particular example illustrates the point. The key is recognizing the
invariant. An experienced programmer with a good theoretical understanding
will see that the code example above is bad. He knows why it's bad, and he
rewrites the code to eliminate the problem, which is a far better solution
because it will run efficiently even in the face of a poor optimizer (or
even the lack of one). A programmer whose butt is saved time after time at
runtime by a clever JIT may not be effective outside that sheltered
environment.

And that was my understanding of what this thread is about (or rather, what
it has become). It's less about Java versus C or FORTRAN and more about
correct understanding of underlying principles and basic concepts. Today's
grads are being insulated from concepts that are still important.

Memory management in Java is still a major hassle, and when I'm supplying
computers with 4 terabytes of RAM (yes, terabytes) because that's the size
of the datasets my customers need to have in memory, you don't want any of
that garbage collection stuff in the way. You've got to let the programmer
do his own memory management according to his own expertise and judgment.
Garbage collectors work very slowly and inefficiently on allocations of this
size. Some of these jobs run for days or weeks at a time, so a memory
management overhead adds up fast.

It may not matter in the long run if a program makes a copy of a ten-byte
chunk of data more times than it strictly needs to. But if a program is
trying to copy a 4,000,000 element matrix just because a certain abstraction
demands it, that may render the program entirely unrunnable. You go to
extreme lengths to *avoid* copying that matrix at all. Ever.

| To be fair, my current project is in Java, but it's largely user
| interface that has no direct contact with any of the "guts" of the
| code. This is where Java works well, at least where I work.

I thoroughly agree. User interaction is an application for which Java is
particularly suited and often gives you very big wins with portability.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[Bruce Palmer]

Mike Speegle wrote:
> Even with calculators kids struggle. Last week at the movies I
> bought something at the counter for $3.25. Gave the kid 3 ones and
> while I'm fishing in my pocket for change he enters $3.00 tendered and
> the display reads $.25 still due. I give him 3 dimes and he keys in
> $3.30 tendered with $3.05 in change. ??? He actually counted out 3
> ones but I saved his butt and just took the nickel shaking my head.
> Sheesh. So even with electonic help some of these kids are seriously
> polluting the gene pool. :-(

And to think baseball pitcher Mike Hampton left New York for the Rockies
because he liked the Colorado school system better :)

But seriously, here on Long Island if the cash registers didn't figure
out the change, 99% of the kids you run into couldn't do it themselves.

--
bp
Proud Member of the Human O-Ring Society Since 2003

[Sam Seiber]

Bruce Palmer wrote:
>
> And to think baseball pitcher Mike Hampton left New York for the Rockies
> because he liked the Colorado school system better :)

And I thought it was the $100 some odd million over 10 years that
was the reason. Silly me.

Sam

[Jay Windley]

Oh, goody, I get to eat my words. I was a little uncomfortable with my
grasp of the optimizing question so I asked a few of our compiler gurus. A
static and a dynamic optimizer should be equally adept at removing loop
invariants. There is nothing especially knowable at runtime that clarifies
the invariance of ambiguous code. The issue of runtime optimization is
strictly one of profiling -- looking at how code behaves when it runs and
optimizing it accordingly based on this information. This is not generally
available to static optimizers, but natively-compiled languages such as
C/C++ can use standalone optimizers to identify problematic code stretches.

The simplistic example I posted was, of course, an unambiguously invariant
loop body. Both Java and C will, if set up to optimize to the same degree,
remove that code and eliminate the loop entirely. It was based on a
comparison I read a while back which used a somewhat less straightforward
loop which the HotSpot JVM had optimized (correctly) into oblivion while the
C compiler (gcc) had not. As I said, it doesn't appear that this happens
very often and the benchmarking people don't seem interested in it.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[Mike Speegle]

In news:Sam Seiber > typed:
> Bruce Palmer wrote:
> >
> > And to think baseball pitcher Mike Hampton left New York for the
> > Rockies because he liked the Colorado school system better :)
>
> And I thought it was the $100 some odd million over 10 years that
> was the reason. Silly me.

...and then his ego got the best of him when he couldn't figure out
that pitching is different at a mile high of thin air. What a maroon,
and good riddance.
--
Mike
__________________________________________________ ______
"Colorado Ski Country, USA" Come often, Ski hard,
Spend *lots* of money, Then leave as quickly as you can.

[Kevin Willoughby]

Jay Windley said:
> The issue of runtime optimization is
> strictly one of profiling -- looking at how code behaves when it runs and
> optimizing it accordingly based on this information.

Not really. A dynamic optimizer has an advantage over a static
optimizer. Static optimizers are often thwarted by not knowing all the
code that is running. Things like the possibility of aliasing (non-
obvious ways of having multiple ways of referring to the same variable)
force static optimizers to be conservative. There is at least one JVM
(currently, iirc, owned by BEA) that can over-optimize the code because
it knows what other code is also loaded into the JVM. Should the
program load some new code, the JVM can deoptimize the code as needed
to prevent problems.

A large dose of engineering good taste is needed to be sure you don't
loose more than you gain in dynamic optimization.


> This is not generally
> available to static optimizers, but natively-compiled languages such as
> C/C++ can use standalone optimizers to identify problematic code stretches.

This really isn't a language thing. Traditionally, C/C++ has been
statically optimized, but there is nothing that would prohibit a
HotSpot-like system that detected performance-sensitive code and
optimized it. With most C/C++ systems, this would be a machine-code to
machine-code optimizer, with the advantage of being usable with any
language that compiles to machine code.


> The simplistic example I posted was, of course, an unambiguously invariant
> loop body. Both Java and C will, if set up to optimize to the same degree,
> remove that code and eliminate the loop entirely. It was based on a
> comparison I read a while back which used a somewhat less straightforward
> loop which the HotSpot JVM had optimized (correctly) into oblivion while the
> C compiler (gcc) had not. As I said, it doesn't appear that this happens
> very often and the benchmarking people don't seem interested in it.

Actually, the benchmarking people were interested in it because the
compiler writers optimized their products for best benchmark numbers,
resulting, as you say, in optimizing away entire loops. (Tuning to the
benchmark was not just a software thing. I know of a machine that
included an arc-hyperbolic-cosecant instruction, but didn't include an
arc-hyperbolic-secant function. Guess which trig functions appeared in
the popular benchmarks.) The benchmark owners eventually mandated that
the benchmarks be run with all optimizers turned off.
--
Kevin Willoughby

We'd spend the remaining time trying to fix the engine.
-- Neil Armstrong

[Kevin Willoughby]

I could go on and on over this topic. Given the forum, let me just say
we essentially agree on all of this stuff.

Jay Windley said:
> Right now Java costs me time. My Java programmers have to wait until a JVM
> becomes operational on platforms I build. That has to wait until the C/C++
> environment is ready, at which point my C/C++ guys are off and running.

I'm not surprised. One of the dirty secrets of Java is that most of the
JVMs are coded in C. Can't start a new JVM until the C compiler is
working well. So the JVM guys can't start working until the time when
your C/C++ guys can also start working.


> ObSpace: I am, however, interested in Java being used on the new Mars
> probes. Is it written up anywhere in more detail?

Not as much detail as I suspect you'd like. If you are a member of the
Java Developers Community (or willing to register for the JDC), go to
http://servlet.java.sun.com/javaone/sf2003/home/index.jsp
and enter MARS into the search box.


> | Myself, I like blackboard and chalk.
>
> Just TRY to find an honest-to-goodness chalkboard anymore. I hate
> whiteboards; not enough resistance to the stroke.

Also, getting chalk dust off my pants is trivial, getting those damn
marker inks off my pants is tough.
--
Kevin Willoughby

We'd spend the remaining time trying to fix the engine.
-- Neil Armstrong

[Jay Windley]

(Replies consolidated to reduce off-topicness)

"Kevin Willoughby" > wrote in message
...
|
| A large dose of engineering good taste is needed to be sure
| you don't loose more than you gain in dynamic optimization.

Yes, thank you. I was going to allude to this eventually. Static or
dynamic, an optimizer will always have the disadvantage of not knowing the
problem you're trying to solve. It can do lint-picking things like strength
reduction or factoring out invariants, or consolidating similar code as you
brought up. But the greatest increases in efficiency that I've seen -- and
I mean they're *big* wins -- have always been from skilled programmers
figuring out better ways to do things at the bird's-eye level with knowledge
of what each modular chunk of code is supposed to accomplish.

Funny how it always comes back to having skilled people whose understanding
is focused on the problem rather than on the tool. I run into this all the
time. People think in terms of what's available to them and what they can
do with it, not in terms of what you need to solve the problem.

| ... With most C/C++ systems, this would be a machine-code
| to machine-code optimizer, with the advantage of being usable
| with any language that compiles to machine code.

Most compilers you buy will optimize both at the abstract code level and at
the machine code level. These are the compilers sold by the CPU
manufacturers. In the cases I've tested they produce much better code than
freebies like GNU's compiler. Remember, my customers write code that has to
run for several days on terascale systems. A 10% speedup is not
insignificant.

| Actually, the benchmarking people were interested in it because
| the compiler writers optimized their products for best benchmark
| numbers, resulting, as you say, in optimizing away entire loops.

Well, I don't put a lot of stock in benchmarks, especially those done by
manufacturers of either hardware or compilers/runtimes. I always find it
interesting in the Java versus C debate that the C people's benchmarks come
out faster for C while the Java people's benchmarks come out faster for
Java. Again, the spectre of the skilled programmer raises its head.

The only benchmark I pay attention to is LINPACK because it's a standard in
the supercomputing industry. And pretty much anything goes. I've got a guy
whose only job is to hand-optimize math libraries for these beasts. He can
sometimes squeeze 20% speedups out of that code, which pushes our benchmarks
along nicely. And we use compilers provided by the CPU manufacturers with
all the recommended optimizations enabled.

But what I meant was that the loop in question wasn't interesting because it
was, in fact, so trivial. The failure of one compiler to optimize it to the
bit bucket isn't that big a deal in the grand scheme of things. I certainly
don't mean to say that factorization of loop invariants is not interesting,
nor that elimination of dead loops is not interesting.

"Kevin Willoughby" > wrote in message
...
| I could go on and on over this topic. Given the forum, let me
| just say we essentially agree on all of this stuff.

Yeah, I think we're wearing out our welcome. I don't mind Java being
pitched for things that it's never been used for before. I do mind Java
being pitched for everything.

| I'm not surprised. One of the dirty secrets of Java is that
| most of the JVMs are coded in C.

I never considered it that much of a secret. I worked with Sun's original
JVM that was *very poorly* coded in C. I *really* hated that code and so
did everyone else that touched it. I think that was one of the big reasons
Java didn't have immediate appeal.

| Not as much detail as I suspect you'd like. If you are a member of the
| Java Developers Community (or willing to register for the JDC), go to
| http://servlet.java.sun.com/javaone/sf2003/home/index.jsp
| and enter MARS into the search box.

LOL, I'll get one of our Java guys to do it. Thanks. I've worked alongside
several projects to embed Java, none of which came to fruition. I'd like to
see a success story.

| Also, getting chalk dust off my pants is trivial, getting those damn
| marker inks off my pants is tough.

Here's a tip (pun intended). Make this a tight "basic block" in your
whiteboard presentations:

1. Remove cap
2. Draw on whiteboard
3. Replace cap

Not only will it keep your clothes cleaner, the pens will last longer.
Nothing irritates me more than an enfeebled whiteboard marker, except for
people who stand there for five minutes talking while the cap is off the
pen. They *dry out*, people!

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[LooseChanj]

On or about Thu, 17 Jul 2003 22:44:39 -0400, Kevin Willoughby
> made the sensational claim that:
> On of my pet peeves: people who mash the marker's point into the
> whiteboard so that is has the consistency of overcooked spaghetti. Ya
> just can't do a drawing with a blunt, mushy marker.

*sniff sniff* Wazzat you say?
--
This is a siggy | To E-mail, do note | This space is for rent
It's properly formatted | who you mean to reply-to | Inquire within if you
No person, none, care | and it will reach me | Would like your ad here

[Jay Windley]

"rk" > wrote in message
...
|
| What did he do on the AP-101?

Writing assemblers and compilers for it. I don't know if he did any direct
support work for the shuttle. He was working for IBM at the time, but I
don't know who else might have been using the -101 while he was there.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[Jay Windley]

"Kevin Willoughby" > wrote in message
...
|
| Yah, but the hand that holds the cap will get brightly colored
| splotches.

Better the hand than the pants. Or the white shirt.

| On of my pet peeves: people who mash the marker's point into the
| whiteboard so that is has the consistency of overcooked spaghetti.

Agreed. But around here they tend to dry out before succumbing to
tenderization. The other nice thing about chalk is that you can use the
same rotation technique as for pencil to assure consistent line weight.

I like CAD. I'm commited to CAD. I've evangelized CAD. I've built CAD.
But I still like the feel of pencil on vellum.

--
|
The universe is not required to conform | Jay Windley
to the expectations of the ignorant. | webmaster @ clavius.org

[jeff findley]

"Jay Windley" > writes:
> And that was my understanding of what this thread is about (or rather, what
> it has become). It's less about Java versus C or FORTRAN and more about
> correct understanding of underlying principles and basic concepts. Today's
> grads are being insulated from concepts that are still important.

Agreed. I'm sure we all have a story we can tell about paying for
something we bought with cash, something unexpected happens, and all
of a sudden the cashier simply can't make change for you because of "a
problem with the register". The real problem is that the person
running the cash register has no clue how to make change on their own.
We're turning out grads (at all levels) that are entirely dependent on
computers to do this sort of work for them.

Jeff
--
Remove "no" and "spam" from email address to reply.
If it says "This is not spam!", it's surely a lie.

[Mary Shafer]

On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
> wrote:

> I like CAD. I'm commited to CAD. I've evangelized CAD. I've built CAD.
> But I still like the feel of pencil on vellum.

Or the look of India ink in a ruling pen going onto creamy drafting
paper.

Mary

--
Mary Shafer Retired aerospace research engineer

"A MiG at your six is better than no MiG at all."
Anonymous US fighter pilot

[Herb Schaltegger]

In article >,
Mary Shafer > wrote:

> On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
> > wrote:
>
> > I like CAD. I'm commited to CAD. I've evangelized CAD. I've built CAD.
> > But I still like the feel of pencil on vellum.
>
> Or the look of India ink in a ruling pen going onto creamy drafting
> paper.
>
> Mary

When I was a freshman engineering undergrad (1986 - 1987) we were
required to take two quarters of Engineering Graphics, which at that
time still meant basic drafting. The classes were a bit of a rarity in
that they were four hour classes and actually met four mornings a week.
Day after day we'd all sit around drafting tables and learn to letter
properly; how to properly dimension drawings; how to derive perspectives
and elevations, etc.

By the time I'd graduated and gone to work on Space Station Freedom,
Boeing had almost entirely eliminated manual drafting. Due to an MSFC
requirement (to help a local business, of course!) we were using
Intergraph Unix-based workstations running their I/EMS software (on
machines with a then-generous 16 megabytes of RAM - about a year later
Intergraph was in the midst of upgrading the machines to an astounding
48 megs each! One of the most interesting things about the Intergraph
system was that even then they were capable of being clustered to
perform detailed 3D renderings using spare machine cycles - very common
in redering farms now but amazing new technology to us junior engineers.
Some of the models were detailed enough that one master machine and the
spare cycles of two or three dozen others took two weeks or more to
render. This was Boeing's first "paper-free" design - everything from
the pressure vessel to the fluid lines were modeled in 3D and the
drawings generated from the models.

Interestingly, a couple years after the start of the SSF contract when
the company started the Triple-7 program, they chose CATIA instead of
I/EMS . . . ;-)

--
Herb Schaltegger, Esq.
Chief Counsel, Human O-Ring Society
"I was promised flying cars! Where are the flying cars?!"
~ Avery Brooks

[Bruce Hedley]

Bruce Palmer > wrote in message >...
> Mike Speegle wrote:
> > Even with calculators kids struggle. Last week at the movies I
> > bought something at the counter for $3.25. Gave the kid 3 ones and
> > while I'm fishing in my pocket for change he enters $3.00 tendered and
> > the display reads $.25 still due. I give him 3 dimes and he keys in
> > $3.30 tendered with $3.05 in change. ??? He actually counted out 3
> > ones but I saved his butt and just took the nickel shaking my head.
> > Sheesh. So even with electonic help some of these kids are seriously
> > polluting the gene pool. :-(
>
> And to think baseball pitcher Mike Hampton left New York for the Rockies
> because he liked the Colorado school system better :)
>
> But seriously, here on Long Island if the cash registers didn't figure
> out the change, 99% of the kids you run into couldn't do it themselves.

I can recall, not terribly long ago although it seems like it, a
summer student we had (4th yr Mech Eng, OK, I _was_ having an affair
with her but I wasn't her supervisor) who came to me with a problem
and I hand-estimated a square root (casting out 9's method, usually
gives you a decent value) and I had to explain to her what it was:
the implication being that without calculators (didn't have mine at
work that day) she was lost. So, then, what ARE they teaching
engineers, or high school students for that matter, in maths class
these days ?

BTW, it all ended amicably and I attended her wedding in France a few
years later.

Cheers all,

[Bruce Hedley]

jeff findley > wrote in message >...
> Kevin Willoughby > writes:
> > While Java isn't the pedagogically best language, it is better than its
> > predecessors. How much time in how many University classes has been
> > wasted explaining the obscurities of C pointers or C++ multiple
> > inheritance?
>
> That's because such understanding is necessary, depending on where you
> get your job after college...
>
> Java has its place, but it isn't at the heart of engineering
> software. I ought to know, considering I work on CAE (finite element)
> software. We've still got lots of Fortran, C, and some C++ in
> performance critical code. Java doesn't cut it in the guts of code
> that has to deal with one million plus finite elements (and their
> nodes and etc).
>
> To be fair, my current project is in Java, but it's largely user
> interface that has no direct contact with any of the "guts" of the
> code. This is where Java works well, at least where I work. Rapid
> development of a user interface level code is well suited to a high
> level language (or a GUI builder).
>
> Jeff

Absolutely agree.

I'm part of a development group holding a large-ish (350K lines)
Fortran
code for doing CFD modelling on CANDU reactors, and, quite frankly,
were we
to have written it in Java, we wouldn't be able to do our job in
anything like
a reasonable time frame. Tests on solving large equations of the form
Ax = b
where the rank of A is ~10,000 show that F77 is still way more
efficient
computationally than Java -- can't say about JVM since we haven't done
that one (yet). That's for real*8 values, BTW.

We're intending to recode (and rethink the code) in F95 or F2000 if a
vendor comes out with a product in the next 18 months or so, which
should widen the gap with Java, most likely.

Visit us at: www.cathena.aecl.ca

Cheers all,

[Michael Kent]

In sci.space.shuttle Mary Shafer > wrote:

> On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
> > wrote:

>> I like CAD. I'm commited to CAD. I've evangelized CAD. I've built CAD.
>> But I still like the feel of pencil on vellum.

> Or the look of India ink in a ruling pen going onto creamy drafting
> paper.

You guys are sick, sick I tell ya. :)

Mike

-----
Michael Kent Apple II Forever!!
St. Peters, MO

[David Higgins]

Jay Windley wrote:
> The first CAD I tried was on
> Techtronix storage tube -- those things where you draw on a big tablet with
> a pen and it shows up as a fuzzy green line on a big picture tube. The only
> way you can erase anything is to erase everything and draw it all over
> again.

You forgot to mention the blinding flash when the storage
tube was erased. Made worse by the dimness of the lines,
which caused everyone to darken the room.

[Michael Kent]

In sci.space.shuttle rk > wrote:

> Michael Kent wrote:

>> In sci.space.shuttle Mary Shafer > wrote:

>>> On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
>>> > wrote:

>>>> I like CAD. I'm commited to CAD. I've evangelized CAD. I've
>>>> built CAD. But I still like the feel of pencil on vellum.

>>> Or the look of India ink in a ruling pen going onto creamy
>>> drafting paper.

>> You guys are sick, sick I tell ya. :)

> I trust you still have your 1/4 size Berols template of logic symbols
> handy.

Not me. It's 3-D parametric solid modeling or bust.

Mike

-----
Michael Kent Apple II Forever!!
St. Peters, MO

[Peter Stickney]

In article >,
(Michael Kent) writes:
> In sci.space.shuttle rk > wrote:
>
>> Michael Kent wrote:
>
>>> In sci.space.shuttle Mary Shafer > wrote:
>
>>>> On Fri, 18 Jul 2003 10:46:55 -0600, "Jay Windley"
>>>> > wrote:
>
>>>>> I like CAD. I'm commited to CAD. I've evangelized CAD. I've
>>>>> built CAD. But I still like the feel of pencil on vellum.
>
>>>> Or the look of India ink in a ruling pen going onto creamy
>>>> drafting paper.
>
>>> You guys are sick, sick I tell ya. :)

More than you'll ever know. Back in the late Pleistocene, (Mid
1970s), we not only had to lear Engineering Graphics (If it was good
enough for Imhotep, it was good enough for us!) We also had to learn
how to use the tools in the Machine Shop.

(When my father was teaching Civil Eng in the late '50s, teh CEng
students were required to learn to, if not drive, at least maneuver a
bulldozer.)

>> I trust you still have your 1/4 size Berols template of logic symbols
>> handy.
>
> Not me. It's 3-D parametric solid modeling or bust.

Ah, hell. We used to do that all teh time as undergrads in the '70s.
All you need is a block of balsa and an X-Acto knife.

Or, if it's going into the high speed tunnel, a billet of steel & a
Bridgeport.

There's solid, and then there's Solid.

--
Pete Stickney
A strong conviction that something must be done is the parent of many
bad measures. -- Daniel Webster

[Scott Hedrick]

I once worked for 7-11. After an inspection, I had a chance to look at the
inspection sheet. Every area was graded in several criteria, each of which
were graded 1-5. Some things had as few as three criteria, while others had
a dozen. I understand why it might be necessary to do long division if you
have several 2s, 3s and 5s to average, but I have yet to understand why it
took long division to two decimal places to figure out the average of 3 4s
was, in fact, 4.

My father considered building his own convenience store. A woman asked me to
consider her for a job. I asked her to tell me how much change was due on
three 45 cent cans of tuna paid for with a 5 (no tax on food here), and to
do it in her head. She gave me a nasty look and said that not everyone was a
genius. I asked her how she expected to handle money when the register
wasn't working.

--
If you have had problems with Illinois Student Assistance Commission (ISAC),
please contact shredder at bellsouth dot net. There may be a class-action
lawsuit
in the works.