Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!74.125.46.80.MISMATCH!postnews.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 13 Feb 2012 08:46:22 -0600 Message-ID: <4F392235.1020804@SPAM.comp-arch.net> Date: Mon, 13 Feb 2012 06:46:13 -0800 From: "Andy (Super) Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 Newsgroups: comp.arch Subject: Re: Single Thread Performance References: <1083982.844.1328506553065.JavaMail.geo-discussion-forums@vbtr6> <18985540.1742.1328921030856.JavaMail.geo-discussion-forums@yqks7> <4F38875A.2050407@SPAM.comp-arch.net> <12562993.824.1329107776365.JavaMail.geo-discussion-forums@ynnj2> In-Reply-To: <12562993.824.1329107776365.JavaMail.geo-discussion-forums@ynnj2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 36 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-xrlnZj6kAyir8NMXoqD9ossvBHhPGtLpWyKO7/Z5EvQfsC3NgTuRLbWCc0i/8SUoMSIITmoqI69nvZ1!0o/TxyEEaUGG91eVcLeegTJ414jpqPwdCFaLtcdSM+GUcQgZSw+Vkzkc8tHECTg= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3204 Xref: x330-a1.tempe.blueboxinc.net comp.arch:5911 On 2/12/2012 8:36 PM, MitchAlsup wrote: > On Sunday, February 12, 2012 9:45:30 PM UTC-6, Andy (Super) Glew wrote: > >> What would a scalable implementation of hardware TM look like? Well, it >> can't depend on finite size caches, except as an accelerator. > > May I suggest that scalability is going to require that the Software gain some understanding of the amounts and kinds of interference and then have the SW do something proactive about it. > > My original ASF had this feature, the current one does not. > > Mitch What does that look like? Beyond what Intel TM already does: provide a way for the transaction to fail, and for SW to resort to some other algorithm, probably lock based. The proactive part would be for SW to say "Hey, it doesn't look as if this transaction will ever pass as a transaction - because it uses too much data, and/or because there are hot spots - so I won't bother ever to use a HW transaction for it." Possibly with profiling feedback, e.g. EMON profiling feedback, so that SW can learn even when it can't predict statically. What more do you want? -- By the way, lots of people jump on the fact that Intel's current HW TM has no transactional escape - no way to do memory accesses from INSIDE the transaction that go outside the transaction. E.g. no way to call malloc() from inside a transaction without aborting (because malloc often updates shared pointers). (Yes, I know: you can code mallocs so that they only update shared stuff if private pools are exhausted.)