Hello folks,

I have been programming in fortran for about a year and a half since I
wrote my "Hello World" program. Since then my projects get bigger and
bigger and although I own two fortran manuals... Metcalfe, Reid and
Cohen, and Ellis, Phillips and Lahey, I still do not know very well
how to set options on my compiler to make programs run fast or how to
do profiling of the programs... or something even more basic, how to
tell when your coding style are making things running slower than they
should. Soooo my question is if anybody knows about any good source to
self train your self

Thank you as always

Hi

To learn how to use your compiler read the manual until your eyes
bleed with the effort, it will be worthwhile in the end. Look for
optimisation, fast, that sort of word, in the index.

To profile programs, well that is at least partly platform dependent,
where platform = operatingSystem+compiler+toolset. On Linux you'll
probably find a copy of gprof already installed -- use the usual
sources for information (Google, man, info). You may also discover
that your compiler comes with a profiler thrown in -- for example the
Portland Group compiler provides a tool called PGPROF. On Windows,
I'm not sure, does Visual Studio include a profiling tool perhaps ?

To write programs which run quickly: careful use of compiler options
is usually the first and best route to faster programs. With O(1 day)
effort you can achieve O(2) speedup. Then it gets harder. You might
want to start modifying your code to take best advantage of the memory
hierarchy on your computer(s) -- if you don't know what this means,
then you should find out. But this can be very time consuming to do
effectively, offering O(2) speedup at a cost of O(10 days) effort.

"octaedro" gmail.com> wrote in message
news:560c2727-01b8-46a3-8bb6-6f2f769891a8@f24g2000prh.googlegroups.com...

If you want to discover whether your coding style is making things
run unnecessarily slowly, there simply is no substitute for examining
the compiler output, i.e. a disassembly of the machine languge code
the compiler generated. You can no more guess what you might have
done that creates a situation where the compiler has to do extra
work do achieve your purpose than you can find the invisible bugs
in your code by reading it for the fourth time without testing.

Hello,

On 2008-05-02 12:47:46 -0400, "James Van Buskirk" comcast.net> said:

I beg to differ.

If you want to know how _fast_ some code is,
time it. It's hard to predict what today's hardware
will do with an emitted code sequence.

Dan Nagle wrote:

I would say somewhere in between.

First, some coding styles will generate bad assembly code
which will run slow on all processors.

On May 2, 3:29 pm, glen herrmannsfeldt ugcs.caltech.edu> wrote:

"Mark Westwood" gmail.com> wrote in message
news:2c70fd38-d6de-4f7b-8279-aa81d0a83526@m45g2000hsb.googlegroups.com...

I have to say, given that the OP is relatively new to programming, that your
advice was an excellent guide on how to get started. Getting inexperienced
programmers to pore over assembly code is without question the least useful
approach.

Regards,

Mike Metcalf

glen herrmannsfeldt ugcs.caltech.edu> wrote:

[discussion of code optimization]

I disagree that it is useful at all for most people to look at generated
code. I haven't done so myself for ages. I particularly think it not
useful for relative novices such as the OP.

Take instead, the advice of Hoare and Knuth, which was briefly echoed by
Mark in this thread, but seemed sort of buried to me.

First and foremost, pay attention to algorithms. That is really, really
important. And you need to actually do it rather than just give it lip
service. You also need to keep doing it, regularly revisting the
question as appropriate to something that is the most important factor
in program speed. Whenever I hear something like "I already did that",
it tends to make me think that it wasn't really taken seriously enough.

Sure, there are times when you have done everything practical with
algorithm selection and still need some more. But it is *SO* important
and so often inadquately done that I think it needs a bit of harping on.

"Dan Nagle" verizon.net> wrote in message
news:2008050215590437709-dannagle@verizonnet...

On May 2, 11:47 am, octaedro gmail.com> wrote:

The best approach is to write straightforward code and let the
compiler do the tricks (though you might have to experiment with
compiler flags) besides using vendor supplied numerical libraries. For
more info check out http://www.osc.edu/supercomputing/training/perftunmic/perftune.ls.pdf