This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[PING][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: Tue, 18 Mar 2014 10:41:16 +0100
- Subject: [PING][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> <20140314100017 dot GB13535 at domone dot podge>
On Fri, Mar 14, 2014 at 11:00:17AM +0100, OndÅej BÃlka wrote:
> 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.
>
--
The kernel license has expired