On Sun, 12 Jan 2020, Sven Schreiber wrote:
Am 12.01.2020 um 09:53 schrieb Ioannis Venetis:
> ( Windows 10 Home
> Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz 1.99 GHz
> Installed memory(RAM) 16.0GB)
> with 2020a-git build date 2020-01-11
There were two snapshots with that date I believe. I'm using the one
from "right now" (half an hour ago or so).
The problem does not go away, ratios stay the same.
I did some testing on Windows 10 today, and I saw the same: eigen()
a lot faster than eigensym(), with the update to openblas 0.3.7 not
making an appreciable difference.
I also found: (a) disabling the symmetry test in eigensym made
essentially no difference; (b) restricting the number of OMP threads
to the number of real cores didn't change the ordering; and (c)
running the script via gretlcli rather than the GUI didn't make a
difference (it shouldn't, of course, but just checking).
But... I did find that if you scale up the order of the input you
eventually reach a breakeven point then eigensum overtakes. On the
haswell laptop I was using the breakeven was around order 80, and by
order 90 eigensym was substantially faster (on Windows, just to be
clear).
In further testing on Linux/haswell I saw that eigensym was much
faster at order 40, but actually it was slower in the "tiny" case
(order 4), though nothing like as much as on Windows. I also saw
that both dsyev and dgeev appear to do multi-threading.
Pending a proper understanding of what's going on. maybe we should
make eigensym() divert to eigen() on Windows for order less than 90
or so.
Allin