Core i7-4770K is performance crippled

[BenchPress]

The notion that Java is slow has been like disproved a decade ago. In fact some stuff is faster than in C++ nowadays...so another misguided belief.

In theory, possibly, in practice, not even close. Anyway, let's not stray off-topic. Feel free to open another thread about it if you want to discuss the details.

ReadWriteLock is fine-grained because you can read in parallel. Only writes block. And they also do with TSX.

You've (still) got your definition of fine-grained locking all wrong. It is not a property of the lock implementation. You can have fine-grained locking by putting every other thread to sleep. It would be horribly slow, but it still counts. The real distinction is in how finely or coarsely you share resources between threads. For instance if two threads want to write 10 data structures into a table at specific locations, then coarse-grained locking would lock the entire table and allow one thread to write its 10 elements while the other one has to wait. With fine-grained locking each table entry would be locked individually, and as long as the threads don't try to access the same entry the writes can happen concurrently. But in the case of fine-grained locking there are a lot more locking operations going on, so the overhead of that can outweigh the benefit of concurrent writing.

The great thing about TSX is that developers only have to think in terms of coarse-grained locking, while at the hardware level it behaves as fine-grained locking. Or in other words it's like fine-grained locking but without the typical overhead and without the massive coding complexity of avoiding race conditions.

So no, ReadWriteLock is not fine-grained just because you can read in parallel. And no, TSX in most cases does not block on concurrent writes.

Link to said 10x more powerful implementation with according performance data? or are you again just coming up with random stuff?

You still expect me to help you out when you accuse me of coming up with random stuff? Do your own research. Or keep believing that ReadWriteLock (and Java) is fast. I don't care.

 

[beginner99]

For instance if two threads want to write 10 data structures into a table at specific locations, then coarse-grained locking would lock the entire table and allow one thread to write its 10 elements while the other one has to wait. With fine-grained locking each table entry would be locked individually, and as long as the threads don't try to access the same entry the writes can happen concurrently.

And that has been working liek this for years in most usable RDBMS with MySQL MyISAM being one of the exceptions that still? (don't know) uses full table locks. But the other common RDBMS have had this for years without the need for TSX.

Besides that database is probably the best-case scenario for TSX and you will never run a database were TSX matters on a consumer CPU...I don't claim it has 0 downisde, but it is not crippled. Show me a gaming benchmark were an OC'ed 4770k is slower than a 4770 and I will agree with you. But I doubt very much you will find such a benchmark because games use too few threads to really matter.

The great thing about TSX is that developers only have to think in terms of coarse-grained locking, while at the hardware level it behaves as fine-grained locking. Or in other words it's like fine-grained locking but without the overhead and without the coding complexity.

Agree. But as was said. That's a tool for developers and has nothing to do with performance. It just makes it easier (cheaper) to develop mulch-threaded software that needs to access common data structures.


So no, ReadWriteLock is not fine-grained just because you can read in parallel. And no, TSX in most cases does not block on concurrent writes.

You still expect me to help you out when you accuse me of coming up with random stuff? Do your own research. Or keep believing that ReadWriteLock (and Java) is fast. I don't care.

The C++ vs Java benches are all out there for everyone to see:

http://blog.cfelde.com/2010/06/c-vs-java-performance/

Interesting thing is that when java is faster it's by landslide not just a bit faster. I on the other hand have not shown a single benchmark proofing any of your claims.

 

[Aikouka]

Beware! All of the K-model Haswell CPUs deliberately lack an important performance feature for multi-threading: TSX. Therefore the 'flagship' i7-4770K may actually be slower than the i7-4770, even when overclocked. D:

What is up with this terrible fear-mongering? People like you and Galego specifically write your post with generic remarks that do nothing but paint half-truths specifically to rile people up with nothing but FUD. TSX may be important in some aspects of computing, but I highly doubt that most users will even care about it.

As for why it (and the other business-oriented features) isn't in the K-series? Most likely to push enterprise users toward Xeons. TSX isn't the first feature to be cut out of the K-series.

 

[24601]

The C++ vs Java benches are all out there for everyone to see:

http://blog.cfelde.com/2010/06/c-vs-java-performance/

Interesting thing is that when java is faster it's by landslide not just a bit faster. I on the other hand have not shown a single benchmark proofing any of your claims.

http://bruscy.republika.pl/pages/przemek/java_not_really_faster_than_cpp.html

Welcome to my block list.

5 kB programs are the best.

Lets ignore that Java's problems have always largely focused on the fact that their memory management is and always has been a joke.

 

[BenchPress]

Besides that database is probably the best-case scenario for TSX and you will never run a database were TSX matters on a consumer CPU...

Databases are just a highly generalized way of storing and retrieving data. That doesn't mean that applications which don't use a database are not storing and retrieving data! Any of the standard container classes is a specialized data storage structure, and accessing that data concurrently from multiple threads is just as amenable to being optimized with TSX as generic database accesses are.

 

[BenchPress]

What is up with this terrible fear-mongering? People like you and Galego specifically write your post with generic remarks that do nothing but paint half-truths specifically to rile people up with nothing but FUD. TSX may be important in some aspects of computing, but I highly doubt that most users will even care about it.

"Most users" don't care about overclocking either. So let's be clear here, people who are choosing between an i7-4770K or a i7-4770, care a lot about performance and use cutting-edge software that uses/will use the latest CPU features. Deliberately disabling a performance feature from an enthusiast CPU and asking more money for it is a major issue within this context.

 

[grimpr]

"Most users" don't care about overclocking either. So let's be clear here, people who are choosing between an i7-4770K or a i7-4770, care a lot about performance and use cutting-edge software that uses/will use the latest CPU features. Deliberately disabling a performance feature from an enthusiast CPU and asking more money for it is a major issue within this context.

100% agree on this. As you already said and i fully agree that TSX is an important "feature" of the cpu along with Hyperthreading, moreso than HT imho when it hits the next linux kernel, windows 8.1m compilers,apis and libraries. I refuse to buy or recommend a Haswell Intel cpu without TSX, unlocked chips are crippled and not worth their money.

 

[WhoBeDaPlaya]

Interesting : http://www.pcpro.co.uk/news/382267/intel-haswell-hotter-and-slower-than-expected

"Retail versions of Intel Haswell processors are hotter and more power-hungry than pre-production chips, and can’t be overclocked to the same speeds"

 

[Kallogan]

Interesting : http://www.pcpro.co.uk/news/382267/intel-haswell-hotter-and-slower-than-expected

"Retail versions of Intel Haswell processors are hotter and more power-hungry than pre-production chips, and can’t be overclocked to the same speeds"

Scam. Conspiracy. We're being played.

 

[BallaTheFeared]

Anyone else reminded of the DRM fear mongering during the SB release?

 

[Shmee]

Wow, what a sorry state of things this is. Well, you can always lobby for more government regulation on behalf of the consumer...But I don't think that will happen soon, things will get worse before they get better.

Anyways, here is for hoping to AMD subsidies. We need more competition, that is the problem. I know this isn't P&N, but this is just one example of how "greedy PURE capitalists" can be so bad, at least for the consumer. And that is what matters, right?

 

[bronxzv]

Interesting : http://www.pcpro.co.uk/news/382267/intel-haswell-hotter-and-slower-than-expected

"Retail versions of Intel Haswell processors are hotter and more power-hungry than pre-production chips, and can’t be overclocked to the same speeds"

wow, it looks like I was wise to order my system with an H110 cooler, just to run it at stock frequency

 

[ShintaiDK]

wow, it looks like I was wise to order my system with an H110 cooler, just to run it at stock frequency

I run mine at stock with stock cooler. Its alittle cooler than my IB setup was. Even at Linpack.

 

[beginner99]

Databases are just a highly generalized way of storing and retrieving data. That doesn't mean that applications which don't use a database are not storing and retrieving data! Any of the standard container classes is a specialized data storage structure, and accessing that data concurrently from multiple threads is just as amenable to being optimized with TSX as generic database accesses are.

And now please name a common consumer application that does this and doesn't run properly on a CPU without TSX?

 

[beginner99]

"Deliberately disabling a performance feature from an enthusiast CPU and asking more money for it is a major issue within this context.

Agree with that but that does not "cripple" it.

 

[beginner99]

http://bruscy.republika.pl/pages/przemek/java_not_really_faster_than_cpp.html

Welcome to my block list.

5 kB programs are the best.

Lets ignore that Java's problems have always largely focused on the fact that their memory management is and always has been a joke.

So he spent probably several days optimizing c++ code and compiler options and now it's faster? The author of that test says himself:

It's easier to create faster Java code.

 

[NTMBK]

I run mine at stock with stock cooler. Its alittle cooler than my IB setup was. Even at Linpack.

Interesting. I wonder if that is because your part isn't hyperthreaded? Given that HW has more execution ports, I could imagine that the hyperthreads get more resources to use and hence cause a larger increase in power consumption.

 

[bronxzv]

I run mine at stock with stock cooler. Its alittle cooler than my IB setup was. Even at Linpack.

I'll see what I experience with mine, I should have it next Saturday

maybe there is more variation between chips than with Ivy ?

 

[blackened23]

"Most users" don't care about overclocking either. So let's be clear here, people who are choosing between an i7-4770K or a i7-4770, care a lot about performance and use cutting-edge software that uses/will use the latest CPU features. Deliberately disabling a performance feature from an enthusiast CPU and asking more money for it is a major issue within this context.

....and you still have not produced any quantifiable benchmarks showing any such benefits of TSX. Still fear mongering about a feature that no software uses, and one which is supposedly only benefit programmers with minimal performance benefit.

 

[ShintaiDK]

I'll see what I experience with mine, I should have it next Saturday

maybe there is more variation between chips than with Ivy ?

I think its the same. People just got more focus on it. Its not like we didnt have hot chips in the past.

The cooler is exactly the same as with IB btw.

 

[BenchPress]

And now please name a common consumer application that does this and doesn't run properly on a CPU without TSX?

It's not about not running "properly". TSX is roughly comparable to Hyper-Threading in usefullness. Applications do run properly on a CPU without HT, but not optimally. Likewise without TSX applications won't run any worse than they did before, but they won't run any faster.

 

[Idontcare]

....and you still have not produced any quantifiable benchmarks showing any such benefits of TSX. Still fear mongering about a feature that no software uses, and one which is supposedly only benefit programmers with minimal performance benefit.

TSX could be as worthless as tits on a boar, but the fact remains that Intel does not think so (otherwise it wouldn't be included on any SKUs).

But at the same time Intel does not want it enabled on a K-class processor...which does make the K-class processor less feature-rich compared to its non-K sibling.

IMO Intel is at fault for marketing the 4770K as being a multiplier unlocked version of the 4770 (non-K) because that really isn't the case.

The 4770 should be numbered as a 4760 or 4780 to further distinguish the fact that the unlocked multiplier (as denoted by the presence of absence of the "K") is not the only differentiating feature between the two SKUs.

No matter how little or much value TSX adds to the equation, it apparently adds enough value as to motivate Intel to bother with leveraging the feature as being a key differentiating feature between the K and non-K SKUs.

 

[blackened23]

True, but I do think it's too early to proclaim that the 4770k is "performance crippled" due to the lack of TSX - the fact of the matter is, it's a mostly unknown variable since nothing uses it as of yet. I'm just taking a wild guess here, but since we know that AVX instructions increase the variable voltage of Haswell, perhaps TSX is similar in that respect? Adding a feature that can exacerbate any potential thermal issues wouldn't be desirable - That's the only possible reason I can think of for the removal, just a wild guess. In any case, TSX is an unknown variable so to claim that the 4770k is "crippled" is a complete exaggeration.

 

[BenchPress]

"Deliberately disabling a performance feature from an enthusiast CPU and asking more money for it is a major issue within this context.

Agree with that but that does not "cripple" it.

Oh so you agree it's a major issue but now we're down to the semantics of "cripple"?

I'm open for suggestions, but keep in mind that Intel deliberately disables a performance feature. They fuse it out. Kill it off in all K models. Then they ask money for it!

I think crippling is a pretty good description of what they're doing to the 4770K.

 

[Gryz]

People are looking at TSX the wrong way around.
You're looking at how TSX can speed up existing applications that are multi-threaded. I don't think that is where the benefit is at all.

TSX makes it easier to write parallel code. But it has to be included in the overall design of the software. From the start of the design process.

Right now, writing parallel code is not easy. The compiler can't do it for you. A big design decision is: will we use coarse-grain locks, or fine-grain locks ?

Coarse-grain locks are simpler. E.g. you lock a whole datastructure (like a tree) when you want to update it. That means while you do that, no other thread can read or access it. They are all waiting. Imagine what this does to packet forwarding when another thread is updating the routing table. But the benefit of coarse-gain locks is: it's simpler. Less opportunity for the programmers to make mistakes (e.g. deadlock).

Fine-grained locks allow for much faster execution. Because the chances are much smaller that 2 or more threads access the same data at the same time. So threads can keep running, with hardly any waiting for locks. But there is a huge downside: fine-grained locks are much harder to do right. You have to keep track of many more locks. And thus of many more potential situations where things can go wrong (e.g. deadlock). It's trickier for the programmers.

TSX makes it (a lot) easier to do fine-grained locks.
Therefor, it should encourage programmers to make more use of fine-grained locks.
This will cause multi-threaded applications to make better use of more cores on average.

But until programmers start doing this, we won't see much speedup of existing software. Not even existing software that had only a few quick changes to existing code to use TSX. The real benefit shows up when you decide to use TSX at the start of your software's design process.

Therefor I find it unbelievable that Intel did not include TSX in all their CPUs ? TSX will only be useful if programmers use it in the skeletal of their design. And you can't use it in the overall design, unless you know all hardware will have support for TSX. Otherwise you have to make 2 separate designs for your software.

Imho, big-time TSX acceptance/usage was going to be delayed until AMD would also support it. Now it's gonna be delayed another extra 1-2 years.

Weird.