On Sat, 16 Mar 2019 07:11:31 -0500 Dan Sommers <2QdxY4RzWzUUiLuE@xxxxxxxxxxxxxxxxx> wrote: > On 3/16/19 7:03 AM, pete via arch-general wrote: > > > What would be the Reason for the change to a slower less efficient > > method apart from it may be someones pet toy .. > > It's only less efficient because networks are more faster > than CPUs. If I had a *multi-terabit* per second network, > and multi-*kilohertz* 8-bit CPUs on both ends, then zstd > might be more efficient for the whole compress, transmit, > decompress cycle. > > Arch can potentially control the CPU at the servers, but > neither the network(s) nor the user's CPUs, which means > that I'm agreeing with your conclusion rather than your > premise. :-) Yeah, it's the CPU processing itself that's the bottle neck, and more importantly, one CPU cache miss and it's taking that flight from Pluto to the center of the sun and back. All to retrieve some forgotten data.
