bug-gettext
[Top][All Lists]
Advanced

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

[bug-gettext] Fwd: Re: Bug#671257: gettext: msgfmt output format prevent


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: [bug-gettext] Fwd: Re: Bug#671257: gettext: msgfmt output format prevents multiarch migration (fwd)
Date: Thu, 03 May 2012 20:42:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3


-------- Original Message --------
Subject:        Re: [bug-gettext] Bug#671257: gettext: msgfmt output format
prevents multiarch migration (fwd)
Date:   Thu, 03 May 2012 13:04:13 +0200
From:   Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>
To:     Bruno Haible <address@hidden>



On 03.05.2012 12:17, Bruno Haible wrote:
> > The opinion of people in charge of multiarch is that in the long run,
> > it would be much better if msgfmt's default changed in gettext to be
> > little endian again.
> I don't agree. Users of PowePC systems have the same right to optimized
> MO files as users of x86 systems. Therefore I would like to have the
> issue solved in Debian's build system. Let me know if you would need
> additional targets or variables in Makefile.in.in (on top of the configure
> option that I already mentioned).
The need to check whether the file is in little or big-endian is a
performance hit. You get a performance benefit only if you manage to
make swap cost outweight the check cost by e.g. having separate little
and big-endian functions (probably compiled from the same source with
different defines) or by swapping the whole file on load. Both
approaches increase memory footprint and this under some circumstances
may decrease the performance. Swapping is a trivial operation in
hardware and many CPUs have instructions to do it quickly. In case of
gettext, I doubt one can even measure it. The need to support 2 formats
can be worse than the need to byteswap. I primarily use little-endian
systems but I'd by far prefer big-endian format rather than guess-endian.
While performance advantages of this approach are dubious, the
additional code complexity or the need to stick to some specific
patterns is evident
> Bruno
>
>
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko





Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]