The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags.
When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything".
Trying to scope that down using arguments of the form "but what the hardware does is X" are fundamentally flawed, because anything means anything, and what the hardware does doesn't change that, and therefore it doesn't matter.
This blogpost "What The Hardware Does is not What Your Program Does" explains this in more detail and with more examples.
From the POV of an HPC cluster user, when using SLURM's `srun` or similar to schedule a job, this now allows you to use `srun --container=<your container>`, and it will start each node where you app run using the container, and make sure MPI, GPUs, etc, all work.
If you don't know anything about containers, it probably will be a bit hard to imagine what this buys you, but don't worry, as more clusters start moving towards this model, you'll have to learn about containers at some point.
From the POV of the HPC cluster, it means that the `module` system can be replaced with containers, and that can significantly lower the maintenance overhead of the cluster. In a sense, it turns HPC cluster users into HPC cluster maintainers (that have to build their own images, preparing their own environment, etc).
The article touches on this, since its an important realization. In C, however, if the integers are not unsigned, the add/sub version exhibits UB on overflow, because C unnecessarily ties signed/unsignedness with overflow behavior (UB, two's complement, etc.).
Not that this is important, but could hint why this trick is more often shown with XOR than with add/sub.
Memory became less of an issue for me with V100, and isn't really an issue with A100, at least when quickly iterating for newer models, when the sizes are still relatively small.
> The challenge is selecting the tests that best represent the typical ML/DL use cases for the M1 and comparing it to an alternative such as the V100 using a common toolchain like Tensorflow.
The benchmarks there are actual applications of ML, that people use to solve real world problems. To get a benchmark accepted you need to argue and convince people that the problem the benchmark solves must be solved by a lot of people, and that doing so burns enough cycles worldwide to be helpful to design ML hardware and software.
The hardware and software then gets developed to make solving these problems fast, which then in turns make real-world applications of ML fast.
Suggesting that the M1 is a solution, and now we just need to find a good problem that this solution solves well and add it there as a benchmark is the opposite to how mlperf works, and hardware vendors suggesting this is the reason mlperf exists. We already have common ML problems that a lot of people need to solve. Either the M1 is good at those or it isn't. If it isn't, it should become better at those. Being better at problems people don't want / need to solve does not help anybody.
Depends on model size, but if the model is small enough that I actually do training on a PCIe board, I do. I partition an A100 in 8, and train 8 models at a time, or just use MPS on a V100 board. The bigger A100 boards can fit multiple of the same models that do fit in a single V100..
Also I tend to do this initially, when I am exploring the hyperparameter space, for which I tend to use smaller but more models.
I find that using big models initially is just a waste of time. You want to try many things as quickly as possible.
> Just look at the result Google gets with BERT on V100s vs the result NVIDIA gets with V100s.
These benchmarks measure the combination of hardware+software to solve a problem.
Google and NVIDIA are using the same hardware, but their software implementation is different.
---
The reason mlperf.org exists is to have a meaningful set of relevant practical ML problems that can be used to compare and improve hardware and software for ML.
For any piece of hardware, you can create an ML benchmark that's irrelevant in practice, but perform much better on that hardware than the competition. That's what we used to have before mlperf.org was a thing.
When developing ML models, you rarely train "just one".
The article mentions that they explored a not-so-large hyper-parameter space (i.e. they trained multiple models with different parameters each).
It would be interesting to know how long does the whole process takes on the M1 vs the V100.
For the small models covered in the article, I'd guess that the V100 can train them all concurrently using MPS (multi-process service: multiple processes can concurrently use the GPU).
In particular it would be interesting to know, whether the V100 trains all models in the same time that it trains one, and whether the M1 does the same, or whether the M1 takes N times more time to train N models.
This could paint a completely different picture, particularly for the user perspective. When I go for lunch, coffee, or home, I usually spawn jobs training a large number of models, such that when I get back, all these models are trained.
I only start training a small number of models at the latter phases of development, when I have already explored a large part of the model space.
---
To make the analogy, what this article is doing is something similar to benchmarking a 64 core CPU against a 1 core CPU using a single threaded benchmark. The 64 core CPU happens to be slightly beefier and faster than the 1 core CPU, but it is more expensive and consumes more power because... it has 64x more cores. So to put things in perspective, it would make sense to also show a benchmark that can use 64x cores, which is the reason somebody would buy a 64-core CPU, and see how the single-core one compares (typically 64x slower).
---
To me, the only news here is that Apple GPU cores are not very far behind NVIDIA's cores for ML training, but there is much more to a GPGPU than just the perf that you get for small models in a small number of cores. Apple would still need to (1) catch up, and (2) extremely scale up their design. They probably can do both if they set their eyes on it. Exciting times.
Just run their benchmarks. Submitting your results there is a bit more complicated, because all results there are "verified" by independent entities.
If you feel like your AI use case is not well represented by any of the MLPerf benchmarks, open a discussion thread about it, propose a new benchmark, etc.
The set of benchmarks there increases all the time to cover new applications. For example, on top of the MLPerf Training and MLPerf Inference benchmark suites, we now have a new MLPerf HPC suite to capture ML of very large models.
IIUC the goal of the Alabama factory is to work around the existing tarifs on shipping planes to the US. Instead of shipping the planes, Airbus ships the parts, and assembles them in the US, thus avoiding the plane tarifs. So now there are tariffs on "plane parts".
Maybe they'll just stop doing this, close the factory, and ship whole planes from the EU again. Depends what the difference is in the plane and plane parts tariff, and whats more worth it.
> The tariff will have a significant effect on production of the Airbus A320 in Mobile, Alabama, something which Airbus has claimed will only hurt US workers.
How will this hurt US workers?
Sounds like this is suggesting that either they will pay the workers less to compensate, or maybe even move the factory elsewhere to avoid the tariffs (moving the factory to mexico might mean the tariffs disappear until new tariffs against shipping planes from mexico get approved, which might take some time).
The EU is not a country nor a federation. Companies that want to operate in EU countries need to abide by each countries laws. The EU just provide a minimum set of laws that must be abided by all countries, but that's pretty much it. Each country uses these laws as a base, and provides its own super set of laws on top.
The EU doesn't really have many tax regulations, so a country like Ireland might think "How else will I attract industry here?", and decide to allow companies to put a mailbox there in exchange for operating in the EU tax free.
This double-screws all other countries, first, because these companies pay zero taxes, so their tax contribution to the EU is zero. Second, because Ireland remains poor, because these companies pay almost zero taxes, so other countries need to send them money.
France didn't like this, so they introduced a tax that both French and non-French companies must pay (it is illegal in the EU to discriminate by country, so this tax affects French companies as well).
And that's pretty much it. This tax is high because it needs to compensate for the lack of taxes these companies pay in France, and for the money France needs to send to the tax heavens in which these companies operate.
TBH I hope other EU countries will follow France's example, and that at some point, when most countries have these rules in place to avoid getting double-screwed, the EU as a whole can agree on a set of regulations to forbid tax heavens within the EU.
Such a set of regulations needs a pretty high buy in from all EU countries (essentially unanimous consensus), and countries that cannot otherwise attract industry are incentivized to be against it.
With these new taxes, Tech companies will be more incentivized to move to the places in which it makes most physical sense for them to be, instead of a freaking mailbox in the artic. At that point, the incentive from Ireland and other tax heavens will be small, since there won't be any point for companies to move there in the first place.
---
Also, while the EU usually negotiates as a front, the EU itself is a union, so it has little to absolutely no power over what any EU country does. Within the union, you have federation republics like Germany, presidental republics like France, monarchies with kings like Spain, and... without really stretching it... some EU countries aren't even democracies and are more like dictatorships. Point being, getting something done at the EU level requires widespread consensus, but the EU is extremely heterogeneous and consensus is really hard, which is why the EU gets nothing done, and why each country does whatever it wants. The EU doesn't even have a constitution.
It might be easy to criticize, e.g., the federal response to COVID in the US, but that's because people actually expected a Federal response to it, because there could have been one. In the EU, the federal response was almost non-existent, but nobody expected any because the EU has no power to do anything in this case. I don't really know whats worse.
That's because the company started dying longer ago.
Their stock price today is around 30$. In the early 2000s it was around 90$.
Also, like the other comment mentioned, HD has been playing a lot of financial tricks over the last 20 years to prevent the stock price from declining (e.g. buy backs to artificially inflate stock price, take a look at the number of outstanding shares: https://www.macrotrends.net/stocks/charts/HOG/harley-davidso... , a reduction from 280 million to 150 million in the 2005-2019 time period).
When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything".
Trying to scope that down using arguments of the form "but what the hardware does is X" are fundamentally flawed, because anything means anything, and what the hardware does doesn't change that, and therefore it doesn't matter.
This blogpost "What The Hardware Does is not What Your Program Does" explains this in more detail and with more examples.
https://www.ralfj.de/blog/2019/07/14/uninit.html