search

justinethier / cyclone

:cyclone: A brand-new compiler that allows practical application development using R7RS Scheme. We provide modern features and a stable system capable of generating fast native binaries.
http://justinethier.github.io/cyclone/
MIT License
823 stars 42 forks source link

@arthurmaciel Moved from gettimeofday() to the more precise clock_gettime() #451

Closed arthurmaciel closed 3 years ago

arthurmaciel commented 3 years ago

@justinethier, for more precision, may I change current-jiffy to return nanoseconds (in a bignum) instead of microseconds as is now? Is the bignum allocation a significant slow down?

Independently of using gettimeofday or clock_gettime, should we have a failsafe implementation for more restricted platforms? I am not sure which platforms Cyclone targets.

I am fiddling with this because I need a simple benchmark library. I have checked that both Python and Julia use clock_gettime and return the number of seconds as a double with up to 9 decimal points (nanoseconds). But our specification demands the return of an exact integer.

R7RS just for reference:

(current-jiffy) time library procedure Returns the number of jiffies as an exact integer that have elapsed since an arbitrary, implementation-defined epoch. A jiffy is an implementation-defined fraction of a second which is defined by the return value of the jiffies-per-second procedure. The starting epoch is guaranteed to be constant during a run of the program, but may vary between runs.

Rationale: Jiffies are allowed to be implementation-dependent so that current-jiffy can execute with minimum overhead. It should be very likely that a compactly represented integer will suffice as the returned value. Any particular jiffy size will be inappropriate for some implementations: a microsecond is toolong for a very fast machine, while a much smaller unit would force many implementations to return integers which have to be allocated for most calls, rendering current-jiffy less useful for accurate timing measurements.

justinethier commented 3 years ago

@arthurmaciel Thanks for the pull request. I don't remember why the code used gettimeofday instead of clock_gettime, but from what I can tell there is no good reason not to switch. Let me get this merged in later tonight.

Regarding bignums, I would prefer to keep returning a double to keep the overhead down. That said, bignums would probably not incur a major hit to performance. How critical is it to add the extra precision? It could make sense to have a benchmark loop several times, as the r7rs benchmarks do, in which case the results may ultimately be on the order of seconds, or only a handful of decimal places.

arthurmaciel commented 3 years ago

@justinethier, thanks for the answer. Following your recommendations I have proposed #452 to change core code to use clock_gettime().

Now we have a very simple benchmark package that returns seconds with up to 9 decimal places (nanoseconds). We can keep R7RS orientation to return an exact integer with (current-jiffy), but gain more precision with the new library, if needed.