[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 May 2013 23:12:10 -0500
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Cc: musl@...ts.openwall.com
Subject: Re: cpuset/affinity interfaces and TSX lock elision in musl
On 05/17/2013 02:41:18 AM, Daniel Cegiełka wrote:
> Rich, Rob - thanks for the information. This is functionality that
> sooner or later, but it is worth to add to the musl.
>
> >> 2) The upcoming glibc will have support for TSX lock elision.
> >>
> >>
> http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions
> >>
> >> http://lwn.net/Articles/534761/
> >>
> >> Are there any outlook that we can support TSX lock elision in musl?
> >
> > I was involved in the discussions about lock elision on the glibc
> > mailing list, and from what I could gather, it's a pain to implement
> > and whether it brings you any benefit is questionable.
>
> There is currently no hardware support, so the tests were done in the
> emulator. It's too early to say there's is no performance gain.
>
> > Before making
> > any decision, I think we should wait to see some performance
> figures.
>
> musl is described as libc for embedded systems (raspberry pi, small
> routers, mobile etc.). Summing up: low-end hardware.
Where is it described that way? That wasn't my impression: it was a
simple generic C library for Linux and Android. We should be able to
build desktops with it just fine.
> I think musl is
> the ideal solution for high-end HPC servers etc., so that's why we
> should support innovative solutions (like TSX lock elision).
HPC and embedded are closer to each other than either is to the
desktop. They race to completion, we race to quiescence on underpowered
hardware; neither has persistent processes but more of a batch
mentality. We keep power consumption down to extend battery life, they
keep power consumption down because heat dissipation costs more than
the hardware...
Right now I'm in month 4 of a 6 month contract at Cray, the
supercomputer company. (No, not the one SGI bought: it split in two
when Seymour Cray retired and they gave him a $100 million research lab
as a retirement present. The half SGI _didn't_ buy expanded back into
the space and is again supercomputing in the big leagues.)
> We may
> also ask manufacturers (such as Intel) for help with optimization
> (they really help with glibc and gcc).
Worry about target-specific optimization after 1.0. Until then it's
premature optimization. Right now target-independent optimization seems
more interesting. (To me, anyway.)
Rob
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
