<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<BR> <BR>
<BR>
<BR>
<BR>
> From: ringing-theory-request@bellringers.net<BR>> Subject: ringing-theory Digest, Vol 65, Issue 8<BR>> To: ringing-theory@bellringers.net<BR>> Date: Sat, 6 Feb 2010 12:00:02 +0000<BR>> <BR>> Send ringing-theory mailing list submissions to<BR>> ringing-theory@bellringers.net<BR>> <BR>> To subscribe or unsubscribe via the World Wide Web, visit<BR>> http://bellringers.net/mailman/listinfo/ringing-theory_bellringers.net<BR>> <BR>> or, via email, send a message with subject or body 'help' to<BR>> ringing-theory-request@bellringers.net<BR>> <BR>> You can reach the person managing the list at<BR>> ringing-theory-owner@bellringers.net<BR>> <BR>> When replying, please edit your Subject line so it is more specific<BR>> than "Re: Contents of ringing-theory digest..."<BR>> <BR>> <BR>> Today's Topics:<BR>> <BR>> 1. Re: Exhausted search spaces (Mark Davies)<BR>> 2. Parallel searches [was Exhausted search spaces] (Mark Davies)<BR>> 3. Re: Parallel searches [was Exhausted search spaces] (Graham John)<BR>> 4. Re: Parallel searches [was Exhausted search spaces] (Mark Davies)<BR>> 5. Re: Exhausted search spaces (Simon Humphrey)<BR>> 6. Re: Exhausted search spaces (Graham John)<BR>> 7. Hyperthreading [was Exhausted search spaces] (Mark Davies)<BR>> <BR>> <BR>> ----------------------------------------------------------------------<BR>> <BR>> Message: 1<BR>> Date: Fri, 05 Feb 2010 17:11:52 +0000<BR>> From: Mark Davies <mark@snowtiger.net><BR>> To: ringing-theory@bellringers.net<BR>> Subject: Re: [r-t] Exhausted search spaces<BR>> Message-ID: <4B6C5158.1080701@snowtiger.net><BR>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>> <BR>> Simon Humphrey writes,<BR>> <BR>> > Surely you don't have a 6 GHz processor, Mark? I thought 3.0 Ghz is<BR>> > still about the limit for processor speed/ Modern technology is only<BR>> > able to provide more computing power by squeezing multiple processors<BR>> > onto the same chip, but that won't speed up single-threaded<BR>> > applications.<BR>> <BR>> No, my current machine is a 2.8GHz i7 quad-core, and (for SMC32) it's <BR>> only barely as fast as my previous box, an Athlon X2 4200.<BR>> <BR>> I don't know why your PC is performing so badly on the SMC32 benchmark. <BR>> Possibly your L2 or L3 caches aren't up to scratch, or maybe disabling <BR>> hyperthreading has made it worse. I'm not quite sure why you've done <BR>> that, as I don't think it'll give you any benefits! I could be wrong, <BR>> but I certainly wouldn't expect it to help SMC32.<BR>> <BR>> In terms of I/O, yes in theory that can be a bottleneck. In practice, <BR>> even if you're producing a composition every 30 microseconds, there is <BR>> much more work to do in the search phase than there is in the output <BR>> phase. The number of bytes output for each composition is small, and the <BR>> disk writes are buffered. Given the above, the CPU should never be <BR>> waiting on I/O on a normal search.<BR>> <BR>> Computers and their associated numbers never cease to amaze me, after <BR>> all these years. We still sit around waiting for busy cursors for <BR>> minutes on end, cursing how slow they are - yet with a decent bit of <BR>> code they can search for, prove and output a composition in a few <BR>> microseconds. A microsecond is really too short a time for the human <BR>> brain to properly imagine, but it is actually a vast aeon for a modern <BR>> CPU. You can carry out maybe ten thousand arithmetic operations in a <BR>> microsecond. Awesome.<BR>> <BR>> MBD<BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 2<BR>> Date: Fri, 05 Feb 2010 17:15:21 +0000<BR>> From: Mark Davies <mark@snowtiger.net><BR>> To: ringing-theory@bellringers.net<BR>> Subject: [r-t] Parallel searches [was Exhausted search spaces]<BR>> Message-ID: <4B6C5229.5030500@snowtiger.net><BR>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>> <BR>> Graham wrote,<BR>> <BR>> > You create a processor pool. If there is a processor free, you assign it to<BR>> > your current branch and backtrack your current process on to its next<BR>> > branch. If a processor exhausts a branch or backtracks to its starting point<BR>> > you return it to the pool.<BR>> <BR>> Sounds about the size of it. It might be worth worrying a bit about the <BR>> size of the state frame you have to copy to a forked processor. If there <BR>> are frequent backtracks you might end up doing a lot of work copying and <BR>> restoring falseness tables etc. There are tricks that can avoid this, <BR>> but then again if the branches eventually become heavy enough, it's not <BR>> an issue anyway.<BR>> <BR>> MBD<BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 3<BR>> Date: Fri, 5 Feb 2010 21:41:30 -0000<BR>> From: "Graham John" <graham@changeringing.co.uk><BR>> To: <ringing-theory@bellringers.net><BR>> Subject: Re: [r-t] Parallel searches [was Exhausted search spaces]<BR>> Message-ID: <001601caa6ab$fae328d0$f0a97a70$@co.uk><BR>> Content-Type: text/plain; charset="us-ascii"<BR>> <BR>> MBD wrote:<BR>> <BR>> > It might be worth worrying a bit about the size of<BR>> > the state frame you have to copy to a forked processor.<BR>> <BR>> Yes, there is probably a significant overhead in checking whether there is a<BR>> processor free too, but this is just optimisation of the algorithm.<BR>> <BR>> > You can carry out maybe ten thousand arithmetic<BR>> > operations in a microsecond. Awesome.<BR>> <BR>> Indeed, as illustrated by a search for Cambridge Minor extents. SMC32<BR>> completes the search before its clock has ticked over the first millisecond.<BR>> <BR>> Graham<BR>> <BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 4<BR>> Date: Fri, 05 Feb 2010 22:04:00 +0000<BR>> From: Mark Davies <mark@snowtiger.net><BR>> To: ringing-theory@bellringers.net<BR>> Subject: Re: [r-t] Parallel searches [was Exhausted search spaces]<BR>> Message-ID: <4B6C95D0.3060803@snowtiger.net><BR>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>> <BR>> Graham writes,<BR>> <BR>> > Indeed, as illustrated by a search for Cambridge Minor extents. SMC32<BR>> > completes the search before its clock has ticked over the first millisecond.<BR>> <BR>> But that's a whole millisecond! A thousand times longer again than the <BR>> interval I was discussing. :-O<BR>> <BR>> MBD<BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 5<BR>> Date: Fri, 5 Feb 2010 23:21:25 +0000<BR>> From: Simon Humphrey <sh@keystrata.co.uk><BR>> To: ringing-theory@bellringers.net<BR>> Subject: Re: [r-t] Exhausted search spaces<BR>> Message-ID: <20100205232125.000037aa@unknown><BR>> Content-Type: text/plain; charset=US-ASCII<BR>> <BR>> On Fri, 05 Feb 2010 17:11:52 +0000<BR>> Mark Davies <mark@snowtiger.net> wrote:<BR>> <BR>> > I don't know why your PC is performing so badly on the SMC32<BR>> > benchmark. Possibly your L2 or L3 caches aren't up to scratch, or<BR>> > maybe disabling hyperthreading has made it worse. I'm not quite sure<BR>> > why you've done that, as I don't think it'll give you any benefits! I<BR>> > could be wrong, but I certainly wouldn't expect it to help SMC32.<BR>> <BR>> The level 2/3 caches are quite likely to be a problem, I guess, it<BR>> being an old processor.<BR>> <BR>> If I leave hyperthreading enabled (which is the default), then according<BR>> to the documentation the processor is effectively divided in two, and<BR>> SMC is confined to using just 50% of the processing capacity. Resulting<BR>> in run times twice as long, I would have thought. <BR>> <BR>> Now, hang on a minute, my run times ARE twice as long as yours. Hmm. I<BR>> wonder if disabling hyperthreading has actually had any effect at all?<BR>> Other than bamboozling Task Manager.<BR>> <BR>> I'm convinced. I'll build a new machine.<BR>> <BR>> SH<BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 6<BR>> Date: Sat, 6 Feb 2010 00:22:27 -0000<BR>> From: "Graham John" <graham@changeringing.co.uk><BR>> To: <ringing-theory@bellringers.net><BR>> Subject: Re: [r-t] Exhausted search spaces<BR>> Message-ID: <000001caa6c2$7674c1f0$635e45d0$@co.uk><BR>> Content-Type: text/plain; charset="us-ascii"<BR>> <BR>> Simon wrote:<BR>> <BR>> > If I leave hyperthreading enabled, then according<BR>> > to the documentation the processor is effectively<BR>> > divided in two, and SMC is confined to using just<BR>> > 50% of the processing capacity. Resulting in run<BR>> > times twice as long, I would have thought. <BR>> <BR>> It is not splitting the processor, it is duplicating part of it. It parallel<BR>> processes instructions to give a claimed 30% performance improvement. I ran<BR>> a SMC32 comparison on a hyperthreading processor in 2004 (possibly similar<BR>> to yours). The results for the "Full Monty" Cambridge S Major search were:-<BR>> <BR>> 1h49m single instance (but still with hyperthreading turned on)<BR>> 2h37m running two searches simultaneously<BR>> <BR>> So running two searches simultaneously was 28% quicker than running two<BR>> consecutively.<BR>> <BR>> In summary, leave hyperthreading on - you can read your emails with one side<BR>> of the processor while running SMC32 at full speed on the other.<BR>> <BR>> Graham<BR>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 7<BR>> Date: Sat, 06 Feb 2010 11:05:12 +0000<BR>> From: Mark Davies <mark@snowtiger.net><BR>> To: ringing-theory@bellringers.net<BR>> Subject: [r-t] Hyperthreading [was Exhausted search spaces]<BR>> Message-ID: <4B6D4CE8.9020006@snowtiger.net><BR>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>> <BR>> Yes, hyperthreading definitely doesn't "split the processor in two", or <BR>> reduce resources allocated to a single thread.<BR>> <BR>> All it really does is provide another set of registers, so that the <BR>> state for a second thread can be maintained without needing an expensive <BR>> context switch. Then, it is able to allocate existing processing <BR>> resources (instruction decoders, ALUs, branch prediction circuitry etc) <BR>> to the second thread when they are not being used by the main thread.<BR>> <BR>> There are no additional execution units on the chip, so fundamentally <BR>> it's just another way of keeping all the ALUs running all the time. If <BR>> you had only one thread running on your machine (e.g. SMC32) you'd see <BR>> no difference with it on or off. However, there are always other things <BR>> going on, e.g. Windows services or other background processes, even if <BR>> you have no other programs open. Without hyperthreading, when another <BR>> process is scheduled for runtime, a context switch must occur, after <BR>> which the original thread (SMC32) is completely stopped for the next <BR>> time slice.<BR>> <BR>> With hyperthreading enabled, other processes are more likely to be <BR>> scheduled to the second, "virtual" thread, and SMC32 will continue <BR>> (nearly) full bore whilst they are running.<BR>> <BR>> So I think you've definitely got the wrong idea Simon: turning off HT <BR>> will make things worse, not better. To be fair though, if you're only <BR>> running SMC32, I doubt you'll see much improvement switching HT back on. <BR>> An old motherboard is more likely to be the problem, as you say.<BR>> <BR>> MBD<BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> _______________________________________________<BR>> ringing-theory mailing list<BR>> ringing-theory@bellringers.net<BR>> http://bellringers.net/mailman/listinfo/ringing-theory_bellringers.net<BR>> <BR>> <BR>> End of ringing-theory Digest, Vol 65, Issue 8<BR>> *********************************************<BR><BR> <br /><hr />Not got a Hotmail account? <a href='http://clk.atdmt.com/UKM/go/197222280/direct/01/' target='_new'>Sign-up now - Free</a></body>
</html>