Στις Παρ, 10 Ιαν 2020 στις 11:48 π.μ., ο/η Sven Schreiber <svetosch(a)gmx.net&gt; έγραψε: Wow! mmm Something is going on? I use gretl 2019d MS Windows (x86_64) build date 2019-12-22 Of course not your job but I also attach some info from my PC properties OS Name Microsoft Windows 10 Enterprise Version 10.0.17763 Build 17763 System Type x64-based PC System SKU 2YW27AV Processor Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz, 3192 Mhz, 6 Core(s), 12 Logical Processor(s) BIOS Version/Date HP Q50 Ver. 01.04.07, 1/31/2019 Installed Physical Memory (RAM) 16.0 GB Total Physical Memory 15.8 GB Available Physical Memory 10.2 GB Total Virtual Memory 18.2 GB Available Virtual Memory 12.3 GB Thanks again Yiannis

BTW just three days ago eigensym was switched to a different Lapack Using 2020a-git (2020-01-08) returns the same times. Also I run the script from either the desktop location or from the hard disk. No other program is running etc. I attach my $sysinfo ? eval $sysinfo bundle anonymous: nproc = 12 blascore = "Haswell" hostname = "DESKTOP-OFGVHSS" os = "windows" mpi = 0 blas = "openblas" omp_num_threads = 12 ncores = 6 omp = 1 blas_parallel = "OpenMP" mpimax = 12 wordlen = 64 if it could be of any value Yiannis

On Fri, 10 Jan 2020, Ioannis A. Venetis wrote: where the fast "timerB" pertains to use of eiggen2() -- now renamed as eigen(), eigen-decomposition of a general matrix -- and the seemingly much slower "timerA" pertains to eigensym(), eigen-decomposition of a symmetric matrix. Both of these employed on matrices which are by construction symmetric. There are definitely some points to note here, though I've not been able to reproduce anything like the asymmetry you found. First, I think you may need more replications to generate meaningful results. Second, the matrices you pass to the respective eigen functions are tiny, 4 x 4. There's nothing wrong with that, but it means that any function that's at all "optimized" (let alone parallelized) is almost sure to take longer than the plainest of plain vanilla algorithms. We recently (git, snapshots) made eigensym() default to a cleverly optimized lapack variant, dsyevr(). I've just recently changed that so that we use use dsyevr only if the order of the input matrix is at least 10. That helps a little in the case of tiny input. Another point is that when openblas includes a parallelized version of a lapack function, by default all available threads get used in its execution. But today's "consumer" CPUs typically offer twice as many threads as real/physical cores (hyper-threading) and on dense computations such as lapack functions using all threads can slow things down quite a bit. This will probably hurt most for tiny input where multi-threading isn't really justified to start with. Anyway, I'm appending below a modified version of your script, with a switch to control tiny versus bigger input. I recommend running this with OMP_NUM_THREADS set in the environment to the number of physical cores on your system. On my (kinda elderly) home system (4 cores, 8 threads max) here's what I'm seeing: With OMP_NUM_THREADS=4 With tiny_mat = 1 (order 4, 20000 replications): eigen() time: 0.2217s eigensym() time: 0.2200s ratio of eigen() time to eigensym() time: 1.00768 With tiny_mat = 0 (order 40, 2000 replications): eigen() time: 1.1705s eigensym() time: 0.6310s ratio of eigen() time to eigensym() time: 1.85502 Script: <hansl> set verbose off set seed 8402212 # or whatever tiny_mat = 0 # or 0 for bigger input! reps = tiny_mat ? 20000 : 2000 dim = tiny_mat ? 4 : 40 matrices AA = array(reps) loop i=1..reps -q A = mrandgen(i, -5, 5, dim, dim) AA[i] = A'A endloop matrix V = {} matrix W = {} set stopwatch loop i=1..reps -q D = eigen(AA[i], &V, &W) Tmp = mreverse(msortby(Re(D)~Re(V)', 1)) D = Tmp[,1] V = Tmp[,2:]' endloop eigen_time = $stopwatch printf "eigen() time: %.4fs\n", eigen_time set stopwatch loop i=1..reps -q D = eigensym(AA[i], &V) endloop eigensym_time = $stopwatch printf "eigensym() time: %.4fs\n", eigensym_time printf "ratio of eigen() time to eigensym() time: %g\n", eigen_time / eigensym_time </hansl> Allin

Στις Σάβ, 11 Ιαν 2020 στις 2:59 π.μ., ο/η Allin Cottrell <cottrell(a)wfu.edu&gt; έγραψε: Allin, thanks a lot.!! I will have a look tomorrow morning (i am away today) from my laptop and Monday morning in office. Yesterday when i run my script at home (laptop new) i got the same times with Sven. I will test it further using your code and I will back. I suspect that my office PC is responsible. Yiannis

Am 11.01.2020 um 01:33 schrieb Allin Cottrell: Hm, is openblas really so naive? Or to put it differently, is it the responsibility of the caller to pick the non-parallel version if needed? Hm, I'm using a perhaps even older 4-core system _without_ HT which has omp_num_threads = 4 as per $sysinfo, and with the brand new snapshot I get: tiny YES: ratio 0.11 tiny NO: ratio 0.37 So eigensym looks pretty bad "always". Since Ioannis had a newer PC, this doesn't look like a pre-Haswell CPU issue. Perhaps something Windows-specific (with OpenMP)? cheers sven

Am 11.01.2020 um 21:26 schrieb Allin Cottrell: The snapshot refuses to start, asking for libgfortran-5.dll or something. Hm, don't know. I remember reading such a warning in the help for some function. This warning would have to be copied to the eigensym doc I guess. But for tiny matrices it may make a relative difference I guess. But what would be the quickest or easiest user-testable way for checking symmetry? (Can't test because my snapshot isn't starting ;-) thanks sven

( 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 and I get (tiny_mat = 1 ) eigen() time: 0.1368s eigensym() time: 1.9458s ratio of eigen() time to eigensym() time: 0.0702871 (tiny_mat = 0 ) eigen() time: 0.7492s eigensym() time: 2.6358s ratio of eigen() time to eigensym() time: 0.284221 Points: eigen() is faster than Allin's due to (I guess) newest machine I have, but eigensym() is considerably slower in any case. Bear in mind than I posted the $sysinfo earlier on but I have no clue about MPI or how to change OMP_NUM_THREADS (for fancy stuff I rely on Jack's ;) intervention ) Tomorrow I will post results from my office Yiannis

Hi all, In 2020a-git build date 2020-01-1 (i haven't test in other versions) Function isnan() returns -1 instead of 1 as the help says "... Given a matrix argument, returns a matrix of the same dimensions with 1s in positions where the corresponding element of the input is NaN and 0s elsewhere" Also shouldn't it be in the help "...of the input is NA and 0s elsewhere" since other 'text' inputs for not-a-number or not-available are not understood by gretl, e.g.set below, Z[3,3]=nan or NAN or NaN but still, if you set Z[3,3]=0/0 it evals Z[3,3]=nan which is then understood by gretl isnan() which returns -1. <hansl> Z = ones(5,5) Z[3,3]=NA eval isnan(Z) eval !ok(Z) eval sumc(sumr(isnan(Z))) eval sumc(sumr(!ok(Z))) Z[3,]=NA eval isnan(Z) </hansl> Thanks Yiannis

On Sun, 12 Jan 2020, Sven Schreiber wrote: 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

On Mon, 13 Jan 2020, Sven Schreiber wrote: Yes, very interesting! See below. google: windows set environment variable. (It's not that hard.) Anyway, here's what I found on forcing single-threaded behavior: * eigensym() is uniformly faster than eigen(), on both Windows and Linux. * It makes more difference to the eigensym() times, but even eigen() is a bit faster when single-threaded. * This applies for matrices up to order 200 (which is as big as I've tried). Just as one example, here's the comparison for input of order 90, on a dual-boot haswell laptop with 2 physical cores, max 4 threads: OMP_NUM_THREADS=1 Win10 Linux eigen: 6.2417s 6.2913s eigensym: 1.7279s 1.5508s OMP_NUM_THREADS=2 Win10 Linux eigen: 6.3512s 6.7276s eigensym: 5.6093s 2.1323s So rather than divert from eigensym to eigen on Windows, what we really want to do is run single-threaded eigensym on both platforms, if we can figure out how to do that. (We don't want everything OMP to be single-threaded.) Allin

On Mon, 13 Jan 2020, Sven Schreiber wrote: We're on ths same page! I just pushed to git an openblas-specific patch for DSYEV* to store the prior number of threads, obtained via openblas_get_num_threads(); set the number of threads to 1 via openblas_sget_num_threads(); then restore the prior thread count. The bad news is that this really does seem to be a design flaw in openblas -- I've now tried matrices of order 400 and multi-threading is still slower for DSYEV*. The good news is that DGEEV runs a bit faster with multi-threading for really big matrices (at least on sandybridge). It remains to be seen how this pans out for other LAPACK functions. Allin