On 2026-02-19T23:18:16+0100, Steffen Nurpmeso wrote: > Hello Alejandro! Hello Steffen!
> > Alejandro Colomar wrote in > <aZeGabzZUpS4fT4B@devuan>: > |On 2026-02-19T22:15:29+0100, Steffen Nurpmeso wrote: > |> Crystal Kolipe via Mutt-dev wrote in > |> <[email protected]>: > |>|On Thu, Feb 19, 2026 at 02:32:45PM +0100, Alejandro Colomar via Mutt-dev \ > |>|\ > |>|wrote: > |> > |> I think "the best" is a table lookup. > |> I use the below script to create a lookup table, it is easily > |> adaptable (it is 128 bytes + alignment, and it could be like this > |> ASM looks even better, all in all. > | > |By "best" are you optimizing for performance or readability? I prefer > |readability any day. We're not libc nor cc(1); we don't need to > |have the absolute best performance, or we'd be writing assembly (this is > |what glibc does, indeed). We can get 80% of the juice with trivial > |one-liners that get optimized by the compiler and libc. > > You were talking assembly! But i am too, yes, i mean x86 has > an explicit XLAT instruction, for example (never used it). > In general with a constant single-instance lookup table and > all-inlined accessors of that, .. of course the table is to be > located relatively to the global offset table, but no "call" at > all, could turn out as maybe even two instructions ("test(b) bit, > mem", plus whatever then comes). > If you make the table 256 bytes you can even scratch "is-7-bit" > check and simply do table[(u8)..char..] & BIT1[|BIT2..]. > (Ie, that is the other nice thing, you could test certain things > with one lookup, ie space|punct|alnum, or whatever.) That's indeed what I'd expect of a good libc implementation. But I don't want to do that. Readability is much more important to me. I was checking the assembly to show that even though the code looked quite heavy at first glance, it wasn't that much (compared to other implementations that use more basic string functions). Of course, a LUT beats anything, but the implementation is far from readable. And it only works for isascii(3) functions, but not so much for skipws(), because you need to write a loop, at which point you don't necessarily beat strspn(s,CTYPE_SPACE_C) anymore. So isascii(3) APIs are only so fast in theory; most often, the fastest approach is to not use isascii(3) at all, but use strspn(s," \t") or something similar. Cheers, Alex > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
