public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: I686 DOUBLE ALIGNMENT VS PERFORMANCE -Reply
       [not found] <199807091608.MAA29071@mescaline.gnu.org>
@ 1998-07-09  9:13 ` Craig Burley
  0 siblings, 0 replies; 2+ messages in thread
From: Craig Burley @ 1998-07-09  9:13 UTC (permalink / raw)
  To: tprince; +Cc: egcs, g77-alpha

>Might we be able to find a consensus on how clock(),
>system_clock(), cpu_time() should be done on various Intel
>OS's?  The current clock() and cpu_time() give 0.010 second
>resolution on Linux and NT, but several of the timers have 1
>second resolution under Windows95.  That could make this
>benchmark run over a day trying to find repeatable timings, if it
>didn't give up.

Do you mean "...should be done on various *Microsoft* OS's"?

FWIW, there are two things I try to keep in mind whenever I panic
about how hard it might be to discover how best to code up an
interface to some obscure OS (like a Microsoft one ;-) in a
GPL'ed product:

  -  GNU Emacs

  -  Perl

My guess is that, for almost anything you need to code up portably,
you can find the best way to do it in the sources to one of those
two products.  (For hardware interface issues, the two things
would be "Linux" and "some free BSD variant".)

Haven't tried this myself yet, but if you feel like looking through
Perl sources (starting with the language, if necessary, to learn what
timer facilities it offers its users), give it a try.

        tq vm, (burley)

^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: I686 DOUBLE ALIGNMENT VS PERFORMANCE -Reply
@ 1998-07-09 12:13 tprince
  0 siblings, 0 replies; 2+ messages in thread
From: tprince @ 1998-07-09 12:13 UTC (permalink / raw)
  To: egcs, g77-alpha

Livermore Kernel source at:

http://www.llnl.gov/asci_benchmarks/asci/limited/lfk/README.ht
ml

appears to be the most up to date official version.  It does a
better job than earlier versions in figuring out how many times it
needs to go to get accurate timing results, as well as generating
check-sums which don't vary with the number of iterations.  The
check-sums, however, are simply the results achieved on typical
SGI machines, not an accurate reference (g77 on Intel is more
accurate).  It takes over half an hour to run on machines with
marginal timer calls.

I'll post my version with check-sums accurate to 17 digits (yes,
run on SGI in REAL*16), and some cleaned up loops, as
well as everything formatted into g77/f90 compatible code, if you
care to remind me at  tprince@computer.org.  This one, of
course, can't be compared with the results from the official one,
as I have fixed the gnu-unfriendly peculiarities.

I must apologize; further investigation turned up some failures to
build certain copies of egcs fully, as well as discrepancies
between timings obtained on Linux and cygwin32 on the same
machine.   Some of these weren't evident until I used this current
version of lfk and worked on building timers based on the Intel
TSC (WinAPI QueryPerformance), which isn't used by standard
egcs or g77.  Also, neither the binutils install nor gmake work on
Windows95, leaving some unreliable manual copying to do.

Might we be able to find a consensus on how clock(),
system_clock(), cpu_time() should be done on various Intel
OS's?  The current clock() and cpu_time() give 0.010 second
resolution on Linux and NT, but several of the timers have 1
second resolution under Windows95.  That could make this
benchmark run over a day trying to find repeatable timings, if it
didn't give up.

           To:                                              INTERNET - IBMMAIL
                                                            N0566301 - IBMMAIL

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1998-07-09 12:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <199807091608.MAA29071@mescaline.gnu.org>
1998-07-09  9:13 ` I686 DOUBLE ALIGNMENT VS PERFORMANCE -Reply Craig Burley
1998-07-09 12:13 tprince

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).