i7 mobile explanation?

Hi guys,

Can someone pls explain to me in layman's terms how Intel makes a 1.6ghz i7 processor faster than some higher speed processors? I'm just trying to understand this new technology...any help would be great.

Thanks.

 

first: it's new technology, so it's made to do it's job better at same "speed" than the previous one.

second: if not all cores are used, it can clock the remaining cores higher.

see this:

 

Alright thanks man. If I'm reading this right, then it basically overclocks cores depending on core usage? Sounds pretty sweet. But if it's using all 4 cores then is the maximum only 1.6ghz per core?

 

the maximum is never really dependent on the clockspeed, but the termal envelope the cores have to stay in. together, they have to stay in a fixed TDP.

but yes, i think they stay at 1.6ghz together. still, that is amazing fast, considered it's still 4 cores then at full speed running. that's 6.4ghz + some 20% gain from the hyperthreads, or around 7.7ghz. now a core2duo would have to have 2x3.8ghz to reach that performance.

this was based on some software rendering tasks which i like (raytracing).

so if you f.e. want to raytrace, you get, with a 1.6ghz i7 something similar to a 3.8ghz c2d. and a 3.8ghz c2d won't fit into a laptop

 

mmmm...a lot of that actually went over my head, but it sounds like the i7 tech should provide significant gains over the current range of processors. I was wondering because, I want to buy a new laptop but was wondering if it was worth waiting for i7. Sounds like it is.

 

depends on the type of laptop. if you plan to have a huge superfast machine that can do everything, yeah. i personally use laptops because they're small, portable, and fast enough. thus, i7 is currently nothing for me. i still can't wait for the day where we get an ULV quadcore (or LV at least).

and what went over your head? all i did was multiplying count of cores with the gigahertz they have. 4x1.6ghz = 6.4ghz. add 20% performance gain trough hyperthreading (each core can do 2 things in parallel, a bit faster than doing each after the other) and you get around 7.7ghz. then divide this by two to "spread" it to your dual core of choice (core2duo), and you get around 3.8ghz.

very simple math. not accurate, but still giving the idea.


or you can use more simple math:

4x1.6ghz == 2x3.2ghz. so the core i7 @ 1.6ghz is always at least as fast as a 3.2ghz core2duo. it is, most likely, always faster.

 

You cannot really add up the GHz of each core. They are basically 4 physical CPUs. 4 cars going at 60 miles per hour is not 240 miles per hour. Same thing with CPUs. (Actually the i7 has Hyperthreading so it has 8 threads instead of 4, but for the sake of simplicity lets just say it has 4 cores.)

But if an application is extremely parallel and can use all 4 cores efficiently, then it can get work done really quickly compared to 1 core. A good analogy is you have to take 20 friends to the theater. It is faster if you take 4 cars (with 5 person per car) to take all 20 friends at the same time instead of taking only 1 car to take 5 person at a time. These very parallel applications are usually video encoding and transcoding applications.

The Turbo mode helps in situations where applications are not very parallel. Like most video games and watching flash videos on Youtube.

 

Alright sweet, thanks. Do you think it's worth upgrading if I plan to use it for gaming and Photoshop? Or getting a Core2Duo enough for it?

 

It depends upon what games you play. The i7 is definitely much faster than the Core 2. If you play the latest 3D games and you have a quality graphics card, then it is worth it.

If the i7 is within your budget, then definitely get the i7 over the Core 2. I am not sure how much more expensive the mobile i7 will be over the Core 2 though.

 

actually, yes, you can add the gigahertz that way if you have an app running on all 4 cores. this works extremely well. a quadcore @ same ghz has twice the fps in my raytracer as a dual core.

why does it work? because if you can distribute your instructions over all the cores, they perform cores x ghz instructions. it's that simple.

but parallelizing software isn't simple, and that's where the i7 fits in: it clocks higher when the system is not fully parallels to all cores.

