331–340 of 431 posts
Earlier quoted context omitted.
Wasn’t the issue that the whole industry did a joint venture, but Intel decided to go it alone? I worked at a site (in a unrelated industry) where there was a lot of collaborative semiconductor stuff going on, and the only logo “missing” was Intel.
Didn't Samsung also go it alone, or am I mistaken?
Earlier quoted context omitted.
Building server software on Graviton ARM creates a vendor lock-in to Amazon, with very high costs of switching elsewhere. Despite using A64 ISA and ARM’s cores, they are Amazon’s proprietary chips no one else has access to. Migrating elsewhere gonna be very expensive. I wouldn’t be surprised if they sponsor their Graviton offering taking profits elsewhere. This might make it seem like a good deal for customers, but I…
Ubuntu 64 looks the same on Graviton as on a Raspberry Pi. You can take a binary you've compiled on the RPi, scp it to the Graviton instance and it will just run. That works the other way round too, which is great for speedy Pi software builds without having to set up a cross-compile environment.
Cross compilation is no big deal these days. Embedded devs cross compile to ARM all day every day.
The tooling will be there when it needs to be.
What was "the memory crash of 1984"?
Earlier quoted context omitted.
> We actually have a lot of insight in that Intel still doesn't have a good grasp on the problem. Their 10nm was supposed to enter volume production in mid 2018, and they still haven't truly entered volume production today. Additionally Intel announced in July 2020 that their 7nm is delayed by at least a year which means they figured out their node delay problem. Knowing something happened is not the same as knowing…
I think it's just a difficult problem. Intel is trying to do 10 nm without EUV. TSMC never solved that problem because they switched to EUV at that node size.
Earlier quoted context omitted.
Where are you getting your M1 CPU + memory controller is about a third of the M1 die from? Looking at this die shot + annotation: https://images.anandtech.com/doci/16226/M1.png The firestorm cores + 12MB cache is far less than 1/3rd the die, and the memory controller doesn't look particularly large. The M1 total is 16B transistors. A 2700K on Intel's 32nm was 1.1B transistors. You're "only" talking something like ~4x…
I was looking at the same image. A very large part of the die is not labelled and it must include some blocks that cannot be omitted from the CPU, e.g. the PCIe controller and various parts from the memory controller, e.g. buffers and prefetchers. The area labelled for the memory channels seems to contain just the physical interfaces for the memory, that is why it is small. The complete memory controller must include…
Where are you getting that scaling from? Intel's 32nm is reported at 7.5Mtr/mm2 while TSMC's 5NM is 171Mtr/mm2. 30 sqmm of TSMC 5nm in 32nm would therefore be around 660 sqmm. That's definitely on the large side, but yet again chips nearly that large were manufactured & sold in consumer products.
> A very large part of the die is not labelled and it must include some blocks that cannot be omitted from the CPU, e.g. the PCIe controller and various parts from the memory controller, e.g. buffers and prefetchers.
You need those things to have a functional modern SoC, but you don't need as much or of the same thing to have just a desktop CPU without an iGPU, nor to have just the raw compute performance of the M1. It'll be a heck of a lot harder to feed it on dual-channel DDR3, for sure, but all those canned benchmarks that fit in cache would still be just as fast.
Earlier quoted context omitted.
I can see this happening for things that run in entirely managed environments but I don't think AWS can make the switch fully until that exact hardware is on people's benches. Doing microbenchmarking is quite awkward on the cloud, whereas anyone with a Linux laptop from the last 20 years can access PMCs for their hardware
Very little user code generates binaries that can _tell_ it is running on non-x86 hardware. Rust is Arm Memory Model safe, existing C/C++ code that targets the x86 memory model is slowly getting ported over, but unless you are writing multithreaded C++ code that cuts corners it isn't an issue. Running on the JVM, Ruby, Python, Go, Dlang, Swift, Julia or Rust and you won't notice a difference. It will be sooner than y…
Earlier quoted context omitted.
"The vast majority of developers never profile their code." Protip: New on the job and want to establish a reputation quickly? Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent. Another bit of evidence developers rarely profile their code is that I can tell my mental model of how expensive some…
> Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent. I've found that a profiler isn't even needed to find significant wins in most codebases. Simple inspection of the code and removal of obviously slow or inefficient code paths can often lead to huge performance gains.
It’s so painful to behold.
Binary formats converted to JSON blobs, each bigger than my first hard drive (!), and then back again, often multiple times in the same process.
> And in that planning the fact that TSMC’s foundries — and Samsung’s — are within easy reach of Chinese missiles is a major issue. Are processor fabs analagous to auto factories and shipyards in World War II? Is the United States military's plan for a nuclear exchange with China dependent on a steady supply of cutting edge semiconductors? Even if it is, is that strategy really going to help? This article is mostly c…
I don't feel that there is a meaningful TSMC alternative today. Samsung, Intel and GlobalFoundries are not suitable replacements for TSMC with regards to throughput or technology. The world does need some meaningful fabs outside of Taiwan/South Korea. All of the 10nm semiconductor fabrication takes place within a 750km/460mile radius circle today. That is risky. Israel, Mexico, Germany, Canada, Japan (not that it wou…
Earlier quoted context omitted.
> I have a MBP, as do all of my engineers. Within a few years all of these machines will age out and be replaced with m1 powered machines. At that point the idea of developing on ARM and deploying on x86 will be unpleasant Is it not at least somewhat possible that at least some of those Apple laptops will age out and be replaced with GNU/Linux laptops? Agreed that developing on ARM and deploying on x86 is unpleasant,…
I develop on GNU/Linux begrudgingly. It has all of my tools, but I have a never-ending stream of issues with WiFi, display, audio, etc. As far as I'm concerned, GNU/Linux is something that's meant to be used headless and ssh'd into.
I had already decided that 2021 would be my year of the Linux desktop, but Apple forced my hand a bit early. My 2019 Mac’s WiFi went. Had to lose my primary dev machine for over a week as it shipped out to have a bunch of hardware replaced.
So, I built a PC with parts that have good Linux support. I think that’s the key. I imagine System76 machines would run smoothly. It’s definitely not as smooth a UX as Mac, but I like being in an open ecosystem on a machine I can repair. And it’s had a number of perks such Docker running efficiently for once.
Edit: I can now trivially repair my computer if it breaks. The entire rig cost about 1/4 what my MacBook cost, and it is much faster.
What was "the memory crash of 1984"?
Intel tried to maintain a competitive advantage and introduced several innovative technology design efforts with its next generation DRAM offerings. These products did not provide enough competitive advantage, thus the company lost its strategic position in the DRAM market over time. Intel declined from an 82.9% market share in 1974 to a paltry 1.3% share in 1984.
Intel’s serendipitous and fortuitous entry into microprocessors happened when Busicom, a Japanese calculator company, contacted Intel for the development of a new chipset. Intel developed the microprocessor but the design was owned by Busicom. Legendary Intel employee Ted Hoff had the foresight to lobby top management to buy back the design for uses in non calculator devices. The microprocessor became an important source of sales revenue for Intel, eventually displacing DRAMs as the number one business.
https://anthonysmoak.com/2016/03/27/andy-grove-and-intels-mo...