Why doesn't everyone make bigger cores?

Memory on phones can't keep up, we're lacking bandiwidth

>>57190557
turns out fabricating silicone costs money

>>57190557
because 4 A53 is cheaper than a single hurricane and also faster when utilized.

>>57190717
>silicone
Kek'd.

>higher costs
>diminishing returns on performance due to timing and power limits
>a lot of CPU optimization is just making caching really efficient

>what is TDP?

>>57191892

>bigger cores usually mean wider, meaning smaller clocks and less voltage.

You do realise that as most cpu architectures have gotten smaller voltage required has also decreased right?

I mean an 8350 is huge compared to a 6700k so it must use less voltage right?

What stops companies from making CPUs with tens of small cores instead of a few big ones? Wouldn't a CPU with, say, 64 tiny cores and 64 threads be better than what we have now? Or are software developers unable of creating programs that can utilize so many cores?

Yes I have no actual knowledge about computer hardware

>>57190557
Clearly you understand nothing about computers.

>>57192019
some tasks don't scale well with increased core count

plus you need to spend extra time to make sure all cores are used well (e.g. see supercomputers)

>>57192019
You have just described GPUs.

>>57192019
More cores only helps with tasks that aren't sequential. Pretty much, if it has to be done in order, more cores won't help, you'll just need faster cores.

More things could be made multithreaded though. A lot of devs ignore that.

>>57190717
i get all of my silicone from bad dragon

>>57192071
because multi-threaded programming is a literal bitch

>>57192019
>Or are software developers unable of creating programs that can utilize so many cores?
yes, they are.

>>57192019
>Or are software developers unable of creating programs that can utilize so many cores?
It depends on the kind of application. If you're doing a program that heavily interacts with a driver, like OpenGL, there's often no way you can do it with more than one core.

In some things, like make, it's trivial to just split tasks between cores and it will scale performance almost linearly in some cases. It wouldn't be worth the loss of single threaded performance to be better in those few cases though.

>>57192019

>[suggestion]
>"Yes I have no actual knowledge about computer hardware"

80% of posts in this board in a nutshell. If you, outside the industry have to ask yourself "Why aren't X doing Y?", then there's a very good fucking reason.

You all should watch some Grace Hopper interviews where she pulls out her nanoseconds.

>>57190557
Cortex-A72 is outperforming Kryo despite being much smaller.

Qualcomm is underclocking Snapdragon 652 because they're embarrassed how shitty Kryo performs compared to A72s inside SD 652.

The performance superiority of Cortex-A72 is why Huawei's high-end line-up, which uses A72 cores instead of custom cores like Kryo, is at the top of the Android performance charts right now.

>>57194113
Then how is power consumption? If the A72 is faster it might also consume more power.

>>57190557
They are, but they dedicated most of the die space for SHA1 fixed function units. Now that Geekbench 4 has come out and removed those SHA1 benchmarks, they'll have to find other things to cheat or go back to smaller dies.

>>57190557
distance = cache latency

speed of light is a bottleneck

>>57194473
>distance = cache latency
>speed of light is a bottleneck
light travels 10 cm in a single 3 Ghz Cycle. Big issue for longer connections like sata2, pcie, usb3, etc.
To my knowledge gate switching delays are a significant form of delay in CPUs
http://yarchive.net/comp/cmos_logic_speed.html

>>57194705
So when can we expect performance critical parts of the CPU to use optical transistors?

>>57194705
are you using vacuum c for silicon?

>>57195874
yes i was using speed of light in a vacuum. Does it matter? What governs the speed at which an electrical pulse propogates?

>>57190717
>fabricating silicone
isn't silicon basically sand?

File: e5_epiphany-1024x569.png (320KB, 1024x569px) Image search: [Google]

320KB, 1024x569px

>>57192019
Nothing. Shitty programs are written with only a single core in mind.

>>57196614
>What governs the speed at which an electrical pulse propogates?

the medium

from what I can google up silicon has about 80% c

and this is before taking into account the effects of the geometry of the chip, the paths through the intricate web of transistors is probably many times longer than straight line

