Don't modern programmers realise that it's always easier to debug 3
lines of code than 30? (OK, I admit that some lines of C++ code are
undebuggable).

I like Fortran 77.

Recently I specified some maths for a Java programmer, a good one. The
program was running too slow so he optimised for speed. After
optimisation it took more than 2 cpu days to get no more than 1/10 of
the way through. I rewrote it in Fortran and it took 1 1/2 minutes.
That's a speed-up of 15,000.

'We used to call it a rigged demo. Now it's called Java'.

Last week a MapBasic programmer (who also programs Delphi) complained
that it took 20 cpu hours to compute 27,000 points. I rewrote it in
Fortran and it took 2 minutes for 7.7 million points. That's a
speed-up of at least 170,000 (more if speed depends on the square of
the points).

Have modern programmers completely lost the plot?

The MapBasic/Delphi programmer was also startled to see that I opened,
read and closed a csv file (format i,j,h) for two dimensional array h
and discarded the i and j in only 3 lines of Fortran code.

Don't modern programmers realise that it's always easier to debug 3
lines of code than 30? (OK, I admit that some lines of C++ code are
undebuggable).

PS. A correctly used 'goto' is far less dangerous than a misused
'while' statement.

'A computer language without a goto statement runs like a dog with
three legs.'

David.Paterson@csiro.au (David Paterson) writes:

I like Fortran 77.

Recently I specified some maths for a Java programmer, a good one. The
program was running too slow so he optimised for speed. After
optimisation it took more than 2 cpu days to get no more than 1/10 of
the way through. I rewrote it in Fortran and it took 1 1/2 minutes.
That's a speed-up of 15,000.

Last week a MapBasic programmer (who also programs Delphi) complained
that it took 20 cpu hours to compute 27,000 points. I rewrote it in
Fortran and it took 2 minutes for 7.7 million points. That's a
speed-up of at least 170,000 (more if speed depends on the square of
the points).

I suspect that has more to do with the algorithms than with the
language. Yes, Java is slower than Fortran, but not 15,000 times
slower (unless you are running on a vector processor or other parallel
machine that the Fortran compiler optimises for). I don't know
MapBasic, so I can't comments on its speed, but even so, I doubt it is
170,000 times slower than Fortran.

Torben

I think that MapBasic programmer was trying to search through a full
matrix of 27,000 * 27,000 points rather than a banded matrix of 27,000
* 85 points. Aren't modern programmers taught algorithms?

I think that MapBasic programmer was trying to search through a full
matrix of 27,000 * 27,000 points rather than a banded matrix of 27,000
* 85 points. Aren't modern programmers taught algorithms?

I like Fortran 77.

Recently I specified some maths for a Java programmer, a good one. The
program was running too slow so he optimised for speed. After
optimisation it took more than 2 cpu days to get no more than 1/10 of
the way through. I rewrote it in Fortran and it took 1 1/2 minutes.
That's a speed-up of 15,000.

Have modern programmers completely lost the plot?

David Paterson wrote:

I think that MapBasic programmer was trying to search through a full
matrix of 27,000 * 27,000 points rather than a banded matrix of 27,000
* 85 points. Aren't modern programmers taught algorithms?

Of course they are. Ever heard of "recursive bubblesort"?

http://thedailywtf.com/archive/2004/10/13/2557.aspx

"David Paterson" <David.Paterson@csiro.au> wrote in message
news:93e7f970.0411021442.72b27a43@posting.google.com...
I like Fortran 77.

Recently I specified some maths for a Java programmer, a good one. The
program was running too slow so he optimised for speed. After
optimisation it took more than 2 cpu days to get no more than 1/10 of
the way through. I rewrote it in Fortran and it took 1 1/2 minutes.
That's a speed-up of 15,000.

Care to post the spec or the Fortran code?

Have modern programmers completely lost the plot?

I don't know but as an eye opener see a book called Inner Loops -
http://ourworld.compuserve.com/homepages/rbooth/ - which, with a variety of
techniques, manages to get some astonishing performance figures. For
example, hash every word in War & Peace in less than a second, compress the
same book using Huffman compression in less than a second, sort 1 million
random 32-bit values in just over two seconds - at the time IIRC on a lowly
100MHz Pentium. It shows that the machines with which we work are capable
of far greater performance than their lowly performance under modern
operating systems and apps would suggest. The challenge for me (and
relevant to this NG) is to produce a language that can come close to being
as efficient - which is why it would be useful to see the Fortan code you
mentioned. Figures like these make programming 'fun' again and make
computers much more usable.

"David Paterson" <David.Paterson@csiro.au> wrote in message
news:93e7f970.0411021442.72b27a43@posting.google.com...
I like Fortran 77.

Recently I specified some maths for a Java programmer, a good one. The
program was running too slow so he optimised for speed. After
optimisation it took more than 2 cpu days to get no more than 1/10 of
the way through. I rewrote it in Fortran and it took 1 1/2 minutes.
That's a speed-up of 15,000.

