The i5 doesn't have Hyper-threading and only has 4 cores, i7 does and has 8

[ibwb]

Thank you!

Could anyone weigh in on the future of HT'ing? Are more apps being developed with/for it increasingly or is it stagnant or ??? And what about games?

I'm not a big gamer but wonder what the difference between i5/i7 would be on say - Spore.

HT is likely to stick around, as long as we are using CPU cores which are drawing on the current philosophy of processor design (massively complex underlying architecture). As these cores are "heavyweight" there is a pretty good chance at any time that they will have significant unused resources which could be exploited by another thread, so adding another front-end to the die remains worthwhile.

As far as software goes -- games and otherwise -- multithreaded operation will soon be the only game in town. In the 70s-90s CPU designers were constantly finding ways to use new transistors to improve the speed of single-threaded execution, so everybody bought single-core computers and programmers didn't bother with concurrency. That long age is now conclusively over; we're still getting lots of new transistors, but CPU designers have run out of ways to use them and are just giving us more cores.

So under current trends it's inevitable that programmers will be writing more concurrent software, to the limits of their ability (or they will get trounced in performance by their competitors). As concurrency in the software improves, we could see a move toward larger numbers of simpler, lightweight processing units (as demonstrated in the currently-useless Cell architecture, or the "100-core" stuff you hear about in the media). In that future HT could be worthless, since the cores would be too simple to run more than one thread, and you'd prefer to use the space for more cores.

In the context of purchasing a computer now, HT is nice to have and will likely become more useful over the 3-5 year horizon. (Disclaimer: I have an i7 on order and could be subject to rationalization bias.)

 

[sfroom]

OMG DID YOU KNOW THE NEW IMAC HAS MAC OS X!!!! OTHER PC COMPUTERS HAVE THIS OTHER OS CALLED WINDOWS!!!!!!

JUST TRYING TO HELP THOSE WHO DIDN'T KNOW!!!!

HT is what makes the i7 different from the i5. An i7 without HT is an i5. Your post is like saying "did you know the Intel iMac has an Intel processor??!!!" Sorry but you can't be that naive, start a whole thread about it and then get all upset when people poke fun at you.

You're being a bit of a jerk. "PC Computers" is redundant, PC stands for "personal computer"..."personal computer computers"?

An i7 without HT might be similar to the i5 750, but the i5 line will soon include 2 core processors as well as 4. When Clarkdale hits, i5's will have HT enabled too.

As others have pointed out, even if you want to consider ONLY Lynnsfield, there are other things that differentiate the i5 and i7. One being the lack of HT, and one being that the processor only turbo's 2 bins instead of 3 (a la i7 860)

 

[Eidorian]

I've never attempted that (my Mid 2007 MB cannot handle that), but it would be nice if I could. So yeah, I would rather be able to do some of those simultaneously.

Well I did Handbrake, gaming, and recording digital over the air on a Q6600 and I do it know on my Core i5 750 right now.

 

[gnasher729]

Could anyone weigh in on the future of HT'ing? Are more apps being developed with/for it increasingly or is it stagnant or ??? And what about games?

Hyperthreading is a strange thing. You don't actually develop code "for hyperthreading", you develop code for using multiple cores.

Any code that a programmer writes doesn't use all the resources of the core that it runs on. Sometimes operation B has to wait until operation A is finished, and that core does nothing for a cycle or two. Hyperthreading uses these leftover cycles. You have two threads running on the same core, and everytime one thread doesn't use all the resources of the core, the other thread can use the leftovers. It doesn't give you _very much_ extra performance, but it is cheap, so it is worth doing.

If you read this again, you'll find that hyperthreading works better with badly written code. Badly written code has more leftover cycles. If you have badly written code that uses only half of what one core could do, hyperthreading could make things run twice as fast. If you have perfectly written code that uses 100 percent of all the power of a core, hyperthreading doesn't buy you anything.

But what you can do is to write code that uses as many cores as possible. If you can use 4 cores, your code is 4 times faster. If you can use 8 cores, then your code is eight times faster on an eight core machine, and maybe 5 times faster on 4 cores + hyperthreading. If you can use 16 cores, then your code is maybe ten times faster on an eight core + hyperthreading machine instead of only eight times faster.

 

[ViViDboarder]

Hyperthreading is a strange thing. You don't actually develop code "for hyperthreading", you develop code for using multiple cores.

Any code that a programmer writes doesn't use all the resources of the core that it runs on. Sometimes operation B has to wait until operation A is finished, and that core does nothing for a cycle or two. Hyperthreading uses these leftover cycles. You have two threads running on the same core, and everytime one thread doesn't use all the resources of the core, the other thread can use the leftovers. It doesn't give you _very much_ extra performance, but it is cheap, so it is worth doing.

If you read this again, you'll find that hyperthreading works better with badly written code. Badly written code has more leftover cycles. If you have badly written code that uses only half of what one core could do, hyperthreading could make things run twice as fast. If you have perfectly written code that uses 100 percent of all the power of a core, hyperthreading doesn't buy you anything.

But what you can do is to write code that uses as many cores as possible. If you can use 4 cores, your code is 4 times faster. If you can use 8 cores, then your code is eight times faster on an eight core machine, and maybe 5 times faster on 4 cores + hyperthreading. If you can use 16 cores, then your code is maybe ten times faster on an eight core + hyperthreading machine instead of only eight times faster.

Interesting point, but I suppose it should be stated as a reminder that well written code will just not see a speed INCREASE. It will still run faster than the poorly written version as there would be no wasted cycles.

Also, using more cores is not always better. There are implications with memory management when more cores are used. Some tasks just lend them self better to single processor use.

Depending on the application of the code, you will get different performance enhancements with different numbers of cores. Basically, the runtime is not a quadratic equation but more like a log function.

 

[jf8]

Hyperthreading is a strange thing. You don't actually develop code "for hyperthreading", you develop code for using multiple cores.

More correctly, you write code that uses multiple threads and assumes the threads are scheduled on separate cores.

Hyperthreading uses these leftover cycles. You have two threads running on the same core, and everytime one thread doesn't use all the resources of the core, the other thread can use the leftovers.

More correctly, one core runs instructions from more than one thread in a way that maximizes the number of instructions being executed per clock, which minimizes the probability of a pipeline stall (possibly what you mean by "leftover cycles"). It also allows more than one thread to run without an expensive context switch.

If you read this again, you'll find that hyperthreading works better with badly written code. Badly written code has more leftover cycles.

In many cases, code that will result in HyperThreading being more/less effective is generated by a compiler. Code need not be "badly written" to cause HyperThreading to be more/less effective. HyperThreading can run instruction(s) from another thread during times when the instructions from one thread need to be delayed (due to dependency or access to cache/memory), but that doesn't necessarily mean that the cycles would be "left over"; it just means that HyperThreading increases the instructions per cycle.

Since different CPU implementations have different performance characteristics, writing a single program that will maximize performance on current and future CPUs is often not possible. Two programs that do the same thing can have two different implementations that perform differently on different systems.

If you have badly written code that uses only half of what one core could do

"half of what one core could do" is ambiguous. If the process is only being scheduled half the time without HyperThreading, enabling HyperThreading will reduce the time spent in context switches but won't make that process any faster. If the process is only scheduled half the time because it uses a slow resource, running two processes that use separate resources might result in almost twice as much total throughput without the use of HyperThreading.

If the process is starved for memory access but scheduled on the CPU all the time, enabling HyperThreading and running two threads for the task will likely make things worse because the threads will share memory bandwidth and cache.

But what you can do is to write code that uses as many cores as possible. If you can use 4 cores, your code is 4 times faster. If you can use 8 cores, then your code is eight times faster on an eight core machine, and maybe 5 times faster on 4 cores + hyperthreading. If you can use 16 cores, then your code is maybe ten times faster on an eight core + hyperthreading machine instead of only eight times faster.

No.

 

[RexTraverse]

Since there appear to be a few people here who know what they're talking about, can someone explain how Hyper Threading and Grand Central Dispatch will differ, as far as end user performance is concerned?

 

[meagain]

I appreciate the explanations re the future of HT.

I think this turned out to be a great thread after all!

 

[C64]

I appreciate the explanations re the future of HT.

I think this turned out to be a great thread after all!

Same here. Thanks for all the insights. Although every time I think I've decided on the i5 or the i7, I read something else that makes perfect sense, and I'm lost again .

 

[300D]

can someone explain how Hyper Threading and Grand Central Dispatch will differ

They are completely different things.

HT allows two sets of code to use different portions of the same CPU.
GCD is a tool that helps developers write code that can be easily split into multiple jobs across multiple cores.

 

[RexTraverse]

They are completely different things.

HT allows two sets of code to use different portions of the same CPU.
GCD is a tool that helps developers write code that can be easily split into multiple jobs across multiple cores.

Well yes... I know they're different and I've read plenty on how each of them work. But again, as far as end user performance goes, what is the difference? They both seem to be trying to accomplish the same goal..

 

[Nutter]

But again, as far as end user performance goes, what is the difference? They both seem to be trying to accomplish the same goal..

Hyper Threading is a hardware trick which aims to squeeze a little extra performance from a core by having it masquerade as two cores, and cleverly managing resources if the OS throws two threads at it. From the point of view of the OS and applications a 4-core HT processor is the same as an 8-core processor without HT, and should be treated as such.

GCD is a software technology which makes it easier for application developers to use threads. Besides considerable convenience, the main advantage it offers over managing threads directly is that it automatically distributes units of work over a global pool of threads, typically one per processor core (real or virtual — as I said the OS doesn’t know or care). This allows the app to use a large number of cores if available without sacrificing performance when running on a computer with a small number of cores.

So, GCD is a tech to help software make use of multiple cores. HT is the CPU designer's way of exploiting such software to avoid wasting resources which would normally be wasted when running one thread at a time on a core.

 

[aakif]

just sharing my findings...._accurate!

though I don't have a Mac, but I've got i5.....

I used to wonder at seeing 4 Cores on my machine, but today finally I found out that it has ONLY 2 Cores.

I've i5 2450M Processor in my machine, and it shows 4 processors in task managers, cpu meters and other tools.!

I found at Intel that it has ONLY 2 Cores, but 4 threads.....
Its just the virtual stuff as you people had stated...

Here is a link to my processor's info at Intel's Website:
LINK IS HERE

and if you wish to check if your Processor supports Threading, and how many Cores your processor actually has follow this link:
LINK IS HERE