This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Polyhedron b'marks | Linux vs Windows



On 6/3/2014 9:43 PM, Jerry DeLisle wrote:
On 06/01/2014 03:57 PM, Evan Cooch wrote:
So, have a box running a new-ish, fairly high-end Intel multi-core chip
(which one doesn't really matter here). Decided to see if the OS
---- snip ----

A few years ago I was investigating some of these benchmark issues.

I do not remember all the details, but I did find that at least one of the
common libraries was implementing some of the basic trig functions, such as
sin(), with software only methods and was not using the floating point
co-processor capability in most modern CPUs.

I attempted to get a maintainer to update this code and use the available
hardware.  I was met with a response more or less "Does it make a real
difference in a real application?"  That is a legitimate question and I don't
have an answer.


The built-in x87 math function support is at a disadvantage when called from SSE or AVX code, due to the necessity of passing operands and results by stack or memory reference. It makes sense to use it only for real(10) now that x87 mode is seldom used for single or double precision. The usual method for in-lining x87 math functions was via the mathinline.h which can be used outside of glibc, but normally isn't used with sse math. The extra bugginess of mathinline.h in several prominent linux distros gave it a bad name. I suppose the builtins scheme was intended to provide an alternative but came too late. The big difference is in possible use of simd vector math functions such as Intel VML or svml library functions, which aren't intended for use with gfortran on Windows. I assumed these weren't used with gfortran on linux either. With Intel compilers, the omp simd directives request use of svml even when the compiler wouldn't otherwise call them (including combining simd and threading by omp parallel do simd). I thought the newlib math functions were similar enough to the glibc ones; anyway, the OP didn't care to answer about which Windows implementation of gfortran or math library was under discussion.

--
Tim Prince


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]