to take your example: 4 cars at 60 mph will drive 240 miles in an hour. if you're for example setting up the pics for google street view, using 4 cars instead of 1 means you're 4x as fast at mapping the whole streets. but this means, you have to manage it that all 4 cares drive on 4 DIFFERENT streets while photographing.

one thing the cores don't help is latency. but at 1.6ghz, you're at 0.625nanoseconds per instruction, reducing that latency to one forth won't matter in most cases (games, rendering, video encoding, etc).

the only thing where it happened to matter, actually, was in music production. music isn't very complex, but has to be generated at a very high rate. there, higher ghz helps compared to the same corexghz in cores. (but after 1.2ghz, it starts to blur and not gain anymore).


so, yeah, my original point still stands. if a quadcore runs at full usage, it runs at 4x it's ghz, compared to a dualcore at full usage having 2x it's ghz performance, and a singlecore system having 1x it's ghz.

 

@ Daveperman

What you say only applies to situations like raytracing which uses all 4 cores efficiently to get your work done. On the Core 2 Duo, there was no Turbo mode that dynamically overclocks 1 to 2 cores in single threaded applications. So if you have a single threaded application on a Core 2, it will only go as fast as 1 core allows it to. The remaining cores are just sitting around doing nothing in single threaded applications.

In multi-threaded applications like raytracing, yes 4 cores will get your work done faster. You, two friends on NBR, and I can collectively cover as much distance as Usain Bolt in a 200 meter dash, but the 4 of us are not as fast as Usain Bolt. That was what I meant by you cannot exactly add up the clockspeed. There are situations where the 4 of us would be better and there are situations where Usain Bolt would be better.

 

yes it will

http://valid.canardpc.com/show_oc.php?id=647836
http://valid.canardpc.com/show_oc.php?id=551676

 

Actually the IDA technology applied in the Core2Duo architecture does automatically overclock one core if only one is being heavily utilised. It's not a massive overclock like that seen in the i7 architecture, but it is still a dynamic overclock.

 

and i SAID this was for multithreaded apps. he asked about it specifically. he asked if it runs on 1.6ghz when all four cores are running. and if it's fast enough to beat a core2duo, then.

 

hehe well, you can't buy one was what i ment. in that clevo, you could clock the i7 even much higher.

 

IDA is so worthless. This Turbo mode is only good for regular consumers. I already overclocked my i7 920 desktop CPU from 2.66GHz to 4.2GHz on water-cooling.

 

only good for regular consumers means useful for mostly anyone.... *sight*

 

I cannot accept addition of clockspeed as that is technically incorrect. Clockspeed is not synonymous with work rate. However, I can accept that work is done faster when using more threads.

 

Turbo mode does nothing for me when I already overclocked the CPU to the max already. That is why I said regular consumers because they do not overclock their computer.

 

IDA does not offer a massive overclock, absolutely, I already said as much in my previous post. I was merely correcting the fact that you stated there was no "dynamic overclock" on the Core2Duo architecture, when in fact there is.

For the vast majority of people out there, two cores running at anything over 1.8GHz is plenty, many can run with considerably less than this. Professionals and gamers may need / want more; but we have to accept that a large proportion of machines are sold to people who do nothing more than browse the net, use office apps, store music & edit holiday videos and pictures. For these people, they don't need massive overclocking, and IDA serves them perfectly well.

 

well, then learn how multithreading works and realize that it's EXACTLY THAT.

if you create 4 car building roboters, they can build 4x cares at the same time.

if you can split a workload into pieces, you can work it in parallel. doing 4x in parallel is the same as doing 4x faster in serial. that is so simple that i can't understand how you can't get that?

the only PROBLEM with multithreading is, a lot of workloads can't get split into nice little pieces that can be done in parallel. still, most that need fast performance can. rendering, physics, compression and espencially decompression (hd movies f.e.), etc.

games have to be rewritten, but can, too.


