4 ms·

Then it truly is irrelevant! You're not even talking about CPUs vs CPUs. The differences you are quoting coming from the difference in libraries (sin, exp etc

by tagrun 7y ago

Then it truly is irrelevant! You're not even talking about CPUs vs CPUs. The differences you are quoting coming from the difference in libraries (sin, exp etc will give different results depending on them libm implementation, that's normal and it has nothing to do with CPU instructions!), not the implementation of IEEE instructions (assuming that you're talking about IEEE floats, otherwise, you shouldn't expect them to behave the same in the first place!), though. > Are they as fast as MKL? If so, just use them? I (and a lot of other people) do use them, when I have a choice. Sometimes they are faster, sometimes they aren't. When there is a significant disparity, however, it usually is because of GeniueneIntel checks. > If not, why not? Because scientific software geared toward applications is usually closed-source proprietary or too complicated to be modified (remember that users aren't interested in becoming software engineers, in addition to their own jobs as researchers) to add new alternative backends and you don't get to choose.

creato 7y ago
> Then it truly is irrelevant! You're not even talking about CPUs vs CPUs. Why does that matter? The bulk of the issues come from implementation defined behavior, of which there is plenty within x86 itself to cause issues. In general, the IEEE-compliant parts of x86 are also IEEE-compliant on other processors, at least the ones I've dealt with. It's the operations that aren't specified by IEEE that cause problems.
fock 7y ago
"Sometimes they are faster, sometimes they aren't. When there is a significant disparity, however, it usually is because of GeniueneIntel checks." so you are saying that your open-source BLAS/LAPACK is showing performance differences (and worse performance compared to MKL) because of "something Intel". Seems like a lot of people here (including the ones not being able to compile numpy against another BLAS) are a little bit short on actual experience/knowing about the problem... "scientific software geared toward applications is usually closed-source proprietary or too complicated to be modified" If it's geared towards applications, it's usually opaque engineering stuff and the results of people claiming to do science with this software are mediocre at best... In my domain (qunatum-chemistry) nearly all software is delivered as source-distribution. Because modifications of methods are part of science...
- tagrun 7y ago
  That's funny because I was actually talking about your field! (whose math is borrowed from one of the subfields of physics) I haven't so far met even a single chemist or material scientist who actually knows what they're running, even when they have access to the millons of lines of code they're using. And I don't blame them (or call them "mediocre" as you do), because they only have 24 hours in a day and only one life! I met only one computational physicist so far doing DFT who used to write his own code back in 70s, but he admits he has no idea what VASP and others are doing nowadays. If you're claiming that you actually know how VASP or Quantum Espresso (or any other similar significant piece of software) works in depth and you can tweak/replace any part as you like (which I'd find very very hard to believe, millions of work hours go into the development of those), you'd nevertheless be the exception in chemistry not the norm. The most common high-level tools theoretical physicists like me use (such as Mathematica) don't give access to source code, on the other hand, so we can't make Mathematica not use MKL and not suck on AMD.

by tagrun 7y ago

creato 7y ago

> Then it truly is irrelevant! You're not even talking about CPUs vs CPUs. Why does that matter? The bulk of the issues come from implementation defined behavior, of which there is plenty within x86 itself to cause issues. In general, the IEEE-compliant parts of x86 are also IEEE-compliant on other processors, at least the ones I've dealt with. It's the operations that aren't specified by IEEE that cause problems.

fock 7y ago

"Sometimes they are faster, sometimes they aren't. When there is a significant disparity, however, it usually is because of GeniueneIntel checks." so you are saying that your open-source BLAS/LAPACK is showing performance differences (and worse performance compared to MKL) because of "something Intel". Seems like a lot of people here (including the ones not being able to compile numpy against another BLAS) are a little bit short on actual experience/knowing about the problem... "scientific software geared toward applications is usually closed-source proprietary or too complicated to be modified" If it's geared towards applications, it's usually opaque engineering stuff and the results of people claiming to do science with this software are mediocre at best... In my domain (qunatum-chemistry) nearly all software is delivered as source-distribution. Because modifications of methods are part of science...

tagrun 7y ago
That's funny because I was actually talking about your field! (whose math is borrowed from one of the subfields of physics) I haven't so far met even a single chemist or material scientist who actually knows what they're running, even when they have access to the millons of lines of code they're using. And I don't blame them (or call them "mediocre" as you do), because they only have 24 hours in a day and only one life! I met only one computational physicist so far doing DFT who used to write his own code back in 70s, but he admits he has no idea what VASP and others are doing nowadays. If you're claiming that you actually know how VASP or Quantum Espresso (or any other similar significant piece of software) works in depth and you can tweak/replace any part as you like (which I'd find very very hard to believe, millions of work hours go into the development of those), you'd nevertheless be the exception in chemistry not the norm. The most common high-level tools theoretical physicists like me use (such as Mathematica) don't give access to source code, on the other hand, so we can't make Mathematica not use MKL and not suck on AMD.