[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