🚀 go-pugleaf

In article <1993Jan22.193019.12936@news.eng.convex.com>, Patrick F. McGehearty <patrick@convex.COM>
writes:
|>[...]  There are always more
|>potential optimizations and features to add to a language like Fortran
|>than there are resources to add them (Fortran 90 makes this statement
|>self-evident :-).  If a compiler group has been entirely driven by the old
|>simple benchmarks such as Whetstones, Dhrystones, and Linpack 100x100, 
|>they will not even realize that there is a worthwhile optimization to be
|>made in this case.  If they use real production applications, then the
|>optimization may get on their to-do list, depending on their target market
|>segment. 

Hmmm.  Do you mean that compiler developers may have the resources
to deal with masses of strange, horrible codes written or used by all
the folks out here? To analyze these codes and see where they spend time?

This is probably too much to ask.  But I am wondering.  Maybe any one of
us (users) could spend some time in putting together some "typical" code,
containing a simplified version of the loops where our programs spend
most of the time.  Staying within, say, 100 lines.  These "test cases" could 
be posted on c.l.f. (and stored at some anon ftp site) and compiler developers 
could have a look at them and perhaps improve the compilers.

These typical loops could perhaps also be coded as self-contained
benchmarks a-la-Linpack, inducing a bit of competitiveness :-), 
helping us to understand better the strengths and weaknesses of the
various architectures, but not necessarily so.

Any comment?

furio
--
furio ercolessi    <furio@uiuc.edu>*    <furio@sissa.it>+
* materials research lab, uni illinois at urbana-champaign
+ intl school for advanced studies, trieste, italy   

"Change nothing and continue with immaculate consistency"
                                      [ Brian Eno, "Oblique Strategies" ]