[PATCH 3/3] resolv: Optimize inet_ntop

[Maciej W. Rozycki]

On Mon, 9 Jun 2025, Adhemerval Zanella Netto wrote:

> >> I am not sure, with gcc 14.2.1 this version is indeed faster on aarch64 (Neoverse N1),
> >> but slower on x86_64 (Zen3):
> > 
> >  How many samples did you collect?
> 
> For both x86_64 and aarch64 I collected on an idle system that I assured
> no extra OS jitter would interfere in the result, and I don't see much
> variability over multiple runs (I will need to do some statistics analysis
> to give a proper number).

 Fair enough.  Usually fixed results can be only obtained on bare metal, 
where there's no interference from the environment, such as hardware 
interrupts affecting TLBs, caches, etc.

 Given that this is about low single-digit percentage performance changes 
even variability in the fractional part matters, and I could certainly see 
such with my almost idle 64-way SMP system (16 CPU cores times 4-way SMT), 
which has enough computing power and RAM available for the task scheduler 
not to interfere.

> >  I can't benchmark Aarch64 or x86-64 easily, but I note that my proposal 
> > produces fewer multiplications for both plus lets x86-64 take advantage of 
> > the carry flag via SBB instead of using a discrete conditional-set+add 
> > sequence, so chances are it'll perform better.  It produces more compact 
> > code too, and I think it might be more readable for some though YMMV.
> > 
> >  Though the dependency on the quality of the optimiser seems very fragile 
> > here, e.g. if the locals are changed to a signed data type, then POWER9 
> > produces an extra instruction that causes performance to drop by ~2.5%, 
> > but x86-64 is able to convert another conditional-set+add to SBB, which 
> > for a change likely causes a performance gain.
> 
> I am even more inclined to use with my current version below mainly because
> it shows less surprising results on different chips.  And we already getting
> a 10x improvement over current implementation, so we can fine-tune this even
> more once we figure out why AMD chips are behaving like this.

 I agree.  It could be a missed optimisation issue with GCC, although I 
think there's value in a variant that gives good overall results with 
generic tuning, so that distribution binaries run fairly well across a 
wide selection of systems.

  Maciej