10 ms·
Intel Distribution for Python
- vitorsr 5y agoYou can easily try it yourself [1]: conda create -n intel -c intel intel::intelpython3_core Or [2]: docker pull intelpython/intelpython3_core Note that it is quite bloated but includes many high-quality libraries. You can think of it as a recompilation in addition to a collection of patches to make use of their proprietary libraries. Other useful links to reduce the noise in this thread: [3], [4], [5], [6]. [1] https://software.intel.com/content/www/us/en/develop/articles/using-intel-distribution-for-python-with-anaconda.html https://software.intel.com/content/www/us/en/develop/article... [2] https://software.intel.com/content/www/us/en/develop/articles/containers/python-core.html https://software.intel.com/content/www/us/en/develop/article... [3] https://www.nersc.gov/assets/Uploads/IntelPython-NERSC.pdf https://www.nersc.gov/assets/Uploads/IntelPython-NERSC.pdf [4] https://hub.docker.com/u/intelpython https://hub.docker.com/u/intelpython [5] https://anaconda.org/intel https://anaconda.org/intel [6] https://github.com/IntelPython https://github.com/IntelPython
- tkinom 5y agoAny benchmarks comparison data? For example: .... benchmarks with this python is XXX % higher than ... (std python, AMD, ARM)
- mumblemumble 5y agoI haven't done a comparison in a long time, and, even then, it wasn't very thorough, so take this with a grain of salt. But, 6 years ago, when I was in grad school, just swapping to the Intel build of numpy was an instant ~10x speedup in the machine learning pipeline I was working on at the time. No idea if that's typical or specific to what I was doing at the time. I don't use MKL anymore because ops doesn't want to deal with it and the standard packages are already plenty good enough for what I'm doing nowadays. If you forced me to guess, I guess I'd have to guess that my experience was atypical.
- rshm 5y agoLooks like recompilation. I am guessing gains are on numpy and scipy. For python heavy code base, i doubt it can be performant than pypy.
- amelius 5y agoMaybe I'm missing something but it seems to me that this can only cause fragmentation in the Python space. Why not use the original distributions?
- lbhdc 5y agoThere are a number of alternate interpreters available. The selling point typically is that they are faster, and seems to be the value proposition of intels. One use might be improving throughput of a compute bound system, like an etl written in python, with little effort. Ideally just downloading the new interpreter.
- amelius 5y agoOk. If they offer Python without the GIL then I'm all ears :)
- gautamdivgi 5y agoI don't think python is ever going to get rid of the GIL. I haven't looked but there's two things that may speed things up quite a bit: - Use native types - Provide the ability to turn "off" the GIL if you know you will not be using multi-threading within a process. I guess that is my naive wish list for a short term speed up :)
- _joel 5y agoWhy are they making their own distro and not putting code back into mainline if it's useful? Do they have some particular IP that makes this impossibe?
- SkipperCat 5y agoI think there is a pretty big base of people who do big data work using Numpy and Pandas (Fintech, etc). They want to squeeze every bit of computing power out of the specific Intel chipset, GPUs, etc and Intel's distro really helps them out. A 10% speed improvement on 1000's of jobs could in theory save you a nice chunk of time. This becomes very important in the financial market where you need batch jobs to be finished before markets open, or you just want to save 10% on your EC2 bill.
- gnufx 5y ago10% is around the noise level for HPC, especially for throughput depending on scheduling. I rather doubt you couldn't do the same as free software.
- Sanguinaire 5y agoYou are correct, nothing Intel provides in their Python distro cannot be obtained elsewhere - this is just a nice wrapper.
- pjmlp 5y agoYet plenty of HPC installations rather use IBM's xl or NVidia's PGI compiler suits. So they definitly don't agree you can do the same with free software.
- gnufx 5y agoThey may or may not disagree on the basis of measured performance in different cases. (The US labs are investing heavily in free software LLVM.) Often not with ifort, at least. However, I was talking about the Intel stuff, and partly from experience with R versus the Microsoft version. However, I recently ran the Polyhedron Fortran benchmarks with the compilers to hand (~2020 vintage). XL (on POWER) was the only one that gave a significantly better bottom line; obviously IBM know how to compile Fortran well by now (or by Fortran-H). As far as I remember, that was essentially due to the treatment (vectorization) of maths intrinsics, which probably aren't so dominant in typical HPC code. One bad case -- fmod inlining -- has since been fixed in GCC. Without GCC's unfortunate longstanding failure to vectorize sincos (or equivalent), gfortran should have beaten ifort significantly in the bottom line, and at least got close to XLF. PGI was distinctly worse than GCC, but may do better at OpenACC/GPU offload, for instance. XL may win on OpenMP, since some of the current standard was for Sierra's needs. I should find time for the NAS benchmarks.
- mushufasa 5y agoThere is a longstanding issue around MKL and OpenBLAS optimization flags making intel systems artificially faster than amd ones for numpy computations. https://stackoverflow.com/questions/62783262/why-is-numpy-with-ryzen-threadripper-so-much-slower-than-xeon https://stackoverflow.com/questions/62783262/why-is-numpy-wi... If there are true optimizations to be had, wonderful. But those should be added to core binaries pypi / conda. I am worried that Intel here may be trying to again artificially segment their optimization work on their math libraries for business rather than technical reasons.
- jxy 5y agoThat SO performance benchmark would be so much more useful if the OP had also run OpenBlas on the xeon.
- thunkshift1 5y agoWhat do you mean by ‘artificially faster’?
- jchw 5y agoIntel libraries whitelist their own CPUs for using certain extension instruction sets, instead of using the relevant CPU ID feature flag for that feature as their own documentation tells you to.
- jeffbee 5y agoCPUID is insufficient. CPUID can tell you that a CPU has a working PDEP/PEXT, but it can't tell you that a CPU's PDEP sucks like the one on all AMD processors prior to Zen3.
- sitkack 5y agoThe real answer is to do feature probing and benchmarking the underlying implementation. In the cloud you never really know the hardware backing your instance.
- 5y ago
- bananaquant 5y agoQuite unsurprisingly, this distribution has no support for ARM: https://software.intel.com/content/www/us/en/develop/articles/intel-oneapi-ai-analytics-toolkit-system-requirements.html https://software.intel.com/content/www/us/en/develop/article... I once was excited about Intel releasing their own Linux distro (Clear Linux), but it has the same problem. It looks like Intel is trying to make custom optimized versions of popular open-source projects just to get people to use their CPUs, as they lose their leadership in hardware.
- smoldesu 5y ago"Their" CPUs meaning x86 platforms, in this case. Plus, who's surprised? This is how Intel makes money. The consumer segment is a plaything for them, the real high-rollers are in the server segment, where they butter them up with fancy technology and the finest digital linens. Is it dumb? A little, but it's hardly a "problem" unless you intended to ship this software on first-party hardware which, hint-hint, the license forbids in the first place. At the end of the day, this doesn't really irk me. I can buy a compatible processor for less than $50, that's accessible enough.
- klelatti 5y agoLink says Core Gen 10 or Xeon so you may be out of luck on AMD or at less than $50. I think this is more likely aimed at AMD than Arm - don't think Arm is yet a threat in this space - and whilst they're entitled to do what they want it does make me less enthused about Intel and frankly more likely to support their competitors.
- mumblemumble 5y agoAMD has their own equivalent: https://developer.amd.com/amd-aocl/ https://developer.amd.com/amd-aocl/ I'm not sure it's a sin for hardware manufacturers to support their products? In the days of yore, we even expected it of them.
- gnufx 5y ago
- TOMDM 5y agoTo me this just looks like Intel saw what Nvidia has accomplished with CUDA, locking in large portions of the scientific computing community with a hardware specific API and going "yeah me too thanks" Thankfully, accelerated math libraries already exist for Python without the vendor lockin.
- bostonsre 5y agoIntel has been releasing mkl/math kernel libraries for Java for a really long time. Hopefully core python devs can learn a few tricks and similar changes can make it upstream.
- agloeregrets 5y agoI wonder who the person is who saw python and was like "You know what this needs? INTEL."
- RocketSyntax 5y agois there a pip package?
- ciupicri 5y agoPython 3.7.4 when 3.10 is just around the block.
- gnufx 5y agoI don't know what Intel did for the proprietary version, but the first thing you should do for Python is to compile with GCC's -fno-semantic-interposition. I don't know if there's a benefit from vectorization, for instance, in parts of the interpreter, or whether -Ofast helps generally if so, but I doubt there's anything Intel CPU-specific involved if there is. I've never looked at it, has the interpreter not been well-profiled and such optimizations provided? Anyway, if you want speed, don't use Python. It's obviously not relevant to Python per se, but you get basically equivalent performance to MKL with OpenBLAS or, perhaps, BLIS, possibly with libxsmm on x86. BLIS may do better on operations other than {s,d}gemm, and/or threaded, than OpenBLAS, but they're both generally competitive.
- Rd6n6 5y ago> the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.[1] I’ve been a little shy about using intel software since reading about this years ago [1] https://www.agner.org/optimize/blog/read.php?i=49 https://www.agner.org/optimize/blog/read.php?i=49
- SavantIdiot 5y agoThat's just plain sinister. I'm really surprised popular numerical computing Python packages don't already have optimized hardware back-ends for things like NumPy... similar to ORC (OIL) which has been around for quite some time: https://github.com/GStreamer/orc https://github.com/GStreamer/orc But I don't know that much about Python under the hood, and I'm willing to be since so many academics work on this there's already optimized FFIs. I've used TensorFlow and it can offload tensor math to GPUs, but only NVIDIA's AFAIK.
- danieldk 5y agoI'm really surprised popular numerical computing Python packages don't already have optimized hardware back-ends for things like NumPy I think it is hard to beat modern BLAS implementations for common operations. E.g. Apple Accelerate (which also implement the BLAS/LAPACK APIs) uses undocumented AMX instructions for large speedups compared to an ARM NEON implementation.
- deleted 5y ago[deleted]
- danieldk 5y agoThis has gotten a bit better. Last time I checked, MKL now uses Zen-specific kernels for sgemm/dgemm. Unfortunately, these kernels are slower than the AVX2 kernels. But at least, it does not use the pre-modern SIMD kernels for AMD Zen anymore. Edit, comparison: $ perf record target/release/gemm-benchmark -d 1024 Threads: 1 Iterations per thread: 1000 Matrix shape: 1024 x 1024 GFLOPS/s: 96.36 $ perf report --stdio -q | head -n3 97.18% gemm-benchmark gemm-benchmark [.] mkl_blas_def_sgemm_kernel_0_zen 1.94% gemm-benchmark gemm-benchmark [.] mkl_blas_def_sgemm_scopy_down16_bdz 0.78% gemm-benchmark gemm-benchmark [.] mkl_blas_def_sgemm_scopy_right4_bdz After disabling Intel CPU detection: $ perf record target/release/gemm-benchmark -d 1024 Threads: 1 Iterations per thread: 1000 Matrix shape: 1024 x 1024 GFLOPS/s: 129.12 $ perf report --stdio -q | head -n3 97.02% gemm-benchmark libmkl_avx2.so.1 [.] mkl_blas_avx2_sgemm_kernel_0 1.77% gemm-benchmark libmkl_avx2.so.1 [.] mkl_blas_avx2_sgemm_scopy_down24_ea 1.02% gemm-benchmark libmkl_avx2.so.1 [.] mkl_blas_avx2_sgemm_scopy_right4_ea Benchmarked using https://github.com/danieldk/gemm-benchmark https://github.com/danieldk/gemm-benchmark and oneMKL 2021.3.0.
- hallgrim 5y agoWe tried using intel python in one of my previous data science jobs, and ultimately gave up because compatibility with some packages from pip was a nightmare. Alas I can’t quite remember exactly what went wrong.
- black_puppydog 5y agoSo I see Intel and Microsoft both like naming things the Wrong(TM) way around? This name makes about as much sense as WSL... :D
- deleted 5y ago[deleted]