time command overly precise after 7756d8b

[Jim Ursetto]

Looks like the change to C_cpu_milliseconds causes (time) to display artificially precise numbers. Not immediately clear why, it should just be displaying up to usec.

Example: results of csi -script tests/port-test.scm is

slow...
0.166863s CPU time, 0.00136399999999999s GC time (major), 13414 mutations, 3/2039 GCs (major/minor)
fast...
0.00144299999999998s CPU time, 30 mutations, 0/3 GCs (major/minor)

versus previously:

slow...
0.036s CPU time, 0.001s GC time (major), 2740 mutations, 3/409 GCs (major/minor)
fast...
0s CPU time, 30 mutations, 0/1 GCs (major/minor)

[Jim Ursetto]

After screwing around with it for a while, the only reliable way I found to avoid it is to limit the flonum precision to 6 (i.e. microseconds), as in the attached patch.

The root cause could be that Chicken doesn't print or round flonums correctly sometimes -- for example it may print 0.00144299999999998 when the C library would print 0.001443 (with %.15g, precision 15). I've noticed this several times, but have not tracked it down yet. This happens when the bitwise representation of the flonum is verifiably correct, so I assume it is a bug in the printer. The fmt egg prints many, but not all, of these correctly.

In the meantime, maybe just limit the output precision?

[felix winkelmann]

I have changed C_cpu_milliseconds to floor the result, which should reduce the precision accordingly (see master). Does this work for you?

[Jim Ursetto]

Seems to work fine. I liked the new microsecond precision too, but if you want to cap it at ms that's fine.

[felix winkelmann]

Milestone 4.8.0 deleted