Zen 2 Missives – AMD now delivering efficiencies that are double that of Intel
apollo.backplane.com
apollo.backplane.com
This is a hidden thing that seems to always go under the radar.
My Intel i7 4790k has lost at least 40% speed since I originally bought it, and for years, I always thought that Intel machines were getting slower without any actual proof whereas AMD machine I returned to after years just felt as fast as ever.
Now with microcode updates and similar getting more coverage, I'm certain that this is what it is.
AMD's partner program is meh, where as Intel is really partner focused - if anything breaks, I can get a replacement shipped to me in advanced the next day for ~3-5 years (component depending), but I am seeing much more demand for AMD as of late.
If I remove the Intel microservice dll from my windows system folder then I get my 41x back, but there's been no documentation forthcoming. Just finding out why speeds were nerfed required lots of research.
Having said that I can see that Asus may have finally released the required motherboard update for this. Updating requires me to reset everything by hand, as Asus doesn't let me simply back up settings - they are invalidated between bios versions. Between that and eating CPUs if using XMP, it's the worst motherboard I ever bought.
https://www.asus.com/us/Motherboards/ROG-STRIX-X99-GAMING/He...
Needless to say my days of building Intel systems are over.
This was incredibly sloppy work by Asus.
So yeah, eating CPUs.
The chipset was the Broadwell EP. VCCSA ran at ~1.33, when the maximum should have been 1.25. Also VCCIO was 1.25, when it'd run happily at 1.096v.
Point taken was to go through every single voltage setting and research safe ranges, not trust auto for _anything_. There were changes in the CPU memory controllers around this time, and that's what caused the CPU to die when unsafe voltages were applied; Asus' XMP settings for my 4x8=32GB 3200 Trident Z DDR4s (17-18-18-36) turned them to mush.
I don't have a degree in electrical engineering; it seems like Asus wanted you to have one.
Looking back I'm discovering more details... and another guy who experienced essentially the same, with others backing up the instability of the platform: https://forums.anandtech.com/threads/my-6850x-just-died-just...
Whilst I want to move over to AMD, I'd like my current 6850k to last longer as my son's computer. It seems like I won the silicon lottery with my old 2600k that he's currently using though; running fixed 4.4ghz which is a very nice upgrade from the stock 3.4ghz.
The original article in this thread is music to my ears - for AM4, just add a great cooler and away we go. It's tempting to upgrade both computers at the same time.. which kind of wrecks my hand me down thing, but I'm sure the 6850k got degraded by 3 weeks on the bad settings as I've had lots of issues with it (unlike the 2600k).
(Final edit: Thus my disdain for Asus' inability to back up BIOS settings on this board when performing BIOS updates like I should now to get my overclock back, unlike others I've had; if I miss even a single one of the voltage settings, I can expect it to fry the CPU - unless they actually fixed their sh*t in one of the BIOS updates).
I've already gone through one CPU, about 4 months after I built it. Now the whole machine is just dead with no signs of life. I bought a new board assuming the board was bad but maybe I need to test the CPU now...
Agreed though, one of the worst boards I've ever bought and seriously rethinking all Asus purchases in the future.
The only solution was to prevent the os from loading the bad microcode at boot - I'm guessing that's what removing those .dlls does.
Pretty sad that mitigations against a largely theoretical attack hurt performance for everyone. Meanwhile people continue to open e-mail attachments with .scr extensions.
My laptop is not high-value so I'd rather just disable that stuff. I once timed a C++ build, with and without Spectre mitigations, and the difference was something like 20%.
Consider the average user. You can remove almost all malware and viruses because they only install and run with user permissions. Without spectre mitigations, it wouldn't be very long before all that malware was installing itself at deeper levels where the only solution is blowing everything away completely.
I'm sure there is also a DRM argument somewhere for people who like that kind of thing.
40% speed reduction does not really count as "anything breaks", does it? Some previously working workloads stopped working.
https://www.anandtech.com/show/14211/intels-interconnected-f...
Hotchips is full of chiplet talk. TSMC specifically calls out AMD, Xilinx, and Nvidia when talking about chiplets.
https://www.anandtech.com/show/14770/hot-chips-31-keynote-da...
Nvidia's Hotchips highlight is an AI accelerator with 36 chiplets on board (and interestingly, with a RISC-V controller -- probably the one they've been putting in their graphics cards).
https://www.anandtech.com/show/14767/hot-chips-31-live-blogs...
A chip can't bin faster than its slowest core. Getting 28 cores that run at top speed is almost impossible (even with Intel's super-stable 14nm and many chip design iterations optimized for the process). In contrast, getting 8 cores at a high speed happens much more often.
Likewise, a given manufacturing process is going to have an average of N errors per wafer. Duplication of parts of the chip can help, but they increase cost and some parts simply aren't economical to duplicate. If the error is in cache, you can probably laser off a cache block and move on. If the error is in the ALU, you probably aren't as lucky and will have to laser off an entire core (worse errors may even cut out an entire group of cores). A huge 28-core chip has a very high probability of an error meaning that you probably have a bunch of 26-27 core chips, but far fewer 28-core chips.
What is the chances of finding that magic chip with 28 defect-free cores where all of them also run at high-speed? This is one reason why Intel has so many SKUs. AMD also sells the same chip to both consumer and server, so they can take the best of the best and ship them to servers. If there's a defective core or two, laser them out and sell one of those 12-core desktop parts. If it's missing a core and doesn't clock high enough, sell it as a 6-core 3-series chip.
The ability to split fab nodes is also huge. Half of the new Zen 2 chip is 14nm. If they had to make that on 7nm as well, their supply would be halved and prices would go up substantially due to increased chip cost and decreased chip supply. If an interposer is needed, it can be even older (I think AMD used a 65nm for their Fury HBM interposer though something even older like 180nm would probably work just fine for wire-only interposers).
Of note here is that Intel tried to identify which cores on a die could run fastest so that low thread count workloads could use only the best cores on the chip, but the software side was a disaster and they have pretty much given up on the concept.
> AMD also sells the same chip to both consumer and server, so they can take the best of the best and ship them to servers.
They may also be sending the most efficient chiplets to the server parts that have so many chiplets on each package, while keeping some of the fastest chiplets for the consumer parts. There's really not much precedent in recent generations for having one piece of silicon span such a wide range of products.
Intel and AMD recently started binning individual cores, although I don't think it has hit Xeon yet.
I don't think you can even get it outside of custom-built HPC machines.
I guess part of this nonsense is the consolidation of cloud vendors. Intel is selling CPUs the way IBM sold mainframes in the 1960s.
We were constantly saying this about AMD until Zen, and Zen is largely credited to Jim Keller. Where did Jim Keller go after Zen? Intel. I'm lowkey afraid that AMD will run out of steam after one or two gens and Intel+Keller will have just finished developing an insane architecture that brings us right back to the pre-Zen era.
I mis-read it as "cynical in nature", and it still fits. May the best process win.
He didn't went straight to Intel, You missed Tesla in between. And anything he is doing will be 2022+ at the earliest. Intel already has a roadmap of Chips that were delayed by Fabs, and that is at least up to 2022 / 2023.
I am pretty sure AMD has many competent people too. And as far as I could tell, I don't ever see engineering talent as a problem in any big tech companies. There are lots of insanely great engineers from Microsoft and even Oracle that most have not heard of, but most of the talents are hampered by cooperate politics and culture. And so far AMD seems to have a far better culture under Dr Lisa Su than Intel.
The biggest problem with the Q6600 is that it was a big hack to communicate over the frontside bus, something designed for nice slow memory access that didn't have the bandwidth or latency for inter-core communication.
Infinity fabric, on the other hand, is good enough that on Zen 2 they didn't even bother to directly connect the two CCX that share a die.
In particular, the EPYC processors achieve such high cache capacities by splitting L3 into slices across multiple silicon dies, and accessing non-local L3 incurs huge interconnect latency - 132ns on latest EPYC vs 37ns on current Xeon [1]. Even DDR4 on Intel (90ns) is faster than much of an EPYC chip's L3 cache.
Intel's monolithic die strategy keeps worst case latency low, but increases costs significantly and totally precludes caches in the hundreds of MB. Depending on workload, that may or may not be the right choice.
[1] https://www.anandtech.com/show/14694/amd-rome-epyc-2nd-gen/7
In general, all Zen generations share two characteristics: cores are bound into 4 core clusters called CCXes, and two of those are bound into a group called a CCD. Chips (Zen 1 and 1+) and chiplets (Zen 2) both have only ever put one CCD per chip(-let), and 1, 2, and 4 chip(-lets) have been put on per socket.
In Zen 1 and 1+, each chip had a micro IO die, which contains the L3, making a quasi-NUMA system. Example: a dual processor Epyc of that generation would have one of 8 memory controllers reply to a fetch/write request (whoever had it closest, either somebody had it in L3 already, or somebody owned that memory channel).
L3 latency on such systems should be quoted as an average or as a best case/worst case. Stating L3 as worst case only ignores memory cache optimizations (such as prefetchers grabbing from non-local L3 and fetches from L3 do not compete with the finite RAM bandwidth, but add to it, thus leading to a possible 2-4x increase performance if multiple L3 caches are responding to your core); in addition, Intel has similar performance issues: RAM on another socket also has a latency penalty (the nature of all NUMA systems, no matter who manufactured it).
Where Zen 1 and 1+-based systems performed badly is when the prefetcher (or a NUMA-aware program) did not get pages into L2 or local L3 cache fast enough to hide the latency (Epyc had the problem of too many IO dies communicating with each other, Ryzen had the issue of not enough (singular) IO die to keep the system performing smoothly).
Zen 2 (the generation I personally adopted, wonderful architecture) switched to a chiplet design: it still retains dual 4 core CCXs per CCD (and thus, per chiplet), but the IO die now lives in its own chiplet, thus one monolithic L3 per socket. The IO die is scaled to the needs of the system, instead of statically grown with additional CCDs. Ryzen now performs ridiculously fast: meets or beats Coffee Lake Refresh performance (single and multi-threaded) for the same price, while using less watts and outputting less heat at the same time; Epyc now scales up to ridiculously huge sizes without losing performance in non-optimal cases or getting into weird NUMA latency games (everyone's early tests with Epyc 2 four socket systems on intentionally bad-for-NUMA workloads illustrate a very favorable worst case, meeting or beating Intel's current gargantuan Xeons in workloads sensitive to memory latency).
So, your statement of "a tiny NUMA system within the package" is correct for older Zens, not correct (and, thankfully, vastly improved) for Zen 2.
Seems like there're at least two approaches for future gens: widen the scope across which you can share L3 without a slow trip across the I/O die, or speed up the hop through the I/O die. Unsure what's actually a cost-effective change vs. just a pipe dream, though.
Regardless I wouldn't be particularly concerned, cache seems like the easier issue to address vs power density.
[1] https://www.tomshardware.com/reviews/amd-ryzen-5-1600x-cpu-r...
[2] https://www.tomshardware.com/reviews/amd-ryzen-7-1800x-cpu,4...
Think of the MESI model.
If Core#0 controls memory location #500 (Exclusive state), and then Core#32 wants to write to memory location #500 (also requires Exclusive state), how do you coordinate this?
The steps are as follows:
#1: Core#0 flushes the write buffer, L1 cache, and L2 cache so that the L3 cache & memory location #500 is fully updated.
#2: Memory location #500 is pushed out from Core#0 L3 cache and pushed into Core#32 L3 cache. (Core#0 sets Location#500 to "Invalid", which allows Core#32 to set Location#500 to Exclusive).
#3: Core#32 L3 cache then transfers the data to L2, L1, and finally is able to be read by core#32.
--------
EDIT: Step #1 is missing when you read from DDR4 RAM. So DDR4 RAM reads under the Zen and Zen2 architecture are faster than remote L3 reads. An interesting quirk for sure.
In practice, Zen / Zen2's quirk doesn't seem to be a big deal for a large number of workloads (especially cloud servers / VMs). Databases are the only major workload I'm aware of where this really becomes a huge issue.
Are there workloads where the AMD suffers due to its l3 design? Maybe, but I've not seen one yet. I would imagine something special like that you could try to arrange thread affinity to avoid non local l3 accesses.
On my 3900x L3 latency is 10.4ns when local.
Databases, particularly any database which benefits from more than 16MB of L3 cache.
> On my 3900x L3 latency is 10.4ns when local.
And L3 latency is >100ns when off-die. Remember, to keep memory cohesive, only one L3 cache can "own" data. You gotta wait for the "other core" to give up the data before you can load it into YOUR L3 cache and start writing to it.
Its clear that AMD has a very good cache-coherence system to mitigate the problem (aka: Infinity Fabric), but you can't get around the fundamental fact that a core only really has 16MB of L3 cache.
Intel systems can have all of its L3 cache work on all of its cores, which greatly benefits database applications.
---------
AMD Zen (and Zen2) is designed for cloud-servers, where those "independent" bits of L3 cache are not really a big problem. Intel Xeon are designed for big servers which need to scale up.
With that being said, cloud-server VMs are the dominant architecture today, so AMD really did innovate here. But it doesn't change the fact that their systems have the "split L3" problem which affects databases and some other applications.
Yes but have you seen this actually measured, as being a net performance problem for AMD as compared to Intel, yet? I understand the theoretical concern.
Older (Zen 1), but you can see how even a AMD EPYC 7601 (32-core) is far slower than Intel Xeon Gold 6138 (20-core) in Postgres.
Apparently Java-benchmarks are also L3 cache heavy or something, because the Xeon Gold is faster in Java as well (at least, whatever Java benchmark Phoronix was running)
Look at PostgreSQL, where the split-L3 cache hampers the EPYC 7601's design.
As I stated earlier: in many workloads, the split-cache of EPYC seems to be a benfit. But in DATABASES, which is one major workload for any modern business, EPYC loses to a much weaker system.
However, I can't find any information on what MDOEFSI is. I'm assuming:
* Modified * Dirty * Owned * Exclusive * Forwarding * Shared * Invalid
Any information I look up comes up to an NDA-firewall pretty quickly (be it in performance counters, or hardware level documentation). It seems like AMD is highly protective of their coherency algorithm.
> That'd let you have multiple copies in different slices as long as you weren't mutating them.
Seems like the D(irty) state allows multiple copies to be mutated actually. But its still a "multiple copies" methodology. As any particular core comes up to the 8MB (Zen) or 16 MB (Zen2) limit, that's all they get. No way to have a singular dataset with 32MB of cache on Zen or Zen2.
- Intel staying low core count probably wasn't evil intent: the software wasn't there and Intel had better single thread perf than AMD. AMD was basically forced into more cores earlier because of weakness in single thread. Today, the software _is_ there (well, mostly) and we can all take advantage of more cores.
- Why did Intel fall behind? Easy: Brian Krzanich's hubris pushed the process too hard, taking many risks, and the strategy failed spectacularly.
- PCIe Gen4 does matter. M.2 NVMe has been read limited for a long time already (NAND bandwidth scales trivially). The I/O section of this article is basically nonsense.
- There's is nothing magical about x86, nor about the AMD and Intel design team. If the market is there, there will be competitive non-x86 alternatives. The data center market is pretty conservative for good reason - but ML is upending a lot of conventional wisdom so it'll be interesting to see what happens.
Strong disagree there, for threadripper and epyc products based on zen2. There's use cases for two and four port 100GbE PCI-Express NICs in 1RU and 2RU sized x86-64 platform systems where you definitely want as much pci-express bus bandwidth as possible.
In addition to the obvious use cases like people putting multiple nvme pci-express bus ssds in pci-express slots. At the low end of the price market things like a pci-express 3.0 x8 card that holds four m.2 2280 SSDs in a $18 part.
First generation single socket epyc was already a huge improvement in number of pci-express lanes per CPU socket compared to equivalently priced intel product, if you were, for example looking at building a 2RU system with eight or twelve 100GbE interfaces to run juniper JunOS as VMX.
In the single socket higher-end workstation CPU market ($400 to $800 CPUs) Intel has for a very long time had a constrained number of pci-express lanes available per motherboard. In a setup with a single high end video card like a 1080ti or 2080 and a single nvme SSD, it doesn't leave a whole lot of I/O lanes left over.
Samsung introduced a 8 GB/s SSD specifically for PCIe Gen4. I used to work in the SSD business many years ago and we could _trivially_ saturate PCIe Gen3 x4 but it wasn't economical to go to more lanes. (Bandwidth is easy, latency is hard).
One immediate benefit that comes to mind, is storage controllers. With 8x spinning disks, you might get away with using a single lane which can provide almost 2 GByte/s bandwidth. And controllers previously using 8xGen3 lanes could switch to 4xGen4 without any loss in performance.
I think the author's point was that storage is already plenty fast enough for many tasks. Personally, I cant feel the difference in storage performance between my NVMe system and older SATA SSD ones, despite NVMe being much faster.
There are "lots" of other subsets where it stopped mattering a while ago though.
IO matters but peak bandwidth sequential reads are not such a limiting factor even for power users.
That's because for the most common tasks, real performance had not improved.
Manufacturers always display the write/read speed using many cores and with huge queue depth. The typical use case for that is copying files. It's around 3000MB/s
When starting OS and loading program you have tasks that use low queue and thread count, which is about 60-70 MB/s.
> Manufacturers always display the write/read speed using many cores...
Why does #cores matter? Once the IO is initiated it's handed off to some DMA/coprocessor stuff so the core can get back to starting other IOs without contention. Being clueless I can't see why a single core couldn't saturate IO bandwidth by just blasting out IO requests.
> ...and with huge queue depth.
Really stupid question now, I thought disk queues were queued up requests caused by issuing a buttload of IO requests, so why does a disk queue of say 20 actually make things any faster over a disk queue of just 2?
I know (correction, believe) with spinny disks a longer queue could be used by the controller to optimise access on the disk surface by proximity, but with SSDs that performance characteristic doesn't exist (access is uniform anywhere, I think) so that optimisation doesn't apply.
If you're benchmarking 4kB IOs, then the system call and interrupt handling overhead means you can't keep a high-end NVMe SSD 100% busy with only a single CPU core issuing requests one at a time. The time it takes to move 4kB across a PCIe link is absolutely trivial compared to post-Spectre/Meltdown context switch times. A program performing random IO to a mmapped file will never stress the SSD as much as a program that submits batches of several IO requests using a low-overhead asynchronous IO API.
> so why does a disk queue of say 20 actually make things any faster over a disk queue of just 2?
Because unlike almost all hard drives, SSDs can actually work on more than one outstanding request at a time. Consumer SSDs use controllers with four or eight independent NAND flash memory channels. Enterprise SSD controllers are 8-32 channels. And there's some amount of parallelism available between NAND flash dies attached to the same channel, and between planes on an individual die. Also, for writes, SSDs will commonly buffer commands to be combined and issued with fewer actual NAND program operations.
One more thing, I'm surprised that 4KB blocks are relevant, I'd have thought that disk requests in benchmarking (edit: cos manufacturers like to cheat), and a lot of reads in the real world, would operate at much larger requests than 4K.
Is it that IOs are broken down to 4K blocks at the disc controller level, or is that done deliberately in benchmarking to stress the IO subsystem?
and higher IOPs numbers give the marketing department the warm and fuzzies. Got it.
For the tasks I do, this is night and day, and lack of NVMe is reason enough to warrant buying new hardware.
Performance tests here https://www.servethehome.com/amd-epyc-7002-series-rome-deliv...
Alongside Netburst development, Intel had the Israeli team develop a mobile first platform. The team took parts of the bus for Netburst and shit canned the rest if the design in favor of the Pentium III which they optimized the shit out of. They introduced concepts like microop fusion and developed the processor with the goal of sleeping whenever possible to conserve power.
The net result was the Banias platform which was incredibly efficient because it was incredibly fast. The original Core line was basically Banias with power saving turned off.
Itanium is often lazily pointed to as a failure by Intel, but in reality it was a hard task with decent execution.
Intel attempted to build an ecosystem around an entirely new architecture. Emphasis on smart-compiler extracted instruction level parallelism, supported by wide but less superscalar hardware. In 2001.
As an analogy, this is kind of like asking every driver to toggle a switch to manage the engine mapping while they drive. It could be more effective, but it's also a ton of work and relies on expertise being developed.
AMD delivered what the market really wanted in x64: something that looked exactly like x86, with a few modest improvements, and some 32-bit scaling limitations removed. But no big changes.
The Israeli teams are usually cited as the caretakers of the P6 (Pentium Pro) legacy, which evolved into the Pentium M, and eventually the Core architectures.
They chose to optimize for power efficiency, and so didn't hit the same power caps the Netburst team did.
Generally, the internet comments on this are armchair generaling with the benefit of hindsight. There are many reasons things could have gone differently.
Sometimes two teams work equally hard, but one chooses a path that leads to success and the other one that leads to failure.
Disagree. Not even "mostly". If I had a dime every time I saw some software stuck at 100% of one core... well, I'd have a few dimes a day.
In the business world, all the commonly-used software I can think of is heavily threaded as well. Generally, the remaining software that comes to mind is simple stuff that could run on a decade-old machine without too much trouble.
What typical programs are you running that require so much single-threaded performance?
Also old (and not-so-old) games.
Tried with Foxit and a few others, same thing. I had to seek indexed search apps, and those are few and far between and generally poor quality - kudos to Recoll[1] as the standout so far. But I'd much rather just search within the reader.
Anyway, it's infuriating, this should go about x times as fast as there are cores.
It probably does for a great many special use cases on servers or other specialty workloads. But for programming/gaming/normal productivity workloads it really doesn't. The net difference in load times/compile times/boot times is tiny even going from a cheap ssd to the latest pci4 ssds.
If you do huge sequential reads/writes, then yeah, large differences are getting unlocked.
They look at the military angle specifically ("Wall Street's short-term incentives have decimated our defense industrial base and undermined our national security.") but it's wider than that.
Example quotes:
> ...in the last 20 years, every single American producer of key telecommunication equipment sectors is gone. Today, only two European makers—Ericsson and Nokia—are left to compete with Huawei and another Chinese competitor, ZTE.
> ...public policies focused on finance instead of production, the United States increasingly cannot produce or maintain vital systems upon which our economy, our military, and our allies rely.
As for chip production capacity, "N. America" (is there anything in Canada or is this just "U.S."?), it's just 12.8% of worldwide capacity and 3/4 of capacity is in Asia: https://anysilicon.com/semiconductor-wafer-capacity-per-regi...
The idea of globalization was that where production is located does not matter, market "magic" somehow makes it irrelevant. I don't see how it does not matter when the imbalance becomes as extreme as it is nowadays. "Finance" is not an industry (if anyone wants to argue with me about the definition of that word I refer to https://www.lesswrong.com/posts/7X2j8HAkWdmMoS8PE/disputing-... -- you know what I mean).
It has been so long since something bad has happened that people believe it can't happen. Pax Americana can only last so long and with the way things are going right now it seems closer to its end than its beginning.
We need to re-learn to consume local products if we want to save this planet.
> Superfund sites are polluted locations in the United States requiring a long-term response to clean up hazardous material contaminations. They were designated under the Comprehensive Environmental Response, Compensation, and Liability Act (CERCLA) of 1980. CERCLA authorized the United States Environmental Protection Agency (EPA) to create a list of such locations, which are placed on the National Priorities List (NPL).
https://en.wikipedia.org/wiki/List_of_Superfund_sites
> Superfund is a United States federal government program designed to fund the cleanup of sites contaminated with hazardous substances and pollutants. Sites managed under this program are referred to as "Superfund" sites. It was established as the Comprehensive Environmental Response, Compensation, and Liability Act of 1980 (CERCLA).[1] It authorizes federal natural resource agencies, primarily the Environmental Protection Agency (EPA), states and Native American tribes to recover natural resource damages caused by hazardous substances, though most states have and most often use their own versions of CERCLA. CERCLA created the Agency for Toxic Substances and Disease Registry (ATSDR). The EPA may identify parties responsible for hazardous substances releases to the environment (polluters) and either compel them to clean up the sites, or it may undertake the cleanup on its own using the Superfund (a trust fund) and costs recovered from polluters by referring to the U.S. Department of Justice.
See also https://www.nytimes.com/2018/03/26/lens/the-superfund-sites-...
Arguments against free trade or trade “imbalance” are always one or more of the following: economically ignorant; mercantilist; racist; or nationalist. They all deny individual rights in favor of tribalism.
Should Intel really be considered a U.S. company these days?
I tend to consider companies like Intel (and IBM, and Apple, and Microsoft, etc.) international companies.
I'll repost a previous post I made
https://news.ycombinator.com/item?id=15484735 ------
To also give context as to what Dragonfly BSD is, DragonFly BSD was forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon over a differing of opinion on how to handle SMP support in FreeBSD. Dragonfly is generally consider as having a much simpler (and cleaning) implementation of SMP which has allowed the core team to more easily maintain SMP support; yet without sacrificing performance (numerous benchmarks demonstrate that Dragonfly is even more performant than FreeBSD [5]).
The core team of Dragonfly developers is small but extremely talented (e.g. they have frequently found hardware bugs in Intel/AMD that no one else has found in the Linux/BSD community [6]). They strive for correctness of code, ease of maintainability (e.g. only support x86 architecture, design decisions, etc.) and performance as project goals.
If you haven't already looked at Dragonfly, I highly recommend you to do so.
Good for AMD, but I'm more interested in an explanation of how Intel allowed this to happen.
It's a pattern you see over and over again.
With 10nm, it's years overdue (we're now on 14nm++++, if my count is right), and Intel's just been incrementally iterating on Skylake in the meanwhile.
I'm really looking forward to the next generation or two, when we see non-mobile 10nm+ chips from Intel and whether they can make up the lost ground between Spectre variants and AMD's gains.
People blame this on complacency (and there was definitely some of that, as internal reports have revealed) but it also has to do with their inability to execute on their 10nm process and the fact that they've got everything tied to in-house development; while AMD is able to execute a much more mercenary approach (mixing and matching node processes, sourcing to multiple fabs, utilizing open standards vs baking their own, etc).
I was a little surprised, but not shocked, that Intel's best reaction to the new AMD processors was so underwhelming.
Yet it's what we expect in most markets - and what happened after IE6 (or Chrome) won. Innovation stops, differentiation by anti-consumer means ramps up.
Couldn't it be both?
The decision to bet the company on 10nm came from the top (Krzanich).
If the entire company is dysfunctional, no amount of low-level work can undo that: if the captain runs the ship aground, adding more sailors bailing water doesn't get the ship to its port.
From the outside, Intel looks complacent. To a degree, that's true, but the inside story is more panic and confusion. The third-party vendors who provide the EUV tools are in panic mode. The leadership is in confusion mode (no amount of seppuku can make the old ways work; re-organizing those 2 levels of low-level managers can't fix this; top-down cannot turn back time and assume that 10nm will be this bad).
Consumers really only see the output of the product/sales division, such as which features to disable on which SKUs. Intel is facing an actual engineering failure; there are no bloody features to disable. Taking the few 10nm parts that made it out the door and sticking them in the 14nm "10th generation" is a product/sales decision. Ignoring the people telling you 10nm is a flop - that's a CEO level decision.
In all seriousness, it is a miracle Intel is able to compete at all.
Pros of higher headcount: theoretically lower transaction costs for highly specialized people to work together.
Cons of higher headcount: more command and control; fewer competing ideas; no market mechanism to evaluate the beat ideas; massively increased politics and executive jockeying; way more middle managers and fewer entrepreneurs; and continuing to invest in failed ventures. I’m sure there are many more cons.
I don't particularly like Intel, but that is Hardly a fair comparison.
TSMC 48K employees, and $13 - $15B R&D.
And even that is excluding all the ecosystem and tooling companies around TSMC. Compared to Intel which does it all by themselves. Not to mention Intel does way more than just CPU, GPU, also Memory, Network, Mobile, 5G, WiFi, FPGA, Storage Controller etc.
I am an AMD fan and my laptop is Ryzen, but I would not say AMD has already won. It is catching up fast, but they can't stop innovating.
What a great time to be in the market for a new machine, lots of hot air (literally) and throttling with the 6/8 core Intel i9s.
At 6-8 cores a 10nm with low base clock and decent boost speeds would probably be a decent option provided it doesn't throttle in the thin/light laptops of today.
Consumer is caught between worlds, the old power hungry one, and the new efficient one where long battery life and cool/quiet mobile systems are the norm (at least that's the hope).
idk, I got a Ryzen 5 HP Envy 15" last year, and am perfectly happy with it. Intel isn't 100% owning the laptop market right now.
This one was an anomaly and it doesn't feel fully supported by the Linux kernel, I have to add several parameters to the bootloader just to install Linux.
Next iterations should be better.
There's quote, something along the lines of "You have to cannibalise your own business. If you don't someone else will". A lesson intel chose to forget because it made them more money, right up until it didn't.
Still a great book and it was highly influential on how I think about business. He's also written a bunch of books after that book that may or may not cover some of those points.
Even if there were more serious issues, I would argue that AMD did the right thing keeping the AM4 socket. Since this varies from board to board, it's obviously not a deficit of the socket itself. At the end of the day, nobody is forcing you to keep your old motherboard. You just have the option to. If you can save 25% by not buying a new motherboard, it probably justifies a small performance deficit.
Well, that effect is there on Zen 1 to an extent, but you can overpower it with >1.4V.
<meta name="viewport" content="width=device-width, initial-scale=1">I actually used this template for an internal development tool and everyone loves how fast and simple it is.
- Users have reasonable window managers for non-maximized windows(they don't, they run windows mostly).
- Websites display text mostly that can flow nicely.
- Web browsers have one window per web page
A lesson on why CSS should be able to specify the nits and colorspace you’d like your content to be displayed in, so it can be readable on your shitty screen, and avoid giving me headaches on my screen.
Also, the color calibration AFAIK does not specify brightness. Perhaps the headaches are not from contrast, but from too much brightness?
Text becomes painful if the contrast is too high, but if you have a cheap screen at 70 nits it won't ever be an issue.
I picked up a tidbit about optimal line widths in one of my courses and it's stuck with me. I think back to it whenever I see websites that don't constrain the width.
Somewhere along the line people just want to make Web Apps, when the Apps itself is no different to a page.
[0] https://www.sinax.be/blog/general/guidelines-for-spartan-web...
A tiny bit of CSS would make it perfect
Users want a readable-width column in front of their eyes. That is: it shouldn't be full width, it has to have a max size that is smaller. And the column has to be centered because the left edge of a big screen is way too off center to read comfortably.
Agree on the minimalist design being a breath of fresh air though. Just needs a reasonable paragraph formatting and it's perfect.