His manager deserves the thank you. If someone started exhibiting the issues described in this post at any of my employers past and present, I suspect they would figure out how to get rid of them.
The biggest blocker to this vision is the lack of libre EDA tools for "modern" process nodes. As things scale down, new types of analysis are required. The OpenRoad project has some great stuff, but there's a long way to go if we want to build a compelling open IP ecosystem.
I bought a Chuwi Lapbook[0] for my wife a few years ago. It was great at first, but got unusably slow running Windows within ~1.5 years. I got her a new laptop and put Linux on the Chuwi. It worked fine for checking email and light browsing. The touchpad had strange sensitivity and seemed to be hard-coded so that scroll worked the opposite of my preference. It was tolerable until the keys stopped responding to my typing. I found that if I pushed really hard in the center of the key, it would sometimes register, but required firmer pressing. Ctrl and Shift stopped working altogether after awhile. The problem crept up from the bottom-right side of the keyboard, and I eventually gave up on it at the end of last year.
> With the new Panther Lake mobile processors, Intel has managed to successfully combine the two previous generations, Arrow Lake and Lunar Lake, as the performance is even better than with Arrow Lake, while efficiency has been improved at the same time. Even with low power limits, the performance is very competitive, and Intel (in conjunction with the new GPUs) is therefore the better choice for slim laptops.
The performance with LNL is not apples-to-apples, like the comparison with Arrow Lake H.
LNL has a much lower power consumption in the memory interface, like the Apple CPUs, which has nothing to do with the fabrication process. Also LNL is a lower performance CPU, for which it is normal to have better energy efficiency.
Only the comparison between Panther Lake and Arrow Lake H, which have equivalent structures, can be used to compare the Intel 18A and the TSMC 3-nm fabrication processes.
This comparison shows that Intel 18A ensures a better performance per watt, i.e. energy efficiency, which leads to a better multithreaded performance, but the TSMC 3-nm process, at least for now, allows higher maximum clock frequencies, which make possible a higher single-thread performance.
On-package memory disproportionately affect idle power more than load power. The benchmark was done with Cinebench 2024 which is a heavy load test. Therefore, LNL's on package memory would have made little to no difference overall to perf/watt in Cinebench 2024 ST.
Only the comparison between Panther Lake and Arrow Lake H, which have equivalent structures, can be used to compare the Intel 18A and the TSMC 3-nm fabrication processes.
Panther Lake uses a new core design which likely contributed to better perf/watt regardless of which node was used. For example, Zen3 had a 19% increase in IPC despite being on the same N7 family node as Zen2. Panther Lake has 3 tiers of cores instead of 2 in Arrow Lake. The MT design is very different. New core and layout designs can make a huge difference in efficiency on the same node.
This comparison shows that Intel 18A ensures a better performance per watt, i.e. energy efficiency, which leads to a better multithreaded performance, but the TSMC 3-nm process, at least for now, allows higher maximum clock frequencies, which make possible a higher single-thread performance.
We should compare ST perf/watt instead of MT. MT has too many factors including core count, die size, transistor count, clock speed.
Based on ST perf/watt, Intel 18A is likely a bit worse than N3B (2022 node) and a bit better than N4P (2021 node).
The Panther Lake cores, i.e. Darkmont and Cougar Cove are the Arrow Lake/Lunar Lake cores, i.e. Skymont and Lion Cove, ported from the TSMC 3 nm to the Intel 18A fabrication process.
The Panther Lake cores have only minor changes, i.e. bug fixes and the addition of a new mechanism for interrupts and exceptions, FRED. A preliminary version of FRED is likely to have already been implemented on Arrow Lake/Lunar Lake, but if so it was disabled there after production.
In any case FRED will not cause improvements in the present benchmarks, as it is used only inside the operating system and the current operating systems are unlikely to have been updated to use it anyway.
In contradiction with what you say, ST performance or performance per watt cannot be used to compare fabrication processes but only the multithreaded performance can bu used for this purpose.
Single-thread performance is affected by a lot of factors that have nothing to do with the fabrication process, but all those have little or no influence on multithreaded performance.
The reason is that in any well optimized MT workload, the CPU runs at a constant power consumption. This eliminates the influence of all factors mentioned by you.
I have already explained in another comment that a constant power consumption means a constant number of gate switchings per second, which is determined by the energy required to switch a logical gate, which is a characteristic of a fabrication process.
When a given amount of work is done by a benchmark using the same algorithm, well-designed CPUs will need approximately the same number of gate switchings to complete the work, regardless of the number of cores included in a CPU.
Significant variations of the numbers of gate switchings can be caused only by architectural differences like the width of vector and matrix execution units. Smaller variations are caused by various quality characteristics of a CPU core design, like the frequencies of branch mispredictions and of cache misses, which should be similar for CPU design teams that do not differ much in competence.
When we compare equivalent cores in different fabrication processes, like Arrow Lake H vs. Panther Lake, the multithreaded benchmarks are almost unaffected by anything else except the fabrication process, assuming that the cooling systems are also equivalent.
The reason is that in any well optimized MT workload, the CPU runs at a constant power consumption. This eliminates the influence of all factors mentioned by you.
This makes no sense because in ST perf/watt, we're normalizing watt already.
For the same reason that Yahoo should have bought Google after the dot-com bust. AI is useful and will eventually change the world. Many companies won't be able to provide sufficient returns, but will still have useful assets that Apple could buy at a discount.
Yeah I soon as I saw the price, this article fell apart completely.
The Neo has a great screen and an older iPhone processor. You can take the keyboard off a Neo add a touch screen but you still have to make a device that fits the battery and has all the same technology. You're back to at least a $600 tablet.
I’m confused as well. Did the author not consider the existing product line? iPads are not that expensive for the base model especially during the holidays.
This is a really well-thought out comment, and I agree with just about everything in it. One comment I'd like to call out for additional consideration is the comment on retirees being priced out due to rising property taxes.
In my experience, most retirees have more rooms/land than they can make productive use of. I feel that there should be some pressure for them to sell that property to families who can use it more productively. That's the stick, but I feel there needs to be a carrot, where builders are constructing homes that these retirees will be drawn to. There are retirement communities in the southern US like "The Villages" https://www.thevillages.com/, but as the population here ages, we need to build these everywhere so retirees can move into the communities that meet their needs without being forced to leave their cities.
> I feel that there should be some pressure for them to sell that property to families who can use it more productively.
I agree to extents. One lives in NY/NJ/CT because this is a big finance and pharma hub and it makes sense to live here while one works and eventually leave when that resource is no longer necessary.
But there's nuance here, too: families. My wife's side is a big Italian family. Everyone's here. What do you do if your grand kids are all here? How do you support your adult kids and help them achieve financial security? Or leave and secure your own? Neither is an easy choice.
> There are retirement communities...
There are here as well. The reason they work here, as far as I understand it, is that they count towards "affordable housing" units that are mandated by state law here in NJ. But I put that in quotes because these units in 55+ communities are often honestly still quite expensive, especially if you've already paid off your mortgage decades ago.
I've been thinking about this problem for quite awhile, and recently coded up something that allows for easy conversion between today's written English, and a phonetic spelling convention.
The idea is that instead of adding a nonsense file, you use the native .gitignore functionality.
".gitkeep" is just a human thing; it would work the same if you called it ".blahblah".
So their pitch is that if you want to explicitly keep the existence of the directory as a committed part of the repo, you're better off using the actual .gitignore functionality to check in the .gitignore file but ignore anything else in the directory.
I don't find it amazingly compelling; .gitkeep isn't breaking anything.
Granted, naming is hard. Routinely using a file named .deleteme or .rememberwalkthedog because it's recommended instead of a more readable solution, is not a compelling reason to switch.
reply