This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2][BZ #16640] Remove strtok assembly implementation.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 14 Mar 2014 11:00:17 +0100
- Subject: Re: [PATCH 2/2][BZ #16640] Remove strtok assembly implementation.
- Authentication-results: sourceware.org; auth=none
- References: <20140227123238 dot GA26291 at domone dot podge> <20140227124206 dot GA26474 at domone dot podge> <1489098 dot ZJs2lkVmBA at vapier>
On Tue, Mar 11, 2014 at 01:59:02AM -0400, Mike Frysinger wrote:
> On Thu 27 Feb 2014 13:42:06 OndÅej BÃlka wrote:
> > As followup this patch removes strtok assembly implementation as it is
> > around 2-4 times slower on sse4_2 capable machines which is a majority,
> > as previous benchtest demonstrated.
>
> where are you getting "sse4_2 capable machines which is a majority" ? iiuc,
> AMD doesn't include SSE4.2 support. Intel released it in their CPU's starting
> in 2007 w/Nehalem, and i don't believe it's in any of their Atom CPUs.
>
>From bulldozer they do. As atom is concerned upcoming silvermont include
these.
> so can you requalify your justification for removal of these funcs to cover
> the significant install base that lacks SSE4.2 ?
> -mike
As I asked in original post do we actually care? As strtok is thread
unsafe historic function and I am not sure how tokenization could be
bottleneck, does that justify maintainance burden?
Other reason is that there is still plenty room of improvement for
strpbrk+friends, a needle often stays constant and without sse4.2 we unnecessarily
recreate 256 byte array for each call is ineffective. A strtok would benefit from
that too. I will send WIP patch for it soon.