[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] MiNTlib timing related functions behavior/performance



Hi,

On keskiviikko 17 huhtikuu 2013, Andreas Schwab wrote:
> Eero Tamminen <oak@helsinkinet.fi> writes:
> > By far most of the time in Quake startup, and in rendering a frame
> > in Doom, is spent by localtime.o from MiNTlib, between these symbols
> > in the binary:
> > ---
> > d0fd0 T localtime.o
> > d30fc T _tzsetwall
> > ---
> > tzsetwall is symbol from localtime, but for some reason there are no
> > symbols before that in the linked in localtime.o content, although
> > one can see them with "mn":
> > ---------------------
> > $ ar x libc.a
> > $ nm localtime.o | sort -n
> > ...
> > 
> >          U _strncpy
> > 
> > 000025e6 T _tzset
> > 000027ae T _mktime
> > 000027c6 T _timelocal
> > 000027dc T _timegm
> > 000027fc T _timeoff
> > 0000274a T _gmtime_r
> > 0000275e T _offtime
> > 0000278a T _ctime_r
> > 0000281e T _time2posix
> > 00002572 T _tzsetwall
> > ...
> > ---------------------
> 
> How comes that _tzsetwall is the symbol with the lowest address?

Hm.  Linux "sort" seems to behave the same.  This sorts them right:
$ nm localtime.o | sed 's/^0/0x/' | sort -n
0x0002572 T _tzsetwall
0x00025e6 T _tzset
0x0002706 T _localtime
0x0002720 T _localtime_r
0x0002734 T _gmtime
0x000274a T _gmtime_r
0x000275e T _offtime
0x0002776 T _ctime
0x000278a T _ctime_r
0x00027ae T _mktime
0x00027c6 T _timelocal
0x00027dc T _timegm
0x00027fc T _timeoff
0x000281e T _time2posix
0x0002862 T _posix2time
0x0005708 D _tzname
0x0005714 B _daylight
0x0005718 B _timezone

But _tzsetwall is still the one with lowest address.  It seems
first function in localtime.c that's non-static, but I think there
should be at least some local symbols that are in lower address.

Maybe Vincent could provide log for his MiNTlib build, in case
there's something funny with that...


> > However, gettimeofday():
> > * uses Tgettimeofday() on MiNT and Tgettime() & Tgetdate() on TOS.
> > * Then it does mktime() which does timezone stuff, and if non-null
> > 
> >   value is given as timezone arg (like Quake does), it will also
> >   call timezone stuff directly.
> 
> What does Quake need the timezone for?  This is long obsolete.

I guess Douglas is using old (90's?) Quake code because newer ones are
much heavier and might even gotten completely rid of the software
renderer.


> But mintlib should not be calling the localtime stuff for the timezone,
> this is meant to be the _kernel_'s idea of the timezone.  If MiNT does
> not keep track of a time zone gettimeofday should just return zero in
> the timezone argument.


	- Eero