Re: Parsing timestamps?

mhx@iae.nl (mhx) writes:

Well, that is strange ...
>
Results with the current iForth are quite different:
>
FORTH> bench ( see file quoted above + usual iForth timing words )
\ 7963 times
\ naive-sum        : 0.999 seconds elapsed. ( 4968257259 )
\ unrolled-sum     : 1.004 seconds elapsed. ( 4968257259 )
\ recursive-sum    : 0.443 seconds elapsed. ( 4968257259 )
\ shift-reduce-sum : 2.324 seconds elapsed. ( 4968257259 ) ok

Assuming that you were also using a Ryzen 5800X (or other Zen3-based
CPU), running at 4.8GHz, accounting for the different number of
iteratons, and that basically all the elapsed time is due to user
cycles of our benchmark, I defined:

: scale s>f 4.8e9 f/ 10000e f/ 7963e f* ;

The output should be the approximate number of seconds.  Here's what I
get from the cycle:u numbers for iForth 5.1-mini given in the earlier
postings:

\ ------------ input ---------- | output
 6_482_017_334 scale 7 5 3 f.rdp 1.07534 ok
 6_452_716_125 scale 7 5 3 f.rdp 1.07048 ok
 2_949_273_264 scale 7 5 3 f.rdp 0.48927 ok
14_634_786_781 scale 7 5 3 f.rdp 2.42785 ok

The resulting numbers are not very different from those you show.  My
measurements include iForth's startup overhead, which may be one
explanation why they are a little higher.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html