Intel Reports Second Quarter 2024 Financial Results
intc.com
intc.com
Anyone else feel like this is bean counters at Intel playing the wrong game? I personally feel like leadership at Intel lost the plot almost a decade ago.
It makes business sense but I don't know if I like that answer. What if everyone did that? Should everyone just use TSMC? That's stupid IMO.
* Intel foundry services were perhaps a decade or two too late. Running a fab needs scale. That had to come before they lost the technology edge.
* Intel treatment and mismanagement of engineers was well-known in 2000, and you need the best and brightest.
* Leadership needs to understand core business / technology. Bob Swan. Arguably Brian Krzanich. Paul Otellini. Just a lot of clueless at the top.
Etc. The point is Intel wasn't "everyone." Intel was at the very top of the game a quarter-century ago. That was their position to lose, which they did in a spectacular fashion.
I continue to hope for a Microsoft-style comeback, but it's becoming increasingly unlikely.
I hope for a comeback too. My amateur worthless opinion is that Intel is struggling now but at least they have fabs. The fabless companies are going to be fucked in the long term- the fabs they contract to are all on shifting geopolitical sands!
It's not luck if they were riding momentum that slowed because they shifted away from proper R&D.
The fabless companies had nothing but R&D to live on and the costs of outsourcing the fab means the capital costs could be amortized over more customers (meaning intel should have probably split in two).
Intel's fabs are a generation behind and now they're capital constrained. How do you get back ahead outside of China invading Taiwan?
Can you elaborate on this?
Intel rarely had the best technology, but it was often "good enough, cheap enough, and available enough" to succeed in the marketplace - this is a lesson SO MANY people forget. Sun, DEC, etc arguably had better hardware, but it was expensive. What Intel was very good at was iterating on the technology it had and making it faster within a reasonable budget. Microsoft is another good example of where "good enough, cheap enough, and available enough" is what usually matters in the market.
Where they started to stumble is when they got greedy. The whole RAMBUS debacle back in the day is a good example of where they took more expensive and worse RAM and tried to make it mandatory. Then there was the whole Itanium debacle, where politics succeeded over engineering and they ended up with a worse, more expensive product that failed in the market. AMD, which had recently acquired a lot of talent from DEC's alpha chip design, then went on and made 64-bit extensions to x86 that Intel had to play catch up to.
Intel (for the most part) ignored the performance per watt aspect of CPU design, which mattered in embedded, mobile, and dense datacentre environments. The result is that ARM came from the bottom up and is now eating Intel's lunch from all angles.
Intel's fabs couldn't compete with TSMC and to a lesser extent Samsung, both of whom could focus on the intense CAPEX (which due to cultural reasons people in Asian countries are willing to take longer term outlooks). CAPEX looks bad on an american GAAP spreadsheet. TSMC literally could take upfront money from apple to build new state of the art fabs and guarantee them a certain number of chips (and keep the money if the iphone had failed in the market). Intel couldn't do that.
Intel spent most of the 2000s era doing $130B in stock buybacks and even if it was run by engineers, they lost sight of the market. Stock buybacks and dividends are fine if you have surplus cash, but chip design is a high CAPEX business.
Why do you say Itanium was politics over engineering? It turned out to be a not-really-workable idea, sure. But if you looked at it, not knowing how it was going to work out, it was not an obviously bad idea. It was probably worth trying.
(Or are you saying that politics succeeded over engineering in the process of implementation of Itanium? I have no view on that.)
The instruction set for it was relatively bloated, indicating that there were too many compromises being made.
Writing compilers for it was a notorious shitshow. Itanium introduced a too much of indeterminism by via static scheduling hostile methods like branch prediction, variable latency caches, and attempts at an x86 compatibility layer. The core problem for Itanium is that it was impossible for the compiler to make good calls since it could not know exactly where and when things in memory would be. Even intel’s own compilers produced lackluster results, to say nothing of attempts by Microsoft, HP (who bet the farm on Itanium), and GNU (which mattered for Linux).
There were politics and demands from HP, which was the only seriously committed partner that wanted chips that would in theory be best for replacing pa-risc, but then intels own expectations of having it replace x86 everywhere.
Itanium actually did perform well at some kinds of parallelism. However, to take full advantage of that would have required a paradigm shift in the way languages worked, because 99% of the code out there was sequential/procedural. So maybe some new code (or more likely languages) could have really kicked ass (and intel did demonstrate that was possible), but even if everybody decided to go ahead there’d be a lot of learning and mistakes on the journey to full optimisation. Or you could just make your current code go faster by buying cheaper 64 bit x86.
I could go on, but you get the idea.
We were in the golden years of Java bytecode translations, real-world JITs, and Transmeta (which made a similar bet in hardware). That was the era we were starting to introduce rather complex transformations and optimizations. Computers were just starting to become powerful enough to where this kind of analysis and optimization felt possible and practical.
The compiler problem felt complex, but not unsolvable.
There were no good, obvious reasons I recall why the Itanium optimization problem couldn't be solved. The basic philosophy was make the hardware as fast as possible, even if it was hard to program, just rely on the compiler to deal with it.
Now, in hindsight, I can give all the reasons it didn't work. Key among them is that we drastically underestimated the degree to which complex software systems are hard to build and the way code messiness grows exponentially for these kinds of systems.
However, that wasn't really knowable in hindsight, though. Around the time, a lot of firms were making similar bets, and in 2001, I likely would have made the exact same bet with what was known at the time.
As a footnote, the anticipated progress in compilers is being made, but much more slowly than anticipated. NVidia reached its market cap on architectures being explored at that time. I had plenty of faculty promise similar SIMD/MIMD architectures would be increasingly important, but __dramatically__ underestimating the time it would take to get there.
Funnily, the static scheduling of Itanium was the opposite direction.
> There were no good, obvious reasons I recall why the Itanium optimization problem couldn't be solved. The basic philosophy was make the hardware as fast as possible, even if it was hard to program, just rely on the compiler to deal with it.
Oh, it technically could have been solved via compilers AND further architecture refinements (though it's a lesson in arrogance that Intel shunted this responsibility onto software developers). x86 is a complex mess of an instruction set, too. But it took decades of incremental hardware optimizations and compiler improvements to get it to scream. But there was a huge market for it, so anybody and everybody was working to improve it. You had everybody from big corporations to scrappy video game developers (especially John Carmack) figuring out ways to make it run faster, often via bugs in the architecture.
> However, that wasn't really knowable in hindsight, though. Around the time, a lot of firms were making similar bets, and in 2001, I likely would have made the exact same bet with what was known at the time.
I would argue that it was somewhat knowable. This wasn't the first time new CPU architectures were created. Many commercial UNIX's moved CPU architectures, some a few times. Some of their choices were similarly problematic. There were many technical and philosophical arguments on how reduced RISC processors should be.
I'm quoting from memory, but I saw a great statement somewhere that fans of RISC tended to be people forced to program assembly in university, which was painful on CISC architectures. This often clouded their judgement that extra instructions can dramatically speed up computing and the complexity can be abstracted by higher level languages and compilers/JITs. The real world is a harsh mistress (this is not to say RISC CPUs didn't have performance benefits in many cases, but it was mostly where large amounts of data needed to be computed on like databases).
> As a footnote, the anticipated progress in compilers is being made, but much more slowly than anticipated. NVidia reached its market cap on architectures being explored at that time. I had plenty of faculty promise similar SIMD/MIMD architectures would be increasingly important, but __dramatically__ underestimating the time it would take to get there.
The big difference is that GPUs, which are a fundamentally different paradigm of computing from CPUs, provided an immediate improvement even before heavy optimizations could be done. GPU development was kickstarted by games and it took decades for it to branch out to other large markets (first crypto, then AI). But the real benefit of GPUs is that it didn't replace CPUs, but operated in parallel. You could even run quake without one, at obviously reduced performance.
But intel also screwed up with GPUs...
I'm a big believer in incentives. Intel's incentives were to make a CPU that nobody else could copy like x86. The complexity was probably internally seen as a benefit so it'd be harder to copy. Intel thought it could dictate to the market what it was going to get and it arrogantly saw its market domination as being stronger than it was, leaving AMD to create 64 bit extensions to x86 on its terms (hilariously most compilers call the architecture amd64).
But the biggest incentive mismatch was there was no incentive to optimize for Itanium in the market. If nobody is buying it, are you going to spend time and money making your compiler or software better for it? If you're Microsoft, how much money are you going to sink into optimizing windows, .NET, VS Code, SQL Server, etc when there's no ROI? It's also a chicken-egg problem where you can't optimize when almost nobody is using it and seeing the bottlenecks. There were no John Carmacks spending hours in a debugger trying to squeeze out performance hacks.
Meanwhile, ARM started to grow by being good at specific things at first (performance per watt at a relatively low price). This mattered first in portable devices, then moved to being important in dense datacenter environments which encouraged development of more raw performance. Now we're seeing it in top of the line consumer computers. Itanium was promised to be to be all of this at once - almost overnight. IMO it was doomed to failure the second that first sales graph was created: https://en.wikipedia.org/wiki/Itanium#Expectations. If you try to make everybody happy at once, you usually end up with nobody being happy.
I think the key difference was that in the early days, one could only afford a single-pass compiler. Then, double-pass (but it was slow). Itanium was just at the time when compilers could _practically_ do deeper program analysis.
There is no individual piece in making a good compiler for Itanium which I can't solve. At the time, most interesting CS problems that smart people were working on are what we called "microprogramming" in my college jargon -- optimizing individual algorithms, optimizing an assembly loop, etc. What made an Itanium compiler hard was (again in local jargon) "macroprogramming" -- making all those things work together.
> I'm quoting from memory, but I saw a great statement somewhere that fans of RISC tended to be people forced to program assembly in university, which was painful on CISC architectures. This often clouded their judgement that extra instructions can dramatically speed up computing and the complexity can be abstracted by higher level languages and compilers/JITs. The real world is a harsh mistress (this is not to say RISC CPUs didn't have performance benefits in many cases, but it was mostly where large amounts of data needed to be computed on like databases).
This doesn't match my history.
The hypothetical difference was the other way around. CISC had complex instructions (which might take many cycles to run, like a string copy). RISC has simple instructions. Ergo, "reduced instruction set." The technical difference in early processors was RISC was pipelined and CISC was microcode (where all instructions took many cycles).
The reason for CISC was largely so programs could be smaller. This made a huge difference if a computer has e.g. 8k of RAM. CISC, circa Pentium days, was hard to make fast because:
- CISC variable length instructions were hard to decode, and RISC fixed-length ones were easy. This mostly disappeared as decode units became smaller perhaps circa 2005.
- CISC was hard to pipeline. Again, circa 2005, it became easy to (1) avoid annoying instructions in code and treat them as very slow backwards-compatibility special cases in hardware; or (2) do a translation.
For the most part, the practical distinction disappeared around then.
> The big difference is that GPUs, which are a fundamentally different paradigm of computing from CPUs, provided an immediate improvement even before heavy optimizations could be done. GPU development was kickstarted by games and it took decades for it to branch out to other large markets (first crypto, then AI).
True. Although that's more of a business distinction than a technical one.
> But the real benefit of GPUs is that it didn't replace CPUs, but operated in parallel. You could even run quake without one, at obviously reduced performance.
I'm betting 50% on convergence, as number of CPU cores grows, and GPU cores become increasingly complex. I think the M1 may be the track we eventually converge on, with diverse cores optimized for diverse tasks.
> But intel also screwed up with GPUs...
True. Although they seem on an okay track if they can get the software right. A770 16GB can be had for $300. NVidia 4060 16GB is $450 (and faster). For a lot of non-gaming users (ML, CAD, etc.), the A770 is ideal.
> I'm a big believer in incentives. Intel's incentives were to make a CPU that nobody else could copy like x86. The complexity was probably internally seen as a benefit so it'd be harder to copy. Intel thought it could dictate to the market what it was going to get and it arrogantly saw its market domination as being stronger than it was, leaving AMD to create 64 bit extensions to x86 on its terms (hilariously most compilers call the architecture amd64).
I am too -- although that's a business rather than technical argument -- but I'm not sure that's exactly what happened here; I think it's about half-right. I think Intel simply overestimated the amount of time it would stay dominant in the market, underestimated the competition, and underestimated the time Itanium would take to develop.
I don't think they were intentionally making the CPU either easy or hard to copy.
> I think the key difference was that in the early days, one could only afford a single-pass compiler. Then, double-pass (but it was slow). Itanium was just at the time when compilers could _practically_ do deeper program analysis.
> There is no individual piece in making a good compiler for Itanium which I can't solve. At the time, most interesting CS problems that smart people were working on are what we called "microprogramming" in my college jargon -- optimizing individual algorithms, optimizing an assembly loop, etc. What made an Itanium compiler hard was (again in local jargon) "macroprogramming" -- making all those things work together.
Both these circle back to a point I made earlier in the thread - who’s going to do that for a processor nobody is using? There is an alternate timeline where a combination of hardware and compiler/software iteration make Itanium competitive at a performance level, but intel’s non-technical decisions made that impossible at a practical level. It was never made cheap or available enough where anybody could tinker at the lower end, and at the high end they suffered from the chicken/egg “nobody bought it because x86 was faster today”.
The Itanium did to very well in some supercomputer deployments where the code could handle the architecture’s good parallelism. But that was likely net-new code for a niche product.
> The hypothetical difference was the other way around. CISC had complex instructions (which might take many cycles to run, like a string copy). RISC has simple instructions. Ergo, "reduced instruction set." The technical difference in early processors was RISC was pipelined and CISC was microcode (where all instructions took many cycles).
Hypothetically, yes. In the real world a lot of work was done to minimize that over x86’s lifetime. In the early days RISC did do a lot of what was promised, but clever (some would say hacky in some situations) updates to x86 CPUs and compilers made these advantages less (although one could argue the x86 microarchitectures that showed up in the mid to late 1990s were more RISC like). Faster and better caching (variable length x86 instructions meant that common instructions can have a shorter encoding and take up less space in the instruction cache, vastly reducing expensive cache misses) also minimized a lot of these issues. The main issue was a lot of these “enhancements” kept the performance per watt ratios at very poor levels, which caused no end of headaches as laptops became more popular and left intel (and AMD with x86) with no competitive alternative to ARM in phones.
> The reason for CISC was largely so programs could be smaller. This made a huge difference if a computer has e.g. 8k of RAM. CISC, circa Pentium days, was hard to make fast because: > - CISC variable length instructions were hard to decode, and RISC fixed-length ones were easy. This mostly disappeared as decode units became smaller perhaps circa 2005. > - CISC was hard to pipeline. Again, circa 2005, it became easy to (1) avoid annoying instructions in code and treat them as very slow backwards-compatibility special cases in hardware; or (2) do a translation.
I agree with all these points, but even before the decode enhancements ~2005, lots of work was done to mitigate these. But the most obvious thing that x86 caught up with was clock speed. A central argument in favor of RISC was that it allowed for an ability to jack up the the clock speeds of processors, that could then iterate over the reduced instructions faster and provide better performance in most computing cases. This clock speed advantage (in practice) was eliminated, though not due to issues with RISC itself, but more because it was only the large volumes of x86 chips could justify the higher costs of staying near the bleeding edge of transistor manufacturing allowing smaller transistor sizes (something that ARM would eventually come to lead, though).
The CISC instructions were often heavily improved upon over hardware iterations or moved over to new ones (MMX being a famous example) that were more in line with how code was used (hilariously MMX became kind of redundant soon after as GPUs took over those functions). There were also many cases where x86 could do things in fewer instructions than RISC, which helped even more at higher clock speeds as x86 caught up.
Again, I’m not necessarily defending CISC/x86. But it had so much engineering heft thrown at it due to its install base that it often brute forced its way to performance and it was only when performance per watt metrics started to matter that an alternative came on the scene (and it was not something that Itanium would have been better at - ARM would probably be causing the same issues to intel in the data center had Itanium taken off as it was). This was always going to be a hindrance to any replacement. The fact there was genuine competition in x86 kept prices lower and development cycles active, too.
A lot of what you state is correct, but in practice x86 chips were still faster for most workloads out there. In a perfect world all this time and effort would have been heaped on a far better CPU architecture (CISC or RISC), but alas…
Even today x86 still outperforms ARM on most server chips, but our AWS loads are using their ARM chips because it’s cheaper per unite of compute, which is fine for most workloads. This may even get better as more focus is put on ARM via compilers or architecture iterations.
> True. Although that's more of a business distinction than a technical one.
It’s a technical one. They provided immediate technical enhancements, but didn’t mean all your current code had to be rewritten. It was optional (until video games got so sophisticated that they were required then) and you didn’t need to rewrite/recompile your OS to use it. However, GPUs are a lot more niche, so fundamental architecture changes can be done more easily, especially as most code out there is done via higher level APIs.
> I'm betting 50% on convergence, as number of CPU cores grows, and GPU cores become increasingly complex. I think the M1 may be the track we eventually converge on, with diverse cores optimized for diverse tasks.
I agree on this for most consumer products. SoCs have taken over the embedded and mobile market and that can continue to other markets. But we’ll see what happens if AI continues its current trajectory. There it’s the GPUs that matter more than the CPUs and we could see something different emerge.
> I am too -- although that's a business rather than technical argument -- but I'm not sure that's exactly what happened here; I think it's about half-right. I think Intel simply overestimated the amount of time it would stay dominant in the market, underestimated the competition, and underestimated the time Itanium would take to develop.
It’s all about business, though. If the world was purely technical, Amiga, DEC, or Sun would be on top of the world. Intel did everything you just said, but also tried to do too much. A lot of what intel does is over-engineered in a sense they do things in a more complex way that necessary (some cynical people would say on purpose to make larger margins on hardware/chipsets eg USB, which at a low level is very complex even for the original spec).
> I don't think they were intentionally making the CPU either easy or hard to copy.
At an engineering level, no. But higher up they made sure the way it worked with IP, etc would make this difficult. The fact that x86 clones exist at all was a legal miracle and a quirk of history (pretty much IBM demanding it for the original PC and intel was not big enough yet to say no): https://jolt.law.harvard.edu/digest/intel-and-the-x86-archit...
> In the real world a lot of work was done to minimize that over x86’s lifetime. In the early days RISC did do a lot of what was promised, but clever (some would say hacky in some situations) updates to x86 CPUs and compilers made these advantages less (although one could argue the x86 microarchitectures that showed up in the mid to late 1990s were more RISC like).
They were identical to RISC architectures, with the exception of a more complex decode unit, which led to extra transistors burning extra power and costing speed in the early Pentium days.
That mattered a lot when a 1993 Pentium had 3.1 million transistors.
That matters a lot less when a modern Intel CPU has ≈5 billion transistors.
Fundamentally, that's what allowed x86 to pass all the various RISC architectures in speed. Those kinds of differences in instruction set just don't matter anymore. At that point, it was just R&D dollars, which Intel had more of due to volume.
As a footnote: It's worth remembering StrongARM. The SA-110 was just as fast as the fastest Intel had to offer, when introduced in 1995, at a much lower price and power budget. It was crazy I could get a little embedded board for $100-$300 which was just as fast as $5000 computers. Intel acquired it from DEC. Oddly enough, it barely improved from there on. A decade later, clock speed went up 4x on the XScale (and only on the very top-end), and more than 15x on the x86.
The fabless companies will also have a problem if only TSMC is left. What is there to keep them from rising the prices? Right now TSMC is afraid of Samsung and Intel, but if Samsung falls behind and Intel folds, AMD / NVDA / ... will have a crisis on their hands.
The US leadership fucked the dog and decided cheap labor was more important than national security or a functioning economy.
Everything is gone, it has been shipped overseas.
Organized labor is considered a threat to national security, it's no coincidence that deindustrialization followed a period of widespread labor militancy.
This applies to most large, inefficient corporations that get too comfy with success and forget how to pivot fast, take risks, and fiercely fight for their place in the market.
Eventually, any organization that falls into this state, slowly stagnates into oblivion.
Add to that the suspension of the dividend, and the packaging of the FPGA business (getting ready to sell it?) and the reference to idle capacity - guess they can't even fill that with their foundry business.
One thing I've noticed is that predicting timing is impossible. You can see a company showing signs of impending failure and somehow stock price still increases for a while, or the company decays slowly over a very long time. This might be a good thing since a company may save itself in some instances.
Then, eventually, you'll see a "straw that breaks the camel's back" and the hollow shell of the company will finally, fully implode.
When Jobs contacted Otellini about having Intel fab an ARM chip for them and Otellini said no... That's probably about the time their fate was sealed. And that would've been around 2006. Yes, there were plenty of signs prior to that. For example: AMD needed a lot less engineers to spin a new processor rev than Intel did and AFAIK that's still the case.
But Intel's stock has been stagnant for years.
By then:
- Intel's 10 nm node was known to be two years late and known to be plagued for many others while TSMC had already taken the crown for most advanced foundry on the planet
- Apple announced their work on phasing out Intel hardware completely for their own ARM SOCs
- AMD had launched Ryzen, back then a bit slower in single thread but already much more competitive in MT
- Supercomputers and crypto showed the ever increasing possibilities of GPUs for heavily parallelizable calculations and Intel had nothing to offer there
- Cloud providers building their own hardware on ARM
Nvidia for comparison is less than half that per year.
It is clearly not in the case or every company would have exponential growth simply by reinvesting in R&D.
In reality, it is extremely difficult to create growth from R&D at all.
Now-obvious mistakes: I'm not including the obvious mobile argument as it belongs to the previous point, but they slept too long on GPUs. Even though the biggest supercomputers in the planet started doing computations on GPUs a decade ago they missed the ultimate parallelization-hardware train.
Honestly the problem is the same then as it was today - having good hardware isn’t enough. You need software penetration and organic usage/ecosystem. And the world can support maybe 2-3 of those right now - nvidia, apple, maybe one other. Everyone else gets the bullshit “we are the ones you need a cross-platform “adapter” ecosystems with effectively no real corporate moat etc.
(amd, intel, the door to this room is locked… one of you will get an ecosystem and the other goes home in a box… the game begins now.)
Like even just in gaming, AMD’s continued refusal to do the devrel has hurt them, it’s cost them revenue. It’s not even just “the drivers” or the constant deficit in features and functionality, but getting the people out into the studios to assist in development and tuning is how it has to be, nobody is going to tune for your hardware if you don’t do it yourself.
Interesting that oligopsony beats oligopoly :-)
When their fab hit a rock with 14nm and 10nm process tech advantage was more. This gave rhe edge to all other design companies and made it clear that how behind Intel was on design front.
Truth is, Pat is doing nothing despite the generous government subsidies
It takes YEARS to realize the benefits of these changes.
The problem is, to stopgap TSMCs growing lead, Intel resorted to cranking up voltage on the last two generations of chips leading to what will be an imminent gigantic ass lawsuit.
Well, he did. He bought up a ton of studios and focused on games again. in 2014 they were completely tonedeaf to the state of not just games, but media as a whole. Cable box subscriptions even in 2014 for their 8th generation console was just horrible optics.
Now, is it his fault directly that the game development per studio is slow, or the releases uneven? He's probably not blameless, but MS isn't really known to intervene nor micromanage their studios. IMO that's a much bigger issue than any single MS studio.
my gut reaction is that he wont be their ceo for long.
It also blows the latest mobile i7 ultra 155H on the same XPS 13 in performance while lasting almost 20 hours (compared to Intel's 6).
The comparisons are made on software that runs on both (Geekbench, handbrake) but it's clear that there is a huge momentum building for windows on arm.
Oh my.
60w peak power consumption for a literal single thread. 35w average.
https://old.reddit.com/r/hardware/comments/1efcst2/ai_370_vs...
https://www.notebookcheck.net/AMD-Zen-5-Strix-Point-CPU-anal...
We simply aren’t going to see x86 get to the subjective “apple experience” of a laptop that runs equally well on or off battery, with day-long life during interactive low-intensity usage, until x86 vendors can get their single-thread power consumption under control. Platform power is part of it (although external-monitor tests minimize most of the usual factors) but x86 simply isn’t competitive in performance terms unless it’s boosting excessively high in power terms. At least not right now.
I know Keller said it only matters 20% or so, but… right now we are objectively in a world where x86 is using ~triple the power in 1T workloads. The x86 is fine when it can exploit SMT and the workloads are heavily numeric/vector oriented, they simply aren’t very good at single-threaded workloads where there is no SMT to fill their pipeline bubbles.
And yes, race to sleep is all well and good. But apple can race to sleep on 1/3 the power. Apple can also have an icache and all that other crap too (m1 has an icache six times as big as its x86 competitors). At the end of the day the x86 results are still objectively poorer by literally several powers of 2. But Keller said everything is equally good therefore the evidence can be casually dismissed.
Even the much happier computerbase numbers only put this at 20w core power (and they’re using sensors, not actual measurements of course). And that still is power you have to pay on those laptops, even if it’s “platform power” - like, ok, so the defense of x86 here is that x86’s finest champion is spending more on platform power than the apple laptop uses at the wall for the whole laptop… by a factor of 50%. It then uses another 2x multiple of the apple laptop to do just the computation work.
That’s the bright side argument about x86.
I disagree. Apple themselves showed what you could do with an x86 processor in terms of battery life long before they went to ARM, and most manufacturers still aren’t even close. People have been talking about the amazing life in their products for ages before arm.
Meanwhile I can’t get my windows laptop to not burn itself up in my bag with an update, which also coincidentally uses a ton of battery power as the fans cool itself on full tilt
Usually if it’s not totally idle it idles at 22w. And again, this is the problem, light load produces quite a lot of power consumption on x86 compared to arm.
I bought it for the meme, it was a laugh and I wanted a late-gen x86 model with no dGPU to give x86 the best shot (mostly bought it for windows use actually). But the “it’s just macOS/optimization magic!!!” isn’t true either. x86 MacBooks still fucking suck, even the ones without the absolutely shit-tastic AMD dGPUs onboard. Those idle at closer to 50w if you have a display plugged in, btw. There’s no way to turn them off because the display outputs are hardwired to the gpu, if you are using an external display the dGPU is forced on. I tried, my old work MacBook was an i9 and it fucking sucked during the summer.
The idea that macOS is just uniquely lightweight and can somehow wring better perf/w out of computational tasks than Linux or windows just isn’t supportable either. Certainly if it were true it would also show up in MT and not just 1T loads. Reality is perf/w is mostly a constraint of the processor and not the OS… just like the OS can’t magically make applications use less ram and “turn 8gb into 16gb” either. It takes X cycles for Y processor to execute Cinebench and the OS does not matter that much in the big picture.
It maybe does help with sleep states and idle power, things like grand central scheduling. But 1T load is a load state, not idle.
That really surprising since my 8th gen intel laptop (2 generations older than ice lake) idled at under 5W in Linux. So does my newer 12th gen intel laptop.
I will play with it and see if I can get package power.
But the overall point is that even looking at total system power - the apple silicon is silly efficient. It’s actually meaningfully better than x86 in literally every way you choose to measure it.
When apple went to the M1, they got their entire software ecosystem to go along with the migration. That's the fundamental strength of Apple. They can do things like kill standards at will.
Microsoft can't necessarily do the same thing for the vast library and catalog of x86 software.
Then they got worse.
Financial reports are going to be exactly that, focused on the numbers and appearing to investors to be maximising their value. You want to carry a perception that you are focusing on the positives and the innovations being carries forward, as opposed to mulling over what "might be wrong". All companies go through ups and downs, but you do not want your financial report to have a theme of these are the things that are wrong.
so, empty platitudes that turn into none or negative change. Gotta love the modern day business.
I doubt that Nvidia putting in their financial reports last year they were focusing their R&D on AI hardware turned into none or negative change
Pessimism aside: they did this exact song and dance some 7 years ago. So I'm not entirely operating off bad vibes but on history and current trends. Like I said, they already basicslly lost the AI race. If they want to compete for scraps, power to them. I just hope employees jump ship before the next layoff wave.
they should have spun-off their fab years ago as AMD did. fabs business model isn't shareholder value compatible.
They essentially ended up where Boeing did, but at least didn't kill anybody.
The Register: "Intel to dump 15 percent of staff to save costs" <https://www.theregister.com/2024/08/01/intel_to_ax_headcount...>
CNBC: "Intel to cut 15% of headcount, reports quarterly guidance miss" <https://www.cnbc.com/2024/08/01/intel-intc-q2-earnings-repor...>
15% layoffs is nearly 20,000 people.
>Fire 80% of them. Twitter had probably more talent per capita than Intel. If they can fire 80% most companies should.
What's special about "them"? Twitter was technically never a particularly complex product that required some kind of exceptional talent. Not even remotely in the same ballpark compared to what Intel is doing (or trying to do anyway...)
But there are also likely to be countless "twitter-like" employees too, paid to sit on their hands or faff about with branding or tinker with devops parlor tricks or gate access to resources that engineers need.
So the current level of cuts passes the "gut" check for me. They surely have less "chaff" than Twitter, and it's crucial not to accidentally cut too many key personnel in the process.
The only reason Twitter isn't a dead husk is because network effects are really damn strong. That's it. The attrition to Bluesky or Mastodon or whatever won't be as drastic as the Myspace days when single percentages of the current internet populace were connected.
You don't get network effects with hardware, especially since most people these days buy laptops and won't bother to specify an intel chip (if available at all).
Their financials tanked as advertisers fled the platform or reduced spend drastically. It's now basically a money pit that at present trajectory will continue to burn money until Elon's other ventures can't afford it. Given his wealth he can keep losing a billion or two a year forever even if people stop buying his overpriced poorly built cars.
I predict however that eventually it looks less interesting and they try a rebrand as twitter with 90% less Elon for 2x the advertising dollars (for real this time) and borrow as much money and assets as possible and eventually exit.
Musk thought that what people wanted was raw unfiltered “free speech”, but he thought his kinds of views were restricted. The result was when he got control, the guardrails were mostly removed and a lot of users recoiled, and advertisers left due to the desirable users targets disappearing as well as having their ads shown next to questionable content. Then he contradicted himself by blocking accounts that hit his ego.
I’m a geopolitical nerd and loved twitter, but finally gave up on it when I started getting fake news as well as promoted tweets by musk himself, whom I didn’t give a shit about his at best bizarre opinions. The blocking of third party clients meant that I couldn’t even filter client-side anymore (RIP Tweetbot).
Censorship is when the government won't let you publish something. It's not when Twitter doesn't let you post something, it's not when your post isn't shared, it isn't when Pepsi won't pay you to run ads, and it's not when users stop engaging.
All of these things are things people are morally entitled to do.
Elon is the wrong person because he's ruining it and because he's doing so in service not to a different tax or economic policy but in service to evil.
US. Total economic collapse. Hard landing.
This is the beginning of the end. We really had the chance to make something beautiful with this country, but the 1% bought and sold it into the ground.
Half our politicians aren't even trying to keep it running anymore.
A good friend of mine is the son of a former hedgefund manager... who told me in 2018 "owning real gold is foolish;" in 2024, he's recently told me about his expanding gold collection.
I have made even more returns on silver/BTC, but anything "real" is probably durable enough to last for (hopefully at least) another decade of keep kicking the can down the road...
Quoting my favorite family member of The Silent Generation (pre WW2 birth), "Nobody wants to be the last one at the party, because then you have to help clean up all the mess!"
It's happening, real-time. Yes. All "trickling up," exactly as-designed: into more-durable asset classes, largely unaffordable to Joe American.
Just for reference, a troy pound of gold currently trades for around $30,000; whereas in 1970 the same mass was, officially, $420.
e.g. Multiple OPEC countries trading oil in non-USD transactions (against policies to only do so, set since early 1970s).
e.g. 2020, largest publicly-traded company was a state-run oil extractor (Aramco), worth barely only $2 trillion [two million million dollars]; 2024 (so far) there were THREE $3T+ marketcaps, each a massively-inflated evaluation; bitcoin is more-stable & more-valuable than most tech stocks
e.g. #100 publicly-traded asset (by market cap), in 2020, was worth approximately $110B; #100, in 2024, is worth approximately $155B
Never forget that Nixon prosmised, just as countless other politicians are trained to do: that this suffering is only TEMPORARY. They're technically not incorrect, when temporal definitions are left undefined.
The company didn't die of starvation, it died of obesity.
Seems pretty clear to me.
Like if you just don't like stock markets or capitalism in general, that's fine, but that doesn't have anything to do with stock buybacks.
Same with Boeing. Miserable failure of a company, somehow found room to hand the owners massive amounts of money, meanwhile they have massive quality issues.
If you want to help turn things around, contact the board members and CEOs directly. Make it clear that they should not receive any compensation until they have successfully revitalized INTC, MBLY, and other related companies. For reference, these are the KPIs for them: INTC's market cap should be currently around $250 billion and MBLY's is about $35 billion.
======================================================
Jensen Huang, please buy INTC!!!! PLEASE BUY IT AND MAKE IT GREAT AGAIN! PLEASE PLEASE PLEASE!
However, the secret sauce of Nvidia is simply using TSMC anyways so...