Mail Archives: pgcc/1998/09/05/13:31:19
On Sat, 5 Sep 1998, Vincent Diepeveen wrote:
> At 04:37 PM 9/4/98, you wrote:
> >Vincent, I can't reach you via private mail!
> >I'm sorry for sending this to the list.
> >>|------------------------- Failed addresses follow: ---------------------|
> >> diep AT xs4all DOT nl ... transport smtp: 571 <diep AT xs4all DOT nl>... You can't use
> this mailserver as a relay for this address.
> >>Subject: Re: pgcc-1.1a - first impression
> >
> >>What about using MSVC and programming stuff somewhat better?
> >>Then you only need to wait for a few months.
> >MSVC? No, thanks. Do you have MSVC for something other than Windows or DOS?
> >Could you imagine Windows machine running flawlessly for few months? Running
> >a cluster of Windows machines flawlessly?
> >Let us stop the discussion at this point. I don't have MSVC and won't buy
> >or even steal one.
> >And the program is mixed FORTRAN and C code (trivial, if you have f2c).
> >It went already through many improvement iterations. This is not
> >the right place for discussion about it. There are problems in computational
> >quantum chemistry/physics, which cannot be done in an hour.
>
> I ran 2 weeks with msvc at NT sp3. Memory leak in sp3 is fixed.
>
> >>The reason that those bizarre optimizations like -fno-runtime-lift-stores
> >>are faster is only because the program is not written very well.
> >Not _faster_, but _reliable_. This option gives _bad_ code.
> >Krzysztof
>
> Wow, that's weird. Why need it? Another problem in (p)gcc?
>
> I've tried all gcc compilers and almost all options available.
> NOT A SINGLE OPTION gives better code than -O2
>
Snipp ....
> Yet hard to see is where the difference in speed is between the
> compilers. Loops are so well written that both gcc and msvc optimize it
> equally well. Not an instruction i would be able to spare when thinking as a
> compiler. Easy to code patterns too.
>
Maybe, my point of view is a little bit different. I am on this
mailing list not for the long time. So I apologize...
As far as I noticed, the improvement in speed is something like 10%.
Maybe, it's impressive, but not so much. I found out that the real
thing is to take advantage of the c o m p l e t e hardware
structure (Regs, L1, L2, latency etc). By using these dependencies
carefully
an improvement by 200-300% is possible. Since I am using my PC (AMD
K5 based) for number crunching, the heart of all efforts is careful
optimization of the whole system for carefully selected routines
(kernels of routines).
But this does not concern the compiler...
Krzystof, maybe, you can speed up your computations by using
hand-optimized blas etc for Pentium. Or have a look at atlas or
phipac.
Yours,
Michael
+---------------------------------------------------------------+
| Michael Hanke Royal Institute of Technology |
| NADA |
| S-10044 Stockholm |
| Sweden |
+---------------------------------------------------------------+
| Visiting address: Lindstedtsvaegen 3 |
| Phone: + (46) (8) 790 6278 |
| Fax: + (46) (8) 790 0930 |
| Email: hanke AT nada DOT kth DOT se |
| na DOT mhanke AT na-net DOT ornl DOT gov |
+---------------------------------------------------------------+
- Raw text -