Care to post the spec or the Fortran code?

Have modern programmers completely lost the plot?

I don't know but as an eye opener see a book called Inner Loops -
http://ourworld.compuserve.com/homepages/rbooth/ - which, with a variety of
techniques, manages to get some astonishing performance figures. For
example, hash every word in War & Peace in less than a second, compress the
same book using Huffman compression in less than a second, sort 1 million
random 32-bit values in just over two seconds - at the time IIRC on a lowly
100MHz Pentium. It shows that the machines with which we work are capable
of far greater performance than their lowly performance under modern
operating systems and apps would suggest. The challenge for me (and
relevant to this NG) is to produce a language that can come close to being
as efficient - which is why it would be useful to see the Fortan code you
mentioned. Figures like these make programming 'fun' again and make
computers much more usable.

"James Harris" <no.email.please> wrote in message news:<418ab1aa$0$27534$db0fefd9@news.zen.co.uk>...
"David Paterson" <David.Paterson@csiro.au> wrote in message
news:93e7f970.0411021442.72b27a43@posting.google.com...
I like Fortran 77.

Recently I specified some maths for a Java programmer, a good one. The
program was running too slow so he optimised for speed. After
optimisation it took more than 2 cpu days to get no more than 1/10 of
the way through. I rewrote it in Fortran and it took 1 1/2 minutes.
That's a speed-up of 15,000.

Care to post the spec or the Fortran code?

Have modern programmers completely lost the plot?

I don't know but as an eye opener see a book called Inner Loops -
http://ourworld.compuserve.com/homepages/rbooth/ - which, with a variety of
techniques, manages to get some astonishing performance figures. For
example, hash every word in War & Peace in less than a second, compress the
same book using Huffman compression in less than a second, sort 1 million
random 32-bit values in just over two seconds - at the time IIRC on a lowly
100MHz Pentium. It shows that the machines with which we work are capable
of far greater performance than their lowly performance under modern
operating systems and apps would suggest. The challenge for me (and
relevant to this NG) is to produce a language that can come close to being
as efficient - which is why it would be useful to see the Fortan code you
mentioned. Figures like these make programming 'fun' again and make
computers much more usable.

Speed is more in the algorithm than in the language and/or compiler.
It's also in the bottlenecks - modern software often spends time
waiting on networked files, the internet, polling some distant
peripheral etc. Office type software typically supplies some 'in the
background' features like 'spellcheck as you type' and so on, all
eating up memory and generating plenty of competing threads for the
CPU to choke on. Add a great big OS (like MacOS X, Windows XP or a
modern Linux with KDE) and the threads are everywhere!

Some of the anecdotes in this thread point to a lack of sensible
algorithm usage, and why this might be. A good illustration of
algorithm speed is fibonnaci numbers, the recursive 'simple' version
vs one that stores some values locally to speed things up. It shows
what a difference algorithm choice can make. I'm not sure any
language design can mae so big an impact.

A 100Mhz pentium is indeed a powerhouse. It chews through millions
of instructions second after all. You only have to see a game of
Quake (a reasonably tuned game) flawlessly running mid action
sequence, no video card GPU backing it up, to realize that even early
pentiums are pretty mighty!

Sounds like great fun. I'll definitely get a copy of this, although I
very seldom have a problem with Fortran algorithm speed, storage is
more my problem.

Some of the anecdotes in this thread point to a lack of sensible
algorithm usage, and why this might be. A good illustration of
algorithm speed is fibonnaci numbers, the recursive 'simple' version
vs one that stores some values locally to speed things up. It shows
what a difference algorithm choice can make. I'm not sure any
language design can mae so big an impact.

"gswork" <gswork@mailcity.com> wrote...
Some of the anecdotes in this thread point to a lack of sensible
algorithm usage, and why this might be. A good illustration of
algorithm speed is fibonnaci numbers, the recursive 'simple' version
vs one that stores some values locally to speed things up. It shows
what a difference algorithm choice can make. I'm not sure any
language design can mae so big an impact.

How do you mean? If I had to generate Fibonacci numbers I think I'd use a
loop, not recursion. (Never had to do it though so have never needed a fast
version.) I'm interested in the idea of storing values "locally." Why
couldn't the compiler work out the need for that?

"gswork" <gswork@mailcity.com> wrote in message
news:81f33a98.0411050107.351973ca@posting.google.com...
snip
Some of the anecdotes in this thread point to a lack of sensible
algorithm usage, and why this might be. A good illustration of
algorithm speed is fibonnaci numbers, the recursive 'simple' version
vs one that stores some values locally to speed things up. It shows
what a difference algorithm choice can make. I'm not sure any
language design can mae so big an impact.

How do you mean? If I had to generate Fibonacci numbers I think I'd use a
loop, not recursion. (Never had to do it though so have never needed a fast
version.) I'm interested in the idea of storing values "locally." Why
couldn't the compiler work out the need for that?