[Openmcl-devel] Quick HW question...
j-anthony at comcast.net
Tue Nov 16 09:06:05 CST 2010
Many Thanks for the info.
On Mon, 2010-11-15 at 14:32 -0700, Gary Byers wrote:
> Someone asked about the i7, and I remember professing ignorance (several
> paragraphs of it.)
> The Mac Pro (at least some models) use/have used Intel XEON processors
> which in turn use HTT; it's reasonable to assume that the OSX scheduler's
> been HTT-aware for some time. (I don't know if it's true, but it's a
> reasonable assumption.)
> CCL uses spinlocks on most platforms; acquiring a spinlock involves a
> loop like:
> (block got-lock
> (dotimes (i *spin-lock-tries*)
> (if (%store-conditional something somewhere)
> (return-from got-lock t)))
> where *spin-lock-tries* is 1 on a uniprocessor system and maybe a few
> thousand on a multiprocessor system. On a system that uses
> hyperthreading, that sort of loop interferes with the hardware's
> ability to schedule another hardware thread, and it's necessary to
> use a special "pause" instruction (a kind of NOP) in the loop to
> advise the hardware that the current thread wasn't really making
I've seen something like that idiom in some LAP function(s), with the
'pause' instruction included. But there was an additional outer loop of
"timeout tries", with yields for each, where a yield is a punt to the
OS. This was on Linux x8632.
> While profiling a customer's application a few years ago, we found
> that - when run on XEONs - a lot of time was reported as being spent
> looping around waiting for spinlocks. I said "D'oh!" and added a
> "pause" instruction on the execution path, but that didn't make things
> better; on Linux, we replaced the use of spinlocks with a slightly
> more expensive mechanism, and (paradoxically) things improved, at least
> on the XEONs.
> That never made sense to me, and I always suspected that something was
> just wrong in the implementation (the "pause" instruction happened
> out-of-line) or that we were seeing profiling artifacts. At the time,
> there wasn't time to explore this issue more fully, but those suspicions
> have lingered.
> CCL generally does a lot less locking (of hash-tables, streams, ...)
> than it did a few years ago. We still use spinlocks (some) on
> non-Linux platforms, so if there was a bad interaction between spinlock
> loops and hyperthreading it's likely still there but may not show up
> as often.
OK, noted (and those lockless entities are definitely nice!)
> Other than that issue, I'm not aware of any way in which HTT is directly
> visible to non-OS code.
> On Mon, 15 Nov 2010, Jon Anthony wrote:
> > Hi,
> > I know the Wiki page for SysReq states no known issues with X86_64, but
> > I seem to recall something passing through here about some "issue" with
> > Intel Core i7 on Mac, or maybe generally, or am I just plain
> > misremembering? On a related note, does MacOS understand HTT (does it
> > know the diff between physical and logical cores)? Thanks for any info!
> > /Jon
> > _______________________________________________
> > Openmcl-devel mailing list
> > Openmcl-devel at clozure.com
> > http://clozure.com/mailman/listinfo/openmcl-devel
More information about the Openmcl-devel