Apple Store down
in [UK Mac]
|
Prev: USB2 PCI card
Next: XQuartz
From: Ben Shimmin on 14 Apr 2010 04:12 David Empson <dempson(a)actrix.gen.nz>: > SM <info(a)that.sundog.co.uk> wrote: >> Ben Shimmin <bas(a)llamaselector.com> wrote: >> > Turns out the i5 and i7 processors in the 15" and 17" models are *not* >> > quad-core: >> > >> > <URL:http://www.apple.com/uk/macbookpro/performance.html> >> >> You're right - I'd assumed they'd be quads. > > Ditto. > > Presumably a heat/power budgeting issue for not using the same series as > the iMac. I see Apple is claiming an improvement for CPU-intensive tasks > despite the drop in frequency from the previous generation. > > Confusingly, even the Core i5 has hyperthreading (four virtual cores), > so what is the difference between the i5 and i7 apart from the > frequency? Beats me. People seem to be ranting and raving about Apple's not using proper quad core processors on MacRumors.com, and yet the performance seems to be pretty good: <URL:http://www.macrumors.com/2010/04/13/early-benchmarks-show-significant-performance-gains-for-core-i7-macbook-pro/> People are also up in arms because the 13" models still have Core 2 Duo processors, but it seems this was because Apple couldn't (or wouldn't) fit a discrete GPU into the 13" and the only integrated GPU they could use with an i3 or i5 was the Intel HD, which apparently is significantly inferior to the NVIDIA offering. Or something. A couple of other interesting features in the new MacBook Pros, while we're at it: 1) automatic switching between discrete and integrated GPUs; no more annoying logging out and back in! 2) the trackpad now supports inertia scrolling. I don't know if they can (or would be willing to) make the older models do that too. b. -- <bas(a)bas.me.uk> <URL:http://bas.me.uk/> `Zombies are defined by behavior and can be "explained" by many handy shortcuts: the supernatural, radiation, a virus, space visitors, secret weapons, a Harvard education and so on.' -- Roger Ebert
From: zoara on 14 Apr 2010 04:31 Ben Shimmin <bas(a)llamaselector.com> wrote: > David Empson <dempson(a)actrix.gen.nz>: > > [...] > > > I'm less certain about which options are new. The 15" now mentions a > > 1680x1050 optional display resolution (required if you want the > > antiglare option), and SSDs are available up to 512 GB. > > The higher resolution is definitely new. If I could change two things > about my 2008 unibody MBP, it would be the battery life (mine predates > the ones with the allegedly much improved batteries, and thus > struggles > to manage three hours) and the resolution; 1440x900 feels a bit > limiting > sometimes -- 1680x1050 would be lovely and it'd match my 20" monitor > nicely too! > Battery life and heat here. I think mine's the Santa Rosa generation and it gets painfully hot. I hope the new ones are nice and cool. -z -- email: nettid1 at fastmail dot fm
From: Jaimie Vandenbergh on 14 Apr 2010 04:59 On Wed, 14 Apr 2010 07:41:32 +0100, real-not-anti-spam-address(a)apple-juice.co.uk (D.M. Procida) wrote: >David Empson <dempson(a)actrix.gen.nz> wrote: > >> Confusingly, even the Core i5 has hyperthreading (four virtual cores), >> so what is the difference between the i5 and i7 apart from the >> frequency? > >What on earth is a virtual core? Each physical core on the CPU has enough physical structures to parallelise some of its calculations, though not the actual execution parts. The parallelism is enough that if one thread stalls, another can be switched in very quickly, keeping the execution resources nice and busy. Intel think they do this well enough to pretend to the OS that each physical core is actually two cores. Hyperthreading is their marketing name for this. It was used back in Pentium 4 days, then dropped in favour of real multiple cores, and with the Core i7/i5/i3 series has come back. So a 4-core i7 chip with hyperthreading enabled shows 8 virtual cores. I note that OSX's Activity Monitor ignores this and only shows graphs for physical cores. Cheers - Jaimie -- Women's breasts are like electric train sets. They're meant for kids, but usually it's the fathers who wind up playing with them.
From: D.M. Procida on 14 Apr 2010 05:09 Ben Shimmin <bas(a)llamaselector.com> wrote: > 2) the trackpad now supports inertia scrolling. I don't know if they > can (or would be willing to) make the older models do that too. I don't see how it could be a hardware-dependent feature, and there are utilities to provide it on other trackpads too. But, it wouldn't surprise me if it were only enabled for newer models. Daniele
From: Bruce Horrocks on 14 Apr 2010 12:19
On 14/04/2010 11:34, Tim Streater wrote: > In article<om2bs5h8m9onqmjr24lpi5vsmn37q0oe87(a)4ax.com>, > Jaimie Vandenbergh<jaimie(a)sometimes.sessile.org> wrote: > >> On Wed, 14 Apr 2010 10:27:45 +0100, Tim Streater >> <timstreater(a)waitrose.com> wrote: >> >>> In article<tg0bs592580a7m186l3vngjut324rin20l(a)4ax.com>, >>> Jaimie Vandenbergh<jaimie(a)sometimes.sessile.org> wrote: > >>>> The parallelism is enough that if one thread stalls, another >>>> can be switched in very quickly, keeping the execution resources nice >>>> and busy. >>> >>> What does "stalls" mean in this context? >> >> Runs out of ability to be acted on. >> >> Say there's a couple of threads in the CPU's pipelines - one >> calculating prime numbers, and one waiting for a keypress. That >> keypress is going to be waiting a long time in CPU terms, so the >> thread is stalled. The CPU can get on with calculating primes for a >> moment, while a third thread is swapped in for attention. >> >> With a normal CPU, the whole CPU will have nothing to do until a >> second thread and it's state is swapped in. Terrible waste of time. > > Hmm, on the face of it this is old hat, I'll have to look it up, there > must be more to it than that. A thread waiting for a keypress won't be > scheduled for running anyway. It'll be in a WAITIO state or similar and > some other thread will be running. Or none, and the CPU will be on a > WAIT instruction until an interrupt comes along. At least, that's how we > did in the early 70s on a PDP-11. Jamie has the right explanation but the keypress example isn't a good one and it has thrown you off the scent. A process waiting for a keypress is far too high level for the CPU to worry itself about directly. Scheduling tasks for execution around a keypress wait will always be an operating system task. For a processor stall, consider the situation where the processor executes code that runs through a jump or branch instruction, perhaps the test at the start of a while loop. If test for the while loop requires access to a variable from memory (rather than one that is in a register already) then that memory access is incredibly slow from the processor's point of view. In a pipe-lined architecture the processor can assume that the while test will return true and continue to execute the statements within the body of the while loop while it waits for the slow memory access to happen. Once the memory access has completed, the processor knows whether its assumption was a good one or not. If good (i.e. the while loop did continue) then all is well and it carries on from where it got to and no time was wasted. If not, then the execution point in the code has to jump to the end of the while loop. Unless the while loop is very small then the code following it won't be in the instruction cache and will have to be fetched from memory. This takes a relative age during which time the processor is stalled: it can't do anything with its current pipeline as that is the wrong code and it can't refresh the pipeline until a slow memory access has completed. If the processor has two programs running 'simultaneously' then when one stalls it can save state, switch to the other process and continue running that. Eventually that too will stall, or will use up its timeslice, and execution switches back. Done well enough it looks like two processors hence the 'virtual core' terminology. -- Bruce Horrocks Surrey England (bruce at scorecrow dot com) |