board was focused on extracting value from the company
A simple way to check if a board/CEO wants to extract a lot of future value _now_ is to look into their accounting, and especially how they count physical assets.
If they count physical assets at their current selling price, you can probably get in long-term.
If they count them at their buying prices you might have to worry.
If they do 'future accounting', tying into assets their estimated future added value, you can be sure the current owners are extracting the most they can _now_ and will try to drop the bag into futures investors (or ask for a government bailout)
And how would counting physical assets at their buying price move money from the company into the pocket of the CEO?
In normal/traditional accounting, you put the selling price of the machine (if you have to liquidate the company) on the side of the asset: let's say 8 millions the first year, and 5 million on the debt side (they bought it with 5 million of investment money, leveraged with debt). Company has 8 millions in assets, 5 million in debt: good ratio, healthy company.
Company B use future accounting: it buy the 10 million dollars machine. On the 'asset' side, you put 16 millions: the machine is worth 8, and is expected to earn the company a net profit of 8 during its lifetime. On the 'debt' side, you put 5. 16/5, the ratio is truly excellent. So good even that you can afford to take another 5 millions, and buy share/issue dividends. Now your asset/debt ratio is 16/10=8/5, same as Company A, except either your current shareholders have already reimbursed the initial investment, derisking themselves totally if the company ends up failing.
I think you have a Republican primary candidate who used that with his drug company, the company failed to produce anything of value, but only late investors lost anything.
But then they failed at that as well. Their share price almost never increased after 2000s. Currently they are valued lesser than their 1996's valuation, even if you exclude inflation. Highest they went was $263B valuation in 2021, which is nowhere close to tech giants.
Personally I feel that the 5 years of reintroducing 14nm instead of getting 10nm out the door was what ate up any lead that Intel had over its competitors.
And don't forget that rumors has it that Apple reported more bugs with Intel Skylake than the QA team at Intel had managed to report. Never a good thing when one of your biggest customers finds more bugs in your product than your own engineers have managed to find.
I wouldn't really blame all this on a single person though.
The largest part of that “overhead” is the need for much higher memory bandwidth and caching due to having many more cores to feed.
And the added complexity of programming is managing groups of cores (and multiple groups of cores) so they are all as active as possible without blocking each other algorithmically or due to memory misalignments, page read/write inconsistency, or cross interference.
With many more cores achieved with smaller cores: streamlined Arithmetic Control Units, less pipelining (?) and a simpler/shared Instruction Control Unit.
Somebody correct me if I am wrong.
If your program has one or two threads and spends all its time doing branchy control flow, a CPU will run it adequately and a GPU very poorly. If the program has millions of mostly independent tasks, a GPU will run it adequately and a CPU very poorly. That's the two limiting cases though and quite a lot of software sits somewhere in the middle.
The most concise distinction to draw between the hardware architectures is what they do about memory latency. We want lots of memory, that means it ends up far from the cores, so you have to do something while you wait for accesses to it. Fast CPUs use branch predictors and deep pipelines to keep the cores busy, fast GPUs keep a queue of coroutines ready to go and pick a different one to step along when waiting for memory. That's roughly why CPUs have a few threads - all the predictor and wind back logic is expensive. It's also why GPUs have many - no predictor or wind back logic, but you need to have a lot of coroutines ready to go to keep the latency hidden.
Beyond that, there's nothing either CPU or GPU can do that the other cannot. They're both finite approximations to Turing machines. There are some apparent distinctions from the hosted OS abstraction where the CPU threads get "syscall" and the GPU threads need to DIY their equivalent but the application doesn't care. Threads on either can call fprintf just fine. It makes a bit of a mess in libc but that's alright (and done in LLVM already).
> If the program has millions of mostly independent tasks, a GPU will run it adequately and a CPU very poorly.
Now I would say:
CPU - optimized to execute threads with independent instruction streams and data use.
GPU - Optimized to execute threads with common instruction streams and data layouts.
—
CPUs
As you noted: Optimizing conditional branches is one reason CPU cores are more complex, larger.
CPUs also handle the special tasks of being overall “host”. I.e. I/O, etc.
—-
GPUs
One instruction stream over many cores greatly reduces per core footprints.
Both sides of conditional code are often taken, by different cores. So branch prediction is also dispensed with.
(All cores in a group step through all the instructions of both if-true and else-false conditional clauses, but each core only executes one branch, and is inactive for the other. Independent per-core execution, without independent code branching. Common branching happens too.)
—
Both CPU and GPU can swap between threads or thread groups, to keep cores busy.
Both optimize layers of faster individual to larger shared memory (i.e. registers, cache levels & RAM).
His explantation is actually closer to the truth than your array of many CPUs. Because GPU isn't that. It is / was moving in that direction but it is certain not many CPU or Intel Larrabee.
To see how the Intel CEO is thinking, I now scrolled through a few interviews with him.
In this interview, Intel's CEO is asked to describe the difference of a CPU and a GPU:
https://www.youtube.com/watch?v=d07wy5AK72E
His answer is that the CPU is capable of doing general computing, while a GPU is made for very specific tasks.
I'm not sure if that is a good way to put it.
The way I would put it is that a GPU is a bit like an array of many CPUs. And to manage this array of processors all doing computation at the same time brings constraints and management overhead. So it is usually harder to program a GPU but results in better performance.