>Being a poorfag

File: 1467748746651.jpg (369KB, 1920x1200px) Image search: [Google]

369KB, 1920x1200px

>>58683099
>being irresponsible with cash is now something to be proud of

New money, Am I right?

>>58683206
Or he just has virtualization software that lets him emulate many cores and present them to a VM, above what the hardware actually has.

>>58683099
For all we k ow you booted a kvm instance with 56 virtual CPUs. Or 64. Or 128. It will just let you add them on willy nilly.

>>58683273
Yep

>What is smp cores=56

>Being a shitposting retard

>>58683099
And? We get servers in all the time with 48 cores, TB or RAM, nvme and raided SSDs for bulk storage. We install them, then they live out their life running boring pipelines. Day in. Day out. Forever.

They have more network bandwidth than a cheap laptop has memory bandwidth now.

And no even notices when they die, because the jobs just restart on another monster, while we rip apart the corpse for parts.

>>58683099
> almost a processor for every process
why would you even an OS scheduler? you should develop a schedulerless one for this beast

>>58683343

>merika'

>>58683099
what's the alternative? having a boss?

>>58683099
oh yeah ? I got a seven billion cores processor with one million thz speed it cost ten times Norway's gdp and not even the most powerful chinese supercomputer can come to a tenth of its power

you poorfag cuck mcdolan slave

> he believes I didn't choose it

>>58683510
From experience, these are often used for VMs/containers that spin up for a job, then get torn down immediately. So it's like the main os scheduler schedules huge processes that are KVM instances, and the OS scheduler in those schedules docker containers, and in that it runs shitty python with braindead multiprocess scheduling attempts written by webdevs, which hammer away at some other DB on the network, mostly repeating queries they don't need to do, and eventually saving the output of the job to it. And you can never get the webdev to fix the fact they're doing gigantic queries at each step in the loop, despite the data guaranteed to never change during a given job. And they insist that the DB is slowing them down, and you show them where they have un-indexed tables, and show them the performance gains from a simple index, and they claim the speedup as their work during the next sprint planning.

I mean, it's schedulers all the way down man.