File: 003048522[1].jpg (27KB, 500x357px) Image search: [Google]

27KB, 500x357px

>>57192019
hi lisa

>>57196708
Yes
just like rockets are a few tons of scrap metal

>>57196708
>isn't silicon basically sand?
Sand is basically silicon.
Like you're basically water.

>>57190557
Latency, space and power consumption.

>>57190734
>and also faster when utilized.

>

>>57192019
>Or are software developers unable of creating programs that can utilize so many cores?
This

>>57192582
>If you, outside the industry have to ask yourself "Why aren't X doing Y?", then there's a very good fucking reason.
So answer it instead of chastisizing people for asking a question. Which you would have done if you had any clue about this stuff yourself.

>>57192061
Not quite, GPUs are SIMD architectures, not multicore. A 10-core CPU can run 10 programs at the same time, but a 10-ALU GPU can't

>>57196708
It must be really clean when it's, so it's a rare pepe for wafer makers. They clean it further of course.

>>57192255
>>>57192071
>because multi-threaded programming is a literal bitch
Maybe if you actually went to class instead of staying home and smoking weed all day you son of a bitch.

https://www.arm.com/products/processors/cortex-a/cortex-a73-processor.php

>>57192054
>some tasks don't scale well with increased core count
Beyond that, the memory controller doesn't scale well past a few direct connections. Increase the core count much past 4 cores, and either it has to become NUMA systems, or an increasingly large amount of the die would be taken up with a more and more complex memory controller.

>>57190557
>apple engineers can't even make a square or rectangle chip

File: intel-broadwell-cpuset-die-shot.jpg (739KB, 1923x870px) Image search: [Google]

739KB, 1923x870px

Here's the shot you're missing. Don't forget the differing process nodes.

If they want to go faster in single threads, then they probably should: deeper pipelines, better parallel branch misprediction, way more aliasing registers, not to mention Intel use an enormous ALU set, especially for AVX2.

It becomes a big challenge to keep most of it gated off so it doesn't cook the substrate.

There are plenty of structures in Broadwell which aren't used in regular instructions, even some which are gated off completely except for certain customers.

I'd like to see someone try a proper AMT arch on RISC-V, with one really fast, huge core for single-threads, a fuckton of smaller cores for higher multithreading performance, and a low-power core for most-of-the-time idling.

The big thing with lots of cores is getting the memory bus and cache coherency right - either you fuck everything and don't bother as such and end up with a GPU or a Parallela, or you try incredibly hard and finally get it right with some kind of complex ring bus - that takes lots of area by itself, but oh well. Note Intel's efforts with Larrabee then Knights Landing - that didn't go so well.

>>57199510
Why don't they just make CPUs bigger?

>>57200757

>I'd like to see someone try a proper AMT arch on RISC-V, with one really fast, huge core for single-threads, a fuckton of smaller cores for higher multithreading performance, and a low-power core for most-of-the-time idling.

big.LITTLE

>>57190557
larger core == higher latency == lower frequency

>>57200757
isn't that basically cell? it was shit

>>57201349

CELL was about having multiple cpus spread the workload. What anon is describing (and how big.LITTLE works) is a different concept.

>>57201373
cell had a fast single core with a bunch of smaller spu's for offloading whatever, and it was apparantly a bitch to program for

>>57200757
>If they want to go faster in single threads, then they probably should: deeper pipelines, better parallel branch misprediction, way more aliasing registers
but intel already does that
how is xeon phi not successfull?

>>57201373
What pisses me off is that they call their big.LITTLE SoC by the total number of cores even though only 4 can be used at the same time.

>>57199510

>So answer it instead of chastisizing people for asking a question. Which you would have done if you had any clue about this stuff yourself.
>Which you would have done if you had any clue about this stuff yourself.

Exactly. That's my entire point you retarded prick. I DON'T know why they don't 'just make processors with a lot of coarz lol', but there's clearly a reason no one's fucking done it. I trust the wisdom of silicone companies over an anonymous post on an imageboard.