Intel announces multi-core enhancements for Haswell chips

[ixfd64]

I wonder if this will benefit Prime95 in any way?

http://www.extremetech.com/computing...e-enhancements

[Dubslow]

This could only ever be possibly useful for multithreaded tests (of which there are admittedly a lot, especially for hyperthreaded users). Even then, it would only be useful if George hasn't already optimized the multithreaded FFTs to the point where each thread will never have conflicts with the others. The steps Prime95 executes to test numbers are much more well defined, than, say, modifying an Excel spreadsheet based on what's happening in real life. That is to say, it would be easier with FFTs to know exactly when each thread will need to access what data and for how long, than for almost any other program out there. If George has put the time to do this, then it will be of little use I think. Even if he hasn't, TSX's use would still be fairly limited. In general though, I think this is really cool.

(Does this sound totally wrong to anybody? I wouldn't call this anything more than an educated guess.)

[bsquared]

Originally Posted by Dubslow

(Does this sound totally wrong to anybody? I wouldn't call this anything more than an educated guess.)

I would say that the answer is complicated, and depends on how tighly coupled a parallel algorithm is (defined as how often threads need to share data) and to what degree the data sharing problem is bottlenecked by the threading overhead, and not, for example, by raw data movement.

I think the more tightly coupled a parallel algorithm is, the more it could possibly benefit from this new approach, assuming the data to be shared is readily available to the processors.

That said, I think the multitheading of FFT's is bottlenecked by raw data movement, not by threading overhead, and I don't know if any amount of "free" improvements in the granularity of data sharing will be a win. The processors will be waiting for the bus to deliver the data anyway. (disclaimer: I have not written a multi-threaded FFT, so I may have missed something.)

For something like multithreaded SIQS or NFS, where the parallelism is very loosely coupled, this new approach would likely be useless.

Maybe things get interesting for parallel block Lanczos...

In any event, the usefullness is limited by the willingness of folks who have already invested a great deal of time developing a parallel solution with available tools, to reinvest that time in this new set of tools.

[Christenson]

Uhh, I think this one is squarely aimed at database access...with lots of sparse random writes of whole records, this is an excellent tool -- TSX makes the record locks and transactions a lot simpler.

Block Lanczos, possibly not..but sieving, now, there's something useful...noticeably reduces average synchronisation overhead....just set the bits in your sieve, be prepared to lose a write here and there and re-do it.

History says that Jasonp and the like will find a way to take advantage.

[bsquared]

Originally Posted by Christenson

Uhh, I think this one is squarely aimed at database access...with lots of sparse random writes of whole records, this is an excellent tool -- TSX makes the record locks and transactions a lot simpler.

Agreed, from what I've seen (which isn't much), it might help there.

Originally Posted by Christenson

Block Lanczos, possibly not..but sieving, now, there's something useful...noticeably reduces average synchronisation overhead....just set the bits in your sieve, be prepared to lose a write here and there and re-do it.

History says that Jasonp and the like will find a way to take advantage.

Using multiple threads to write simultaneously to the same sieve block would be crazy. There is no earthly reason why you would need to share data to that resolution when sieving with multiple threads. I don't care how low overhead TSX is, it can't be less overhead than 0.

[ldesnogu]

Originally Posted by Christenson

but sieving, now, there's something useful...noticeably reduces average synchronisation overhead....just set the bits in your sieve, be prepared to lose a write here and there and re-do it.

As bsquared already pointed that'd be a very poor use case. No matter what their technology does, you'd have to move cache lines from CPU to CPU, and you simply don't want that to happen

[Christenson]

True, those cache lines have to move from time to time in a sieve...but this allows only the NECESSARY cache lines to move...no substitute for a good hand-optimisation of a mathematical operation, but definitely useful for a database taking random hits.

[ldesnogu]

Originally Posted by Christenson

True, those cache lines have to move from time to time in a sieve...but this allows only the NECESSARY cache lines to move...

There's no need for transactional memory for that: the MESI (or MOESI) protocol takes care of moving and sharing cache lines that are in a shared memory area depending on what each CPU does. Necessary is a bit abusive in that case: the cache lines that move have to move, or correctness is lost.

As far as sieving goes, the only way I can think of to efficiently use multi CPU would be to sieve non-overlapping segments. Probably some lack of imagination

[firejuggler]

haswell to be launched march-june 2013