3 ms·

I really doubt Intel Fortran will stall. ifort is pretty big business for Intel and the HPC space. It's probably one area where LLVM's advantages don't really m

by cultus 7y ago

I really doubt Intel Fortran will stall. ifort is pretty big business for Intel and the HPC space. It's probably one area where LLVM's advantages don't really matter.

Bostonian 7y ago
Is ifort "big business" in terms of direct revenues from sales of the compiler or because it makes Intel hardware a faster platform for HPC?
- cultus 7y ago
  Both. They are able to optimize things on Intel processors that no one else since they are the ones that make the processors and have more proprietary information and such. It's closed-source freeware but they make money on support.
- Someone 7y ago
  Let’s say your hardware cost $1 million. Then, a compiler that brings you a 1% speed increase compared to a free one should be break-even at a license price of $10,000, possibly more if you factor in the cost to run that machine. $1 million computers are rare, but not that rare (The fastest in the top-500 cost over $100 million), so, _if_ you can build a compiler that consistently does that, there should be a profitable business there. I would think margins on CPU sales and on consulting would dwarf that 1% margin, though. Because of that, I think it’s more “winning the benchmarks game, because that’s what sells hardware there” then revenues from compiler sales that keeps intel’s compiler alive.
celrod 7y ago
I've been working on LoopVectorization in Julia, and benchmarking against a few compilers. Intel's compilers are far ahead of GCC and LLVM in vectorizing loops. LLVM (even with Polly) fairs worst in my benchmarks, so it does not look like a future where Intel is obsolete is on the horizon yet. However, I am excited for Flang and its FIR MLIR-dialect. I haven't benchmarked MLIR-optimized code at all. I'm sure that will change things, but until I test I have no idea by how much.
- noobermin 7y ago
  I'd say it's more than merely far ahead. When it's your hardware and you've been doing HPC optimization for decades, you are leagues ahead.
  - stephencanon 7y ago
    There are no great secrets to the HW or vectorization. It’s mostly a question of willingness to devote resources to the problem and hire folks (e.g. Aart Bik, who literally wrote the book on vectorization at Intel and is now working on the TF compiler team at Google and contributing to LLVM).
  - gnufx 7y ago
    This "leagues ahead" is simply not true experimentally. I ran the Polyhedron benchmarks on SKX with profile-guided optimization. Pre-release gfortran 10 was (insignificantly) faster on the bottom line than beta ifort (from oneapi). That was reversed for gfortran 8 v. ifort 18. It's also not true that HPC performance is generally dominated by code generation rather than libraries and communication costs, but obviously mileage varies.
- stephencanon 7y ago
  Note that a lot of Intel’s advantage in SIMD, historically, came from optimization modes that simply (unsafely) assume that there are no dependencies that would block vectorization (instead of doing the conservative analysis like GCC and Clang). It makes for impressive benchmarks, but is borderline-unusable in much real code. Intel’s compiler team has actually suggested some patches adding the same mode to LLVM, though I’m not sure what the current status is, since the initial reaction was not overwhelmingly positive.
  - celrod 7y ago
    Interesting. Would this be safer in a language like Fortran, where (without aliasing between separate arrays), loop dependencies should be more obvious? I think it'd be nice to be able to activate this mode through pragmas. Does "#pragma omp simd" result in more aggressive use of blocking?

by cultus 7y ago

I really doubt Intel Fortran will stall. ifort is pretty big business for Intel and the HPC space. It's probably one area where LLVM's advantages don't really matter.

Bostonian 7y ago

Is ifort "big business" in terms of direct revenues from sales of the compiler or because it makes Intel hardware a faster platform for HPC?

cultus 7y ago
Both. They are able to optimize things on Intel processors that no one else since they are the ones that make the processors and have more proprietary information and such. It's closed-source freeware but they make money on support.
Someone 7y ago
Let’s say your hardware cost $1 million. Then, a compiler that brings you a 1% speed increase compared to a free one should be break-even at a license price of $10,000, possibly more if you factor in the cost to run that machine. $1 million computers are rare, but not that rare (The fastest in the top-500 cost over $100 million), so, _if_ you can build a compiler that consistently does that, there should be a profitable business there. I would think margins on CPU sales and on consulting would dwarf that 1% margin, though. Because of that, I think it’s more “winning the benchmarks game, because that’s what sells hardware there” then revenues from compiler sales that keeps intel’s compiler alive.

celrod 7y ago

I've been working on LoopVectorization in Julia, and benchmarking against a few compilers. Intel's compilers are far ahead of GCC and LLVM in vectorizing loops. LLVM (even with Polly) fairs worst in my benchmarks, so it does not look like a future where Intel is obsolete is on the horizon yet. However, I am excited for Flang and its FIR MLIR-dialect. I haven't benchmarked MLIR-optimized code at all. I'm sure that will change things, but until I test I have no idea by how much.

noobermin 7y ago
I'd say it's more than merely far ahead. When it's your hardware and you've been doing HPC optimization for decades, you are leagues ahead.
- stephencanon 7y ago
  There are no great secrets to the HW or vectorization. It’s mostly a question of willingness to devote resources to the problem and hire folks (e.g. Aart Bik, who literally wrote the book on vectorization at Intel and is now working on the TF compiler team at Google and contributing to LLVM).
- gnufx 7y ago
  This "leagues ahead" is simply not true experimentally. I ran the Polyhedron benchmarks on SKX with profile-guided optimization. Pre-release gfortran 10 was (insignificantly) faster on the bottom line than beta ifort (from oneapi). That was reversed for gfortran 8 v. ifort 18. It's also not true that HPC performance is generally dominated by code generation rather than libraries and communication costs, but obviously mileage varies.
stephencanon 7y ago
Note that a lot of Intel’s advantage in SIMD, historically, came from optimization modes that simply (unsafely) assume that there are no dependencies that would block vectorization (instead of doing the conservative analysis like GCC and Clang). It makes for impressive benchmarks, but is borderline-unusable in much real code. Intel’s compiler team has actually suggested some patches adding the same mode to LLVM, though I’m not sure what the current status is, since the initial reaction was not overwhelmingly positive.
- celrod 7y ago
  Interesting. Would this be safer in a language like Fortran, where (without aliasing between separate arrays), loop dependencies should be more obvious? I think it'd be nice to be able to activate this mode through pragmas. Does "#pragma omp simd" result in more aggressive use of blocking?