clockspeed is synonymous with work done per system type. any core2duo and core2quad does the same amount of work per core per clock. (except when it hits another bottleneck, likely on early quads the memory bandwidth).

obviously you can't compare clockrates of DIFFERENT systems (like an atom 1.6ghz with a core2duo @ 1.6ghz). but all same-platform systems do their work at the same speed, only differing by amount of cores, and clockspeed.

 

you said "IDA is so worthless". because it doesn't help you? it's still not worthless AT ALL if it helps everyone else

 

but parallelizing software isn't simple, and that's where the i7 fits in: it clocks higher when the system is not fully parallels to all cores.

"There's also the issue of background threads running in the OS. Although your foreground app may only use a single thread, there are usually dozens (if not hundreds) of active threads on your system at any time. Just a few of those being scheduled on sleeping cores will wake them up and limit your max turbo frequency (Windows 7 is allegedly better at not doing this)."

from http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3641

 

i only noticed today that these cpu's are out when i was on the alienware website and saw the new m15x and i expect they'll be on the m17x soon enough

 

Your analogy, while basically true, is an oversimplification of multi-core performance gains in multi-threaded applications. You're assuming that all the threads being processed by each core are finished at exactly the same time, which is never the case in real-world processing. Execution of thread A may be dependent on the output of thread B which is being done on another core and completed at a different rate. These interdependencies that occur within a multi-threaded application are further complicated by the fact that the tasks do not complete at the same time. As a result, thread A ends up waiting for thread B and thus accomplishing no work. While this is a pretty bland example, it demonstrates your error.

So, you cannot add up the clock frequencies of a multicore CPU in order to cumulatively measure performance; it oversimplifies things to the point of not being true, and this is shown by the surprisingly modest performance gains (~20% in most apps) exhibited when the first dual-core CPUs hit the market.

Just because the cores have the same potential to accomplish work does not mean that they have equal work rates simply because they are working to complete different tasks, which oftentimes depends on the work done by another core. This is why multi-core CPUs don't deliver proportional performance gains per core, even if you optimized the application for multi-threading.

EDIT: I would also like to add that there is no easy way of explaining the benefits of multi-core computing to a layman (ie, the average people that walk into Best Buy). There are no analogies that work, even the one that pacmandelight offered with driving a pack of friends to a theatre because not all the cars will arrive at their destination at the same time! So your friends will end up waiting at the theatre for the others to arrive.

 

Yeah i have to say, as i understand it, more cores isn't really more speed (thats what the clock is) but more space to fit things on ( like 1.6|1.6|1.6|1.6| can handle around 6.4 GHz of usage, but i dont think it makes it faster, its just it has more space for the calculations (as opposed to 2|2| duo core)

One could argue that sure encoding will go faster on the 6.4ghz (which it will) and say that its down to the cores adding up, but its more space for calculations isn't it?

