Threadripper 32 core review

Groo (charlie.delete@this.semiaccurate.com) on August 13, 2018 4:50 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 13, 2018 3:48 pm wrote:
>
>
> All that said if I were you I would get an Epyc instead, it has 8 channel memory as opposed to the
> four in Threadripper. Compiles may not use it but I am sure you will have workloads that can.
>

I'd have suggested the eight channels, but still a baby threadripper is closer to what ordinary joe's might have stored in their basements at home, or underneath their desks at works. And correct me if I've wrong, but it's it part of the philosophy of the software engineers/architects to try and stay as close as possible to the baseline of what is out there in greatest numbers? The 'bog standard' point, that Linus always comes back to. I thought this was the best insight I've got into Threadripper's purpose (and okay, four memory channels, is only four). Gordon Mah Ung, tried to get a bit of a handle on how the threadripper systems were intended to be used, by simulating a load that is more typical of how people will work with the actual systems. Around the 16:00 minute here.

A few years back, the big news in desktops, was Microsoft and Intel trying to bring server OS type of virtual machine capability, down on to consumer level with Windows 8.0 onward. That was the value proposition back then. This is an entirely different value proposition - may not be as useful as virtualization hardware and OS - promised to be back then, for a lot of folk, and still is.

What we're looking at really, is the ability of the modern operating system (Windows, Linux, whatever), to be able to access,... not 'two cores', or multiple cores,... but more accurately, two essentially separate and distinct, well provisioned multi-core machines,... that just both happen to be contained inside of the same operating system. It's the flip flop of what we're trying to do with virtual machines basically. Instead of trying to fit multiple VM's on the one box. We're trying to fit more than one box, into the one operating system instance. The kinds of productivity loads that Gordon Mah Ung simulated above, were equivalent to the kinds of workloads that one might see put on two separate virtual machines, if one was using 'the cloud' to do the work load. But here, we're talking about engineers who are looking at two massively parallel, but entirely un-attached and un-related workloads, effectively working off the same desktop.

The only thing that can go wrong there, is that the desktop OS tears apart and collapses from underneath you, mid-course. And apparently it didn't. Previously, the focus was on running separate services inside of different VM's in order to increase security in general. This is going in the opposite direction, where engineers are trying to fit more and more, in the same operating system instance. It's a horse of a different color. Time will tell if whether it's a new departure for desktop computing or not. But it's definitely something that needs a new name for it, other than what we used to call 'multi-tasking' in the past. Multi-tasking was a bit less extreme, than what we're looking at here.