Is Haswell the new i8 or still i7 is in the name.

[grkM3]

HP is already advertising the the ivy bridge as gen 3 so I dont see why haswell will not be gen 4.

its I3,5,7 and kinda like the BMWs with 3 5 and 7 series and people have got used to low,mid and high end calling by now and would be dumb for intel to mess that up.

I think intel messed up a little along the way also.It should of been like this.

Nehalem gen 1
lynnfield,bloomfield,clarksfield


Westmere gen 2
gulftown,arrandale

Sandybridge gen 3
sandy and sandy E

Ivybridge gen 4
Ivy and Ivy E ?

Haswell gen 5

 

[cmdrdredd]

The only thing that makes me sad is things haven't caught up really well with the CPUs. Still too many single threaded apps, not enough multi-core aware stuff going on which means we are running quads instead of 6 or 8 core CPUs. I know there are 6 core consumer level CPUs but they don't necessarily bring the added performance aside from specific apps (mostly professional ones).

I'd like to see more usage of more cores with more apps, but it'll probably be a long long time. I don't care what they call it either.

 

[ShintaiDK]

The only thing that makes me sad is things haven't caught up really well with the CPUs. Still too many single threaded apps, not enough multi-core aware stuff going on which means we are running quads instead of 6 or 8 core CPUs. I know there are 6 core consumer level CPUs but they don't necessarily bring the added performance aside from specific apps (mostly professional ones).

I'd like to see more usage of more cores with more apps, but it'll probably be a long long time. I don't care what they call it either.

You just cant make something multithreaded because you want so. Alot of code simply cant be multithreaded at all.

Alot of servercode aint actually multithreaded either. They simply benefit from the concurrent users.

 

[Interitus]

Won't be i8, that is an even number. Has to be either i7 or i9. History says it will be an i7 and the first digit of the processor number will be incremented from a 3 to a 4.

2700k -> 3770k -> 4840k (all i7)

2500k -> 3570k -> 4640k (all i5)

Just add 1070 till it's ...

More than 9000?

 

[cmdrdredd]

You just cant make something multithreaded because you want so. Alot of code simply cant be multithreaded at all.

Alot of servercode aint actually multithreaded either. They simply benefit from the concurrent users.

Yeah I know. I had thought a few years ago that things would catch up a little bit. Software seems limited like you said.

 

[ShintaiDK]

Yeah I know. I had thought a few years ago that things would catch up a little bit. Software seems limited like you said.

I dont know if you remember the Mitosis project. It sole exsistence shows how little multithreaded code can actually be produced.

Mitosis basicly took singlethreaded code, then spawned x threads that was to calculate on the result of thread 1. If any of them hit correctly you would continue from there. Else you would simply drop all the work and continue from core 0.

But the entire idea behind speculative multithreading was simply horrible resource wise. Imagine 100% load on all 4 cores on a 3570, only to get 5-10% over the singlethreaded performance on 1 core (Without turbomodes.).

Instead we got turbo modes from Intel and AMD. It was a better solution and more consistent. Not to mention alittle bit faster. Turbomodes also work on all software. While Mitosis would require recompile of all software.

Hence why Mitosis died of.

 

[cmdrdredd]

I think I remember something like that. However, I think that if we had say games that loaded a few things to core 1, a few things to core 2 and so on up to whatever cores you had plus HT at full speed on every core (say 4.5Ghz x4 + HT on each core), then you'd be sailing along. It doesn't work that way and I guess just can't...not with the way things work in reality.

Anyway I'm off topic, but I guess my point was I don't care what they call it. I5,I7,I8, Incredible crazy fast CPU # 102...Things need to be made more efficient so that throwing clock speed at it isn't the only solution.

 

[BenchPress]

The only thing that makes me sad is things haven't caught up really well with the CPUs. Still too many single threaded apps, not enough multi-core aware stuff going on which means we are running quads instead of 6 or 8 core CPUs. I know there are 6 core consumer level CPUs but they don't necessarily bring the added performance aside from specific apps (mostly professional ones).

I'd like to see more usage of more cores with more apps, but it'll probably be a long long time. I don't care what they call it either.

This is precisely why Haswell adds revolutionary TSX technology!

It makes it much easier to write robust multi-threaded software that scales well.

 

[BenchPress]

You just cant make something multithreaded because you want so. Alot of code simply cant be multithreaded at all.

That is not correct. There isn't "a lot" of code that can't be multi-threaded.

The problem is that a lot of parallelism is fine-grained. Today's synchronization primitives are not suited for fine-grained locks. They have too much overhead and the more you have the more complex your code becomes.

That's why Haswell's hardware transactional memory makes coarse-grained locks perform like fine-grained ones, without the overhead. It will allow a lot more code to be multi-threaded successfully.

 

[ShintaiDK]

I think you put overly much faith into TSX to put it mildly.

 

[Charles Kozierok]

TSX actually is pretty cool, but it's very specific to certain types of applications and isn't going to address the general problem of efficient parallelism.

 

[BenchPress]

I think you put overly much faith into TSX to put it mildly.

Because... ?

 

[BenchPress]

TSX actually is pretty cool, but it's very specific to certain types of applications and isn't going to address the general problem of efficient parallelism.

Because... ?

 

[ShintaiDK]

Because... ?

Because its not gonna be a magic solution to multithreading as you portrait it.

TSX will mainly benefit already highly threaded shared memory applications.

Intel TSX targets a certain class of shared-memory multi-threaded applications; specifically multi-threaded applications that actively share data. Intel TSX is about allowing programs to achieve fine-grain lock performance without requiring the complexity of reasoning about fine-grain locking.

 

[dave_the_nerd]

A laptop with a 65watt tdp processor :O (G630 is a desktop processor, B940/B950/B960/B970 are laptop sandy bridge pentium processors.)

 

[pelov]

Because its not gonna be a magic solution to multithreading as you portrait it.

Nah-uh! TSX will solve the issue of parallelism once and for all and AVX2 will cure cancer!

TSX has to be programmer specified. Meaning the programmer picks a region of code and then sees whether or not this region benefits from TSX (edit - and as was mentioned the code should share memory). That's kinda cool but it also requires additional work and that's not a good thing.

The issue of parallelism isn't going to be solved until it's done completely passively. Meaning a programmer just programs code and an underlying program automatically picks out code to thread. This can be done at the OS level or at the programmer's desk but that's the ultimate goal. TSX, if I'm understanding it correctly, is just another option to run code through to see whether or not it can benefit from TSX...

 

[BenchPress]

TSX will mainly benefit already highly threaded shared memory applications.

Why?

 

[pelov]

Why?

Because that's what it's called...? Transactional memory synchronization = TSX.

Intel TSX targets a certain class of shared-memory multi-threaded applications; specifically multi-threaded applications that actively share data. Intel TSX is about allowing programs to achieve fine-grain lock performance without requiring the complexity of reasoning about fine-grain locking.

However, if there is high data contention the algorithm would need to change in order to have an opportunity for high scalability. There are no magic bullets that can solve the problem, since true high data contention implies that the algorithm is effectively serialized.

 

[BenchPress]

Because that's what it's called...? Transactional memory synchronization = TSX.

Why does "transactional memory synchronization" prevent it from helping multi-thread software that previously wasn't successfully multi-threadable?

You have no clue what transactional memory synchronization means, do you?

 

[ShintaiDK]

Why?

I wonder why you keep linking to Intels page, if you skipped reading about it yourself.

How about you show where Intel says it will allow for multithreading of singlethreaded code that currently cant be multithreaded?

 

[ShintaiDK]

Nah-uh! TSX will solve the issue of parallelism once and for all and AVX2 will cure cancer!

TSX has to be programmer specified. Meaning the programmer picks a region of code and then sees whether or not this region benefits from TSX (edit - and as was mentioned the code should share memory). That's kinda cool but it also requires additional work and that's not a good thing.

The issue of parallelism isn't going to be solved until it's done completely passively. Meaning a programmer just programs code and an underlying program automatically picks out code to thread. This can be done at the OS level or at the programmer's desk but that's the ultimate goal. TSX, if I'm understanding it correctly, is just another option to run code through to see whether or not it can benefit from TSX...

I think its 2 fold.

First of all we need a new coding language thats better suited for it. This is due to the fact that multithreading coding is complex due to the highly increased debugging complexity. And then there is the development cost that also increases multiple times.

And secondly we(some people) need to accept some code just cant be multithreaded nomatter what we do.

This is also why Intel tried Mitosis. There just aint no way around it.

 

[ninaholic37]

You just cant make something multithreaded because you want so. Alot of code simply cant be multithreaded at all.

Exactly! A lot of code needs to run in sequence, you can't just say let's calculate x*y+z by running x*y and +z in two separate threads. Cooking 9 hamburgers at separate start times can be multi-threaded if you know a space on the grill is available for each, but you can't cook 1 hamburger and eat it at the same time (bad examples maybe, but the point is there's no magical way to "parallize" a lot of things that rely on something else to happen first, which is how a lot of processes need to work).

 

[BenchPress]

Intel TSX targets a certain class of shared-memory multi-threaded applications; specifically multi-threaded applications that actively share data. Intel TSX is about allowing programs to achieve fine-grain lock performance without requiring the complexity of reasoning about fine-grain locking.

Where does it say that it will only help "already highly threaded" software?

Any why are you quoting Intel? I want you to explain why TSX won't be widely applicable. Is it RTM or HLE that is limited?

Or are you just full of it?

 

[Charles Kozierok]

Couple of good articles on the subject...

http://arstechnica.com/business/2012/02/transactional-memory-going-mainstream-with-intel-haswell/

http://realworldtech.com/page.cfm?ArticleID=RWT021512050738

 

[ShintaiDK]

Exactly! A lot of code needs to run in sequence, you can't just say let's calculate x*y+z by running x*y and +z in two separate threads. Cooking 9 hamburgers at separate start times can be multi-threaded if you know a space on the grill is available for each, but you can't cook 1 hamburger and eat it at the same time (bad examples maybe, but the point is there's no magical way to "parallize" a lot of things that rely on something else to happen first, which is how a lot of processes need to work).

Yep, this is basicly why Intel and essentially also AMD wanted to try bruteforce. Speculative threading. Simply having extra threads running with the guesswork of what a result was.

Simplified example you need to solve say 1+1=? and then following that you need ?+3=result. You would run 1+1=? con core 0. And then core 1,2 and 3 would run 0+3, 1+3 and 2+3. After you know the result of core 0 that says its 2. Then you got the result from core 3 for the next task. However its extremely inefficient. And you easily used 400-800% more resources to gain 5-10%.