(Im still learning more about how CPU's work so forgive me if this is a complete load of rubbish, im still learning as noobs do )

And yeah, the other cars never arrive on time (even in wprime32)

 

Nice post. Maybe the analogy would be that some of your friends are extremely overweight and they don't end up evenly spread in the cars - therefore the cars exerting the same amount of acceleration will not all reach the destination at the same time, but it would still be faster than making several trips

Probably not a great explanation to a potential customer at BestBuy though........

 

Here are the olympians running 200m around a track, by the end the 4th guy will be like 5-10 seconds behind the rest.

EDIT* THE LAST RUNNER SHOULD EAT CHOCOLATE EVERY DAY, lol.

 

You could substitute any reason as to why the cars don't reach the destination at the same time, apart from having different cars. In any case, what reason you use doesn't matter since they all make an analogy of the same thing.

Having fat friends is problematic, though.

 

Yeah, the threads dont assist the other ones, they just wait for the others to finnish (although i think they do in cynbench or whatever it was with the motorbike render, but that was probably set to do that.)

 

it is the case if you can split the job into tiny parts that you can schedule. which is about all the time where you have to process large amounts of data, a.k.a., then, when speed matters.

and can easily be fixed by making that thread start on a new junk of work while the other one waits for finishing (a.k.a. using more than one thread per core.. if you dive further, this is exactly how gpu's handle their shading processing right now)

not true. any real multithreaded app, a.k.a. all that, till then, supported high end machines with multiple cpu's (or even networked processing) scaled by close to 100%, mostly hitting other limits like memory bandwith. all sort of 3d renderers, cad apps, etc showed that gain.

the others failed to gain because they never had multithreading to split workload in mind. they had multithreading to process some slow data in parallel (preloading the next level in the background without hitting into the framerate of the current level that gets played)

still, the limit of what can be done is exactly that: cores x clockpersecond shows a number that is comparable. if you can parallelize your app, that's what you can expect as long as you don't hit any other limit (including your app not capable of being parallelized). this is true 100% of the cases.

i DID state that it's mostly impossible to parallelize an app to 100%. but most of the time, the biggest workloads of an app can easily be done.

well, it's easy: you take more than one person, call each one a core, and say, now, work together.

you have to change the way you work, to effectively gain 4fold when being 4 people. but you can manage to do it in a lot of repetitive tasks. not so, in complex non-repetitive tasks. and the same has to be done on a program level to use the multiple cores well.

simple, easy even for your mom, and 100% accurate.

 

in that demo, they just wait. most complex computations don't let a thread wait for the other (but there has to be some sync in the end, so in the end, the last bits have to wait for the last one).

but thread a could easily process 10 chunks of work, thread b only 4 chunks, thread c 7 chunks and so on, so that they get to the end at the same time. that actually happens quite often if you have some cpu with hyperthreading, as some of the worker-cores are just like "kids", if you take the analogy of several person trying to accomplish a task together.

 

This does not work across different CPUs (ie, Turion vs Core 2 Duo vs Athlon) where they do not perform equally well on the same task.

Besides the fact that we are not talking about GPUs, there are applications that do not line up threads on a core. In addition, you still have different threads waiting on each other; while you can mitigate that limitation by assigning the cores to do something else while they wait, it doesn't solve the problem altogether, and this assumes that you have additional tasks to queue up on a suddenly idle core.

We could debate theory all day; in the end, benchmarks from different sites support the fact that multi-core CPUs do NOT offer 100% proportional performance gains per core. Perhaps you find this difficult to accept because you're assuming programs are written perfectly (or nearly perfectly) in terms of multi-threaded optimization. This is almost never the case.

For one thing, I mentioned most apps: I should be more clear. I am referring to mainstream applications used by many users. Suddenly you are referring to high-end machines (a minority of hardware) with industrial applications (a minority of software). While I don't doubt the veracity of your claim on some CAD applications and ray tracing programs, these are extremely rare animals in the jungle. Meanwhile, you are also referring to different hardware to suddenly support your argument: multiple CPUs (also rare) and distributed and cluster computing (rarer still).

The rare circumstances that support your argument are not likely applicable to the original poster of this thread or even anyone on this forum.

First you say that the limitation of potential work = actual work, then you claim that they are "comparable". You're contradicting yourself besides the fact that real world results do not support your claims.

 

i stated it's not comparable over different architectures. i said for same ones.

and most work that takes long on nowadays computers can be parallelized in some form. mainstream apps are often not cpu bound except for games, which happen to be able to parallelize quite well, but the game programmers are quite lazy at learning how to program well (i know quite some of them, they are really wayyy behind in software design).


i just don't get how hard my argument is.

if you can split a job into four or more pieces, a quadcore can do it 4x faster than an equivalent singlecore at the same clockrate (as long as it doens't hit another bottleneck). there is nothing complicated in that, nothing that you can't get. it's just 4 people doing work in parallel. if you have 1000 papers that have to get put into envelopes and send out today, then having 4 persons doing it means each does (around) 250, and you have 4x faster working.

it's that dead simple. and people fit well in that equation, as everyone does it's work a bit different, and so does each core, thanks to thread scheduling, other tasks it has to do (pee, drink coffee, scan for viruses, check mail..), it's no 100% perfect thing. but all in all, it works out pretty well.

a lot of applications till today are not designed to be able to handle their job like if multiple persons work at the same problem. most could be ported to it, but programmers are all lazy. if there's no money to make, why go the hard route?


but you're all just rather.. closed minded if you can't get that.

 

and i STATED THAT! applications HAVE TO BE PROGRAMMED FOR IT. the free lunch is over. intel agreed on that, and people have to learn how to program for the new "free lunch".

but that doesn't change that an app made for multiple cores just scales perfectly well as long as it doesn't reach another bottleneck. just as rendering on a gpu scales perfectly well with more pipelines, a parallelized app scales with more cores. from a dual core, to a quadcore, to a sixcore, to 8x6 core installations. mostly, they then hit other bottlenecks, though.

 

You're simply repeating what you previously said... and now you're calling me narrow-minded for not agreeing. Well I laid out my arguments quite clearly and many of them haven't been addressed. I don't have anything more to put forward.

 

You clearly don't understand what I just said:

This assumption does not depend on whether the application has been programmed for it; even if it has, there may not be other tasks to queue up on an idle core.

They don't scale perfectly well even if you run the most optimized multi-threaded application possible. That's what we've been arguing this entire time, and you're not really presenting any new information; instead you've begun insisting that I'm narrow-minded.

 

i am in no disagreement actually. i just don't get why you disagree with me. i am a programmer, i worked hard studying multithreading, and it's no easy beast. i have friends in the gaming industry (console games, even more fun to multithread with all the other restrictions, and portability between consoles.. ps3 and xbox360 for one game? hell..).

i just said that for performance comparisons, that if a system uses all 4 cores completely, you can estimate it's performance as 4x1.6ghz. just as the, then fully used dual core would have 2x3.2ghz to deliver about the same performance.

with this statement i have nowhere said that this would be a common case right now, or in the future. i just said IF THIS IS THE CASE (as it was asked by the OP), then you could compare like that. and there is NOTHING wrong in that (except that the i7 has some optimisations, making it faster clock per clock and core per core, but actually the differences are quite small).

 

at wich point it would not reach 100% cpu usage even on a single core: when it has nothing to do anymore. and yes, the end part, where waiting for the last core happens, is not 100% used. but if you can split your jobs in small enough parts, that is maybe a millisecond over a task working over minutes.

any app that stil has something to process, and capable to schedule to another core scales perfectly till it hits some other bottleneck, like memory bandwith. mostly 3d renderers do scale such well, they are the best example.


oh, and, i've done it, several times. it does scale that well. even on my crappy memory limited quadcore i can get over 98% cpu usage, or close to 4x gain. but it's hard to get around it's memory bandwidth limits. (Q6600).

 

Yeah from what i can see,both of your statements are pretty much true, i guess its really a case of if a single core of the quad (etc a worker) decides to move to another set of instructions, or stand around, i guess in that part, its really down to how the app is coded, and if the tasks queued for the processor.

 

yeah, and the op asked specially about an app that uses all 4 cores. so it's not an "if it can use all four cores or not", but, if it does, what happens then, and, is 4x 1.6ghz then slow? (as it sounds that way.. "only 1.6ghz").

 

Yeah, it does seem quite low, but when you come to think of it, being about to utilise 6.4 ghz of space in a sense (not raw speed) it doesnt appear that slow at all, and hyperthreading is there for a bit of a boost too.

(i suppose the mix of cinebench r10 and wprime can accurately show the different types of how cores can either move to other instructions or stay on there own, i shall grab some more pics just to show even more clearly to people that dont understand it to much just what has been meant.)

 

btw, a typical app not scaling to multiple cores well is ableton live, a live music software that i use. an individual instrument is single threaded for obvious below-millisecond-synching reasons, and multiple instruments would parallelize well. but if certain instruments affects each other (common in electronic dance music.. check out sidechaining if you're interested), they can't be parallelized (yet). the result: if you side-chain or otherwise affect all your audio channels in some form together, you get a singlethreaded app in the end.

so for ableton live, the core i7 should be a blessing. no matter what you do, it can spread the workload to all cores if possible, or enhance the "fused" threads which have multiple interoperating instruments in (and thus use more cpu% anyways) by clocking higher.

i plan on getting one of these beasts for audio production one day.. or the next iteration of it

 

But can we really compare clocks for clocks with the quads? I mean, this is a new architecture, so at same clocks the i7 is probably faster no? (not taking into account hyperthreading or turbo boost)

 

To a degree yes we can, however i7 does hold the advantage, l3 cache, hyperthreading, its definately a step up from c2q,

Below you can see the start of a WPrime1024 run, all the threads are pretty bunched together, (each thread is a core remember and this application is the one where if a thread finnishes, it'l wait for the others)




And here you can see the threads 1,2 and 4 finnished where as 3 is still calculating, so heres a good example of just a typical kind of multi thread app, its efficient but nothing special.




The next few screenshots shows CB R10 (Cinebench rendering basically) which renders and image using the CPU (S) with each CPU rendering about 25% for itself, however in this application, the workers/threads (whatever you like to call them) are allowed to help other workers/threads.

At the start, you can see the lines, there rendering downwards horizontally, and each worker has its assigned chunk to render.



Next you can see that A and B workers are tagging along quite happily, C is a laggy fool and D is on fire (C or thread 3 always seems to lag :S ) D is nearly finnished however.



And the last one you can see that D has finnished and gone over to help C out, so the rendering will finnish much faster if there are now 2 CPU/Workers on 1 chunk to render.



Now im not too sure on how this program completely works however if its testing each CPU individually then you get a brief idea on how each one is doing, and how None of them are in sync, or another explanation could be, C has the most calculations while the others are getting away quite easy, this basically in a way shows you a few gripes of multcore rendering.

As for the fellow I7, if im correct, we have 4 logical cores with hyperthreading ability on each, so the i7 can handle up to 8 threads in total at 1.6GHz which is nothing short of slow (dont forget hyperthreading should effectively give 20% boost or so?), and with the faster instructions cache should compare pretty nicely with the q9000 that i've used here.

Cpu-z are tricky business, but i think at the end of the day, its down to developers as well as the CPU architecture (prehapsI7 will sync nicer then c2q, i dont know but only time will tell )

Im still quite a narb at CPU's but hopefully some of the pro's comments will enlighten everyone

 

I have a question, which might appear a bit basic, but would be appreciated if someone could answer: If I have a core i7 and I give it four threads to work with, does it split that amongst each of the cores - 1 thread each, or does it give it to two cores and force them to hyperthread but overclock the cores because only two of them are working and the temperature is within the specified thermal envelope?

 

exceptional post. you can always tell when a fellow engineer posts.

 

^ I agree. His explanation was better than mine.

I admit that my car trip analogy is still imperfect at explaining multi-core performance. The quick and dirty way is to say that you add up the frequencies of the cores. However, real world and synthetic tests do not always show this performance increase. There are a lot of inefficiencies when it comes to multi-core CPUs.

There are also a lot of inefficiencies for multi-GPU performance. My ATI Crossfire setup does not scale 1:1 in every single game. Some games you get nearly twice the performance but in other games, you only get 20 percent or less increase from the 2nd GPU. This is also the case for my friend's Nvidia SLI setup. For every video card you add to the system, you get even less performance scaling on average.

 

Okay,

Did I just got fu** If I just bought A computer with nearly the same spec (a slightly better Graphic card) as the studio15 with a ie7 1.6,

A return is in order or the gain is minimal?

my cpu was a core 2 duo 2.56

 

Depends what you are using your notebook for.