What are the benefits of Hyper Threading?

[Winni]

Good joke man. Photoshop doesn't even support quad-core

That explains then why Adobe even released an octo-core patch for PhotoShop CS2 years ago...

Here's a simple tip for everybody who believes that multi-threaded software does not support more than two cores: Fire up Activity Monitor and observe how busy your CPU cores are. Strangely enough, you'll find that beasts like Aperture and HandBrake push all your available cores to the limit.

Most games don't take advantage of more than one CPU core, which is related to the classical "games loop". Typical office applications also have only limited use for multiple cores. But there are tasks that are scalable, especially in the audio/video/graphics department, and they take advantage of multi core systems.

 

[Winni]

In theory any program that uses lots of threads can benefit from multiple cored cpus, but unless they're coded to do so, they will not be compatible with multiple cored cpus.

It is not the job of the application to distribute threads over multiple CPUs - this is the job of the operating system. The application does not need to know about this at all.

I don't know enough about the mechanics within the OS X kernel, but in Windows NT-based systems, the application can specifically request a CPU affinity, meaning that it wants to bind a specific thread to a specifc CPU, but this is -not- the default behavior. Unless explicitly requested, the NT kernel automatically load balances the running threads over the available CPU cores. Since both the OS X and NT kernels have their roots in the Mach architecture, I presume that OS X does not behave much differently in this regard - and observing Activity Monitor in OS X seems to confirm this assumption.

 

[pinksatin]

handbrake

How much faster can an i7 encode videos from DVDs with Handbrake? Or file Rendering on Final Cut Pro...

 

[belvdr]

It is not the job of the application to distribute threads over multiple CPUs - this is the job of the operating system. The application does not need to know about this at all.

I'm no developer, but I don't think that's accurate. Running gzip through Cygwin on my Windows PC at work only uses one core.

 

[TMRaven]

I frequent the handbrake forums from time to time, and I do believe the developers built it with multi-cores in mind. So the hyperthreading in the 860 should boast some good improvements when using handbrake.

 

[andyOSX]

Good joke man. Photoshop doesn't even support quad-core

Oooh, maybe you should do some research so you actually have a clue what you're talking about next time. It would be less embarrassing than making misinformed jokes.

http://arstechnica.com/apple/reviews/2009/04/266ghz-8-core-mac-pro-review.ars/6

There are many things that are not optimized for multiple cores. However there are many things that are. I'm not going to worry about whether MS Word is optimized for 16 cores, as the processor is really not the bottleneck in these sorts of apps. Most apps that need to be, are.

 

[300D]

TMRaven, clearly you lack understanding of multi-threading and how OSX handles threads.

"Nearly any program ever written for OSX will use all the cores it can."
Simplification of that statement: OSX will split a program's data to be processing across as many of the cores as it has available. If a program has only 1 thread and data that can't be cracked down on the fly, it will only use 1 core. If a program has multiple threads, OSX will automatically balance the load across all the cores to execute as many threads simultaneously as possible.

If you have a process capable of taking 100% of only 1 core, the others don't just stop working. You've got things like drive I/O, memory access, background OS tasks, background applications, etc always using the other cores even if they aren't all being used 100%.

Simple enough?

I'm no developer, but I don't think that's accurate. Running gzip through Cygwin on my Windows PC at work only uses one core.

Thats because code encryption is a linear process, it can't be readily broken down into thread chunks like encoding video.

 

[ibwb]

Thats because code encryption is a linear process, it can't be readily broken down into thread chunks like encoding video.

Actually it's quite easy in principle to break up gzip compression into chunks. If you compressed separate 1MB blocks you would take only a tiny hit to the compression ratio (as each block would need to be a separate session). gzip just isn't designed that way.

 

[kocoman]

Actually it's quite easy in principle to break up gzip compression into chunks. If you compressed separate 1MB blocks you would take only a tiny hit to the compression ratio (as each block would need to be a separate session). gzip just isn't designed that way.

How to read a file in Xcode without reading "all" into memory first?