question about timing used in Windows

  • jim_monte


    I noticed that to find elapsed time in the
    Windows version, src\librt\timer-nt.c uses time(),
    which has a resolution of 1 second.  Is there a
    reason why more accurate calls from the Win32 API
    (e.g., QueryPerformanceCounter()) were not used?

    The comments in this file mention that the
    it is used for finding times on the NT family
    of OSs.  Should I read from this that
    BRL-CAD will not run on the 9x family or
    am I reading too much into that one comment?
    If it does not, what specifically does not

    Jim Monte

    • jim_monte

      I wrote a replacement based on Win32 API
      calls QueryPerformanceCounter(),
      QueryPerformanceFrequency(), and
      GetProcessTimes().  This allows much higher
      resolution on the wall clock time.  CPU
      time has problems in the previous version due
      to the implementation of clock().  Win9x does
      not implement GetProcessTimes() or another way
      to find CPU usage by a thread or process.  So
      I was curious how clock() was implemented.
      I found that even in NT, it just returns elapsed
      time, NOT CPU time.  My replacement returns
      kernel and user times for NT and a negative
      value for 9x to indicate that the information
      is unavailable.


      • Sean Morrison
        Sean Morrison

        Is this fix readily available anywhere? :)  I don't see a link nor is it in the patches tracker..

        • jim_monte

          See my earlier post.  I will certainly include
          it along with my other changes.

          Regarding the Win 9x compatibility, in case
          you are not aware of it, the Win32 API is
          implemented slightly differently in each
          family.  Windows 95 was built to run with
          4 M of RAM, so some things just did not fit
          in.  In other cases, it appears that it was
          an unfortunate case of two development teams
          not communicating.  I have a fondness for
          Windows 95, so I try to write programs that are
          compatible with it unless there is a very good
          reason to use a newer feature.  Usually it is
          not that difficult but some uncommon things are
          implemented very differently.


    • Sean Morrison
      Sean Morrison


      Only because that code was written quite a while ago before there even existed a comprehensively tested Windows port and it hadn't been looked at since.  QueryPerformanceCounter() is indeed the way to go.

      That comment wasn't meant to imply it only runs on the NT family.  If anything, the comment reflects that the code was simply written and tested on NT only.  It just happened to still work as the port to Windows was worked on and nobody noticed.

      There is also nothing intentionally (and hopefully nothing unintentionally) being used that outright prevents the package from functioning on any of the Win32 platforms.  Since we don't have a dedicated Windows developer at the moment working on the project consistently, there is only so much time and effort that can be put into "officially" supporting more than XP right now.  But again, that is mainly just due to resources and time.  As more (Windows) open source devs get involved in the project, this can easily change.  I'm certainly hoping more devs like yourself become involved, and are perhaps even interested enough in becoming a part of the dev team.  ;-)