Intel's Future Chips: News, Rumours & Reviews

[volkgren]

It's an architectural design choice; there is performance loss when you have unused CPU cores, but you gain more performance in tasks that do scale. Hence, "Game Mode".

So they choose to excel in productivity workloads while taking a hit to gaming? That's a choice they made? As in they could have went the other way around and made better gaming CPUs? Or, is that just happened to be where their R&D landed them?

*Because I am somewhat biased against AMD even with the Ryzen CPUs because I mostly game and I continuously see their CPUs with many cores being underutilized AND bottle-necking top-end GPUs. (talking about their mid-range Ryzen 5 mostly)

 

[gamerk316]

It's an architectural design choice; there is performance loss when you have unused CPU cores, but you gain more performance in tasks that do scale. Hence, "Game Mode".

So they choose to excel in productivity workloads while taking a hit to gaming? That's a choice they made? As in they could have went the other way around and made better gaming CPUs? Or, is that just happened to be where their R&D landed them?

*Because I am somewhat biased against AMD even with the Ryzen CPUs because I mostly game and I continuously see their CPUs with many cores being underutilized AND bottle-necking top-end GPUs. (talking about their mid-range Ryzen 5 mostly)

The problem is there is a performance cost to having a CPU core that is not used. And it gets worse as you increase core count. So for tasks that scale, you want as many CPU cores as possible. For tasks that don't, you want as few as possible.

 

[-Fran-]

It's an architectural design choice; there is performance loss when you have unused CPU cores, but you gain more performance in tasks that do scale. Hence, "Game Mode".

So they choose to excel in productivity workloads while taking a hit to gaming? That's a choice they made? As in they could have went the other way around and made better gaming CPUs? Or, is that just happened to be where their R&D landed them?

*Because I am somewhat biased against AMD even with the Ryzen CPUs because I mostly game and I continuously see their CPUs with many cores being underutilized AND bottle-necking top-end GPUs. (talking about their mid-range Ryzen 5 mostly)

The problem is there is a performance cost to having a CPU core that is not used. And it gets worse as you increase core count. So for tasks that scale, you want as many CPU cores as possible. For tasks that don't, you want as few as possible.

That's where Turbo implementations come into play.

The only thing kind of annoying is the CCX bouncing, but Intel will get the same problem now that they're moving into a more complex mesh.

Cheers!

 

[volkgren]

Which gen of Intel's will have the same problem? 8/9th-gen or the next die shrink?

 

[jimmysmitty]

Which gen of Intel's will have the same problem? 8/9th-gen or the next die shrink?

LGA 2011 went from a ring bus to a mesh for inter-core communication. It shows as there were a few tasks that the current LGA2011 CPUs were slightly behind last gen LGA2011 CPUs.

I haven't seen any news on them moving to that for their mainstream yet though as this design was meant for higher core counts.

@Yuka, I don't know if they will run into the same issues though as Intels design is still different enough. We will have to wait and see.

 

[-Fran-]

Intel won't run into the same exact issues, but increasing the core count doubles down on your interconnection mechanism. There's no free lunch here, so Intel better flesh out their mesh topology. AMD has made a very good job at making IF quite good: cheap to implement/expand and decently to escale up (or so I've read).

In fact, you can see how Intel fares now under heavy switching: piss poor. When you're running a lot of apps in parallel (not the same app threaded) and they start cracking up, that is when you KNOW the underlying topology isn't good enough. Check the Streaming tests Toms did not long ago. They show the Achilles heel of Intel. If they i9/7 9K CPUs don't go away from Ring, they'll have hiccups. Noticeable hiccups.

Cheers!

EDIT: Typo.

 

[gamerk316]

Intel won't run into the same exact issues, but increasing the core count doubles down on your interconnection mechanism. There's no free lunch here, so Intel better flesh out their mesh topology. AMD has made a very good job at making IF quite good: cheap to implement/expand and decently to escale up (or so I've read).

In fact, you can see how Intel fares now under heavy switching: piss poor. When you're running a lot of apps in parallel (not the same app threaded) and they start cracking up, that is when you KNOW the underlying topology isn't good enough. Check the Streaming tests Toms did not long ago. They show the Achilles heel of Intel. If they i9/7 9K CPUs don't go away from Ring, they'll have hiccups. Noticeable hiccups.

Cheers!

EDIT: Typo.

I don't think the mesh is the root problem; while slower then a Ring bus for a few cores, it should be consistent as core counts go up. I think Intel is getting screwed by threads jumping between cores, since that behavior makes the CPU very cache/memory limited. I suspect that's where Intel is loosing the most performance.

 

[-Fran-]

I don't think the mesh is the root problem; while slower then a Ring bus for a few cores, it should be consistent as core counts go up. I think Intel is getting screwed by threads jumping between cores, since that behavior makes the CPU very cache/memory limited. I suspect that's where Intel is loosing the most performance.

Yeah, that was the implied context: thread bouncing. You have to move a lot of stuff nowadays to make processes be able to use another core, so thread bouncing is going to be come a hot topic, I think.

Anyway, core-parking (and affinity) help alleviate this when you know your programs. The rule of thumb is: stay away from 0 and park in adjacent cores. That is, if the program doesn't escale all the way to max-core count, of course.

I really wish Toms did some sort of sub-test of the whole Streaming article when testing the i7/i9 siblings. Maybe add some Discord, AV and some other "normal" tasks into the mix as I usually ask for? I have to say, 90% of people now games with Crome open in the background! Haha.

Cheers!

 

[gamerk316]

I don't think the mesh is the root problem; while slower then a Ring bus for a few cores, it should be consistent as core counts go up. I think Intel is getting screwed by threads jumping between cores, since that behavior makes the CPU very cache/memory limited. I suspect that's where Intel is loosing the most performance.

Yeah, that was the implied context: thread bouncing. You have to move a lot of stuff nowadays to make processes be able to use another core, so thread bouncing is going to be come a hot topic, I think.

Anyway, core-parking (and affinity) help alleviate this when you know your programs. The rule of thumb is: stay away from 0 and park in adjacent cores. That is, if the program doesn't escale all the way to max-core count, of course.

I really wish Toms did some sort of sub-test of the whole Streaming article when testing the i7/i9 siblings. Maybe add some Discord, AV and some other "normal" tasks into the mix as I usually ask for? I have to say, 90% of people now games with Crome open in the background! Haha.

Cheers!

Be very careful about locking threads to cores; 99% of the time you suffer unintended performance loss when the system decides to use that core anyway (which you can't really stop; Windows's kernel threads preempt everything).

Linux is more "predictable" in this regard, given they use thread pools, but at the cost of absolute maximum thread uptime.

The real underlying problem is that on a multitasking OS, your game will never be the only thing running. From a thread scheduling perspective, the ideal architecture would be a gaming console, where you have a very slim OS and very predictable thread scheduling.

 

[-Fran-]

Be very careful about locking threads to cores; 99% of the time you suffer unintended performance loss when the system decides to use that core anyway (which you can't really stop; Windows's kernel threads preempt everything).

Linux is more "predictable" in this regard, given they use thread pools, but at the cost of absolute maximum thread uptime.

The real underlying problem is that on a multitasking OS, your game will never be the only thing running. From a thread scheduling perspective, the ideal architecture would be a gaming console, where you have a very slim OS and very predictable thread scheduling.

Well, I've never considered thread "parking" to imply "locking" (as in the common understanding of "hogging" a core for itself). You can still have the OS overruling/dictating the CPU time slices as per usual, but the further away you're from 0, the best chances for that core to be "for yourself", sort of speaking.

Predictability is an interesting topic as well. I do believe that having more cores allow you to be lenient with "predictability", since you, explicitly, have more resources at your disposal and can just spread tasks across. The devil is always in the details, so the obvious counter argument is "ok, how good of an assumption it is to just even loads across?". Even more, how can you even design the scheduler around a fat assumption like that, haha. Can you have 2 flavors of a kernel for this? Given the age we're living, I'm pretty damn sure you can so you tweak the scheduler to fit the underlying core-count and architecture. Something Microsoft is kind of lazy in doing, with good reason, I guess.

Cheers!

 

[gamerk316]

Be very careful about locking threads to cores; 99% of the time you suffer unintended performance loss when the system decides to use that core anyway (which you can't really stop; Windows's kernel threads preempt everything).

Linux is more "predictable" in this regard, given they use thread pools, but at the cost of absolute maximum thread uptime.

The real underlying problem is that on a multitasking OS, your game will never be the only thing running. From a thread scheduling perspective, the ideal architecture would be a gaming console, where you have a very slim OS and very predictable thread scheduling.

Well, I've never considered thread "parking" to imply "locking" (as in the common understanding of "hogging" a core for itself). You can still have the OS overruling/dictating the CPU time slices as per usual, but the further away you're from 0, the best chances for that core to be "for yourself", sort of speaking.

Predictability is an interesting topic as well. I do believe that having more cores allow you to be lenient with "predictability", since you, explicitly, have more resources at your disposal and can just spread tasks across. The devil is always in the details, so the obvious counter argument is "ok, how good of an assumption it is to just even loads across?". Even more, how can you even design the scheduler around a fat assumption like that, haha. Can you have 2 flavors of a kernel for this? Given the age we're living, I'm pretty damn sure you can so you tweak the scheduler to fit the underlying core-count and architecture. Something Microsoft is kind of lazy in doing, with good reason, I guess.

Cheers!

Once upon a time, staying away from the first core was a good idea. Schedulers nowadays really don't care though; unless a thread is specifically coded to run on the first core, it will go wherever the OS scheduler decides it needs to go.

The Windows scheduler is designed around maximum thread uptime. This comes at the cost of latency and being much harder on the cache/memory systems. There's nothing *wrong* with the design, but it starts to run into issues when the number of threads that want to run for extended periods of time exceed the number of CPU cores available. Linux handles this cleaner (threads get assigned to cores and mostly stick there unless the workload significantly changes), but when you have multiple threads assigned to a core they will be forced to timeshare, reducing performance if the workload between them isn't roughly the same.

 

[gamerk316]

Well now:

https://www.hardocp.com/news/2018/10/18/intel_to_split_manufacturing_branch_into_three_divisions/
https://www.oregonlive.com/silicon-forest/index.ssf/2018/10/intel_manufacturing_vp_sohail.html

Intel will split its vaunted manufacturing unit into three pieces, the company told employees Monday. And Sohail Ahmed, who has jointly led the manufacturing organization since 2016, will retire next month.

...

With Ahmed's departure, Intel plans to break its technology and manufacturing group into three segments:

Technology development, led by Mike Mayberry, a Hillsboro executive who serves as Intel's chief technology officer and head of Intel labs. Rich Uhlig will run Intel Labs on an interim basis as Mayberry takes on his new role.
Manufacturing and operations, led by Ann Kelleher, another Hillsboro executive who had been running the technology and manufacturing group with Ahmed.
Supply chain, to be run by Randhir Thakur.
They're all under the direction of Venkata "Murthy" Renduchintala, whom Intel hired away from Qualcomm in 2015. He is now president of several Intel businesses, including manufacturing, and the company's chief engineering officer.

Intel declined to elaborate on the changes.

 

[Peter Martin]

I predict their non-volatile 3dxpoint memory to become system ram at some point, enabling pcs to run, power off, back on and continue without a hiccup

 

[jimmysmitty]

I predict their non-volatile 3dxpoint memory to become system ram at some point, enabling pcs to run, power off, back on and continue without a hiccup

Pretty sure thats everyones prediction especially since they can have 512GB DIMMs vs 32GB DIMMs. Its not as fast as current DDR4 but I would trade off a slight performance decrease for a vastly better storage performance increase.

 

[Isaiah4110]

Think about the potential security issues that brings to the table though...

 

[Peter Martin]

I predict their non-volatile 3dxpoint memory to become system ram at some point, enabling pcs to run, power off, back on and continue without a hiccup

Pretty sure thats everyones prediction especially since they can have 512GB DIMMs vs 32GB DIMMs. Its not as fast as current DDR4 but I would trade off a slight performance decrease for a vastly better storage performance increase.

oh, they will solve the speed issues. I would accept the tradeoff too.

 

[gamerk316]

I predict their non-volatile 3dxpoint memory to become system ram at some point, enabling pcs to run, power off, back on and continue without a hiccup

Pretty sure thats everyones prediction especially since they can have 512GB DIMMs vs 32GB DIMMs. Its not as fast as current DDR4 but I would trade off a slight performance decrease for a vastly better storage performance increase.

oh, they will solve the speed issues. I would accept the tradeoff too.

Don't forget that CPUs care more about memory latency then memory bandwidth, and that's where persistent memories like 3dxpoint are vastly inferior to what we have now.

 

[8350rocks]

I predict their non-volatile 3dxpoint memory to become system ram at some point, enabling pcs to run, power off, back on and continue without a hiccup

Pretty sure thats everyones prediction especially since they can have 512GB DIMMs vs 32GB DIMMs. Its not as fast as current DDR4 but I would trade off a slight performance decrease for a vastly better storage performance increase.

oh, they will solve the speed issues. I would accept the tradeoff too.

Don't forget that CPUs care more about memory latency then memory bandwidth, and that's where persistent memories like 3dxpoint are vastly inferior to what we have now.

That is also why so many things invented to replace RAM end up relegated to specialty tasks.

 

[-Fran-]

You could make the argument that when you go wider, you might start moving the bottleneck back to bandwidth (see GPUs).

That could also explain the long term thinking behind HBM. It kind of provides both.

Cheers!

 

[goldstone77]

Intel kills off the 10nm process
This is actually a good thing for the company
Oct 22, 2018 by Charlie Demerjian

SemiAccurate has learned that Intel just pulled the plug on their struggling 10nm process. Before you jump to conclusions, we think this is both the right thing to do and a good thing for the company.

https://semiaccurate.com/2018/10/22/intel-kills-off-the-10nm-process/

 

[aldaia]

I was about to post the same but you posted it earlier ;-)
As Charlie himself says "this is a big bombshell".

Wondering about the consequences.

Edit:
This news from a few days ago are in line with the rumor.
Amid 10nm Delays, Intel to Break Manufacturing Group Into Three
https://www.tomshardware.co.uk/intel-10nm-delays-manufacturing-group,news-59304.html

 

[jimmysmitty]

I was about to post the same but you posted it earlier ;-)
As Charlie himself says "this is a big bombshell".

Wondering about the consequences.

Edit:
This news from a few days ago are in line with the rumor.
Amid 10nm Delays, Intel to Break Manufacturing Group Into Three
https://www.tomshardware.co.uk/intel-10nm-delays-manufacturing-group,news-59304.html

Not sure breaking the manufacturing group up confirms a rumor of them killing the 10nm off. However I do know the work being done at FAB 42 is mainly for 7nm and it will no longer be a 10nm FAB. However that was known quite a while ago.

Guess we still have to wait and see what happens.

Charlie is a bit arrogant though. He acts like Intel made bad decisions but in my eyes any company who invests as much as they do into a technology has to give it every last go they can to make it work. If they are killing 10nm then even without the additional time it has taken it would have been a very expensive science experiment.

 

[ganron]

Intel Tweet:

https://twitter.com/intelnews/status/1054397715071651841
"
Media reports published today that Intel is ending work on the 10nm process are untrue. We are making good progress on 10nm. Yields are improving consistent with the timeline we shared during our last earnings report.


ITS FAKE NEWS !!

 

[jimmysmitty]

Intel Tweet:

https://twitter.com/intelnews/status/1054397715071651841
"
Media reports published today that Intel is ending work on the 10nm process are untrue. We are making good progress on 10nm. Yields are improving consistent with the timeline we shared during our last earnings report.


ITS FAKE NEWS !!

And this is why I don't trust Charlie.

 

[goldstone77]

Intel splits up manufacturing group amid production delays
Updated Oct 18; Posted Oct 17

Intel will split its vaunted manufacturing unit into three pieces, the company told employees Monday. And Sohail Ahmed, who has jointly led the manufacturing organization since 2016, will retire next month.

With Ahmed's departure, Intel plans to break its technology and manufacturing group into three segments:

• 
  Technology development, led by Mike Mayberry, a Hillsboro executive who serves as Intel's chief technology officer and head of Intel labs. Rich Uhlig will run Intel Labs on an interim basis as Mayberry takes on his new role.
  Manufacturing and operations, led by Ann Kelleher, another Hillsboro executive who had been running the technology and manufacturing group with Ahmed.
  Supply chain, to be run by Randhir Thakur.
  They're all under the direction of Venkata "Murthy" Renduchintala, whom Intel hired away from Qualcomm in 2015. He is now president of several Intel businesses, including manufacturing, and the company's chief engineering officer.

Intel declined to elaborate on the change

He joined Intel in 1984 and works in Hillsboro, where he and Kelleher have run the manufacturing group since 2016.

Retirement "was not an easy decision, but there is never a perfect time to make a change," Ahmed, 60, wrote in a note to colleagues. "It has been a wonderful, exciting and rewarding career for me, far more than I could have ever imagined. I had so much fun and would not trade it for anything else in the world!"

"Thanks to the efforts of Sohail and the entire Intel team, we are making good progress on 10nm," Renduchintala wrote to employees Monday. "Yields are improving consistent with the timeline that we shared in April, and we continue to expect systems on shelves for the 2019 holiday season."

Intel has been without a chief executive since June, when Brian Krzanich abruptly resigned after the company uncovered "a past consensual relationship with an Intel employee" in violation of corporate policy. Chief Financial Officer Bob Swan is serving as interim CEO.

https://www.oregonlive.com/silicon-forest/index.ssf/2018/10/intel_manufacturing_vp_sohail.html

There are conflicting reports. CD says they canceled 10nm, that could be the original 10nm as in Cannon Lake. The "new" 10nm(12nm) with relaxed specs could still be alive and well. Also, looking at these report this could mean Intel might have a new CEO. "Venkata "Murthy" Renduchintala" could be that new CEO.