2 ms·
It wasn't an interesting idea, it was a footgun. There's nothing naturally advantageous about the machine your process happens to be running on. In the era of v
by jeffbee 3y ago
It wasn't an interesting idea, it was a footgun. There's nothing naturally advantageous about the machine your process happens to be running on. In the era of very large machines there may be substantial contention for the block device that by coincidence is in the same chassis as your CPU.
- mbreese 3y agoIt was useful at the time though. Both network and disk were substantially slower at the time. And servers had far fewer cores. So which server stored the data could make your processing faster. And you’d have less risk for IO contention within the same chassis. Fast forward a few years and compute servers can have hundreds of cores and the network is significantly faster. I think it was a “good enough” design for the time and those assumptions. And batch processing. Now? I think there are different assumptions to be made. (And I think there is a good argument that by the time Hadoop/HDFS had stabilized the assumptions had already shifted)
- woooooo 3y agoIt's a footgun if your cluster is providing data/compute to other systems, absolutely, the case you mentioned is a risk worth extra network traffic to avoid. But theoretically, if we're trying to beat a benchmark or something, the "move compute to data" idea has something to it. Nobody transfers the LLM weights off of card memory, let alone to other machines for compute.