7 ms·

> it’s not clear to me whether a container can take advantage of the same CPU and GPU instruction optimizations that a binary or compiled-from-source version

> it’s not clear to me whether a container can take advantage of the same CPU and GPU instruction optimizations that a binary or compiled-from-source version can. Since the container is running on the bare metal, with the same kernel and everything, just isolated, it absolutely can take advantage of these things. It'll require about the same amount of work to do the compilation for using any special instructions for performance as it would if it's on bare metal. > For example, I’m curious if containers package redundant versions of software for convenience that are underoptimized when compared to versions packaged with the operating system. Is that realistic concern? Maybe. It'll mean that there's extra data on disk and maybe in ram from loading other shared libraries which will mean some overhead, but unless there's some specific set of instructions or optimizations that would make a difference for the workload it should be basically the same.

derefr 9y ago
> unless there's some specific set of instructions or optimizations that would make a difference for the workload I think this was the parent's worry. Most HPC deployments have versions of libc, libm, etc. compiled with tuning flags specific to the microarchitecture of the system, to allow workloads deployed on them to squeeze as much performance as possible out of the system. I would worry that the versions of libraries in the container are just the generic packages that ship with the OS, compiled with -march=i686 or whatever the modern equivalent is, where they don't try to take advantage of e.g. AVX512 instructions if they're available.
- malux85 9y ago
  Yes you’re 100% correct, but if you’re using a well tuned GPU Deep Learning pipeline the bottleneck is GPU compute and the CPU is always waiting on the GPU. It can be a bit tricky to optimise this though - some deep learning users do things like resizing images on the fly, or on the fly vectorising / scaling of input data in these cases the CPU can be the bottleneck and the optimisations above can help - but this is largely a symptom of a poor pipeline configuration in newbie shops, most serious places have optimised this away and the GPU is the bottleneck
- dsacco 9y ago
  > I would worry that the versions of libraries in the container are just the generic packages that ship with the OS, compiled with -march=i686 or whatever the modern equivalent is, where they don't try to take advantage of e.g. AVX512 instructions if they're available. That was essentially my worry, yes. Thanks for clarifying.

derefr 9y ago

> unless there's some specific set of instructions or optimizations that would make a difference for the workload I think this was the parent's worry. Most HPC deployments have versions of libc, libm, etc. compiled with tuning flags specific to the microarchitecture of the system, to allow workloads deployed on them to squeeze as much performance as possible out of the system. I would worry that the versions of libraries in the container are just the generic packages that ship with the OS, compiled with -march=i686 or whatever the modern equivalent is, where they don't try to take advantage of e.g. AVX512 instructions if they're available.

malux85 9y ago
Yes you’re 100% correct, but if you’re using a well tuned GPU Deep Learning pipeline the bottleneck is GPU compute and the CPU is always waiting on the GPU. It can be a bit tricky to optimise this though - some deep learning users do things like resizing images on the fly, or on the fly vectorising / scaling of input data in these cases the CPU can be the bottleneck and the optimisations above can help - but this is largely a symptom of a poor pipeline configuration in newbie shops, most serious places have optimised this away and the GPU is the bottleneck
dsacco 9y ago
> I would worry that the versions of libraries in the container are just the generic packages that ship with the OS, compiled with -march=i686 or whatever the modern equivalent is, where they don't try to take advantage of e.g. AVX512 instructions if they're available. That was essentially my worry, yes. Thanks for clarifying.