Andreas Arnez

Thanks, with that change the tuning completes. The performance is very poor, as expected, and as seen from sPerfSumm.txt: Clock_rate=5000 Mhz % clock MFLOP ROUTINE/PROBLEM ======= ========= =============== 74.4 3718.5 kgemvN 81.1 4052.5 kgemvT 79.5 3975.4 kger1 82.7 4136.4 kger2 29.5 1477.3 kgemm as compared to dPerfSumm.txt: Clock_rate=5000 Mhz % clock MFLOP ROUTINE/PROBLEM ======= ========= =============== 71.4 3568.2 kgemvN 74.5 3722.7 kgemvT 76.2 3811.9 kger1 106.4 5322.1 kger2 307.7 15385.5...

At least that assertion is the one we fixed earlier, unless the error file is from a prior install? I didn't remove the files in INSTALL_LOG before running "make" again, so there are probably leftovers from a previous run. But sAMMTUNE.LOG certainly contains the message from the patch for opsrch.c, rather than the assertion that was there before: ASYMPTOTIC KERNEL ID=0, B(72,12,84) fits in L1! The tuning continued a bit after that, and then the assertion in gmmsearch.c happens -- enriched with the...

At least that assertion is the one we fixed earlier, unless the error file is from a prior install? I didn't remove the files in INSTALL_LOG before running "make" again, so there are probably leftovers from a previous run. But sAMMTUNE.LOG certainly contains the message from the patch for opsrch.c, rather than the assertion that was there before: ASYMPTOTIC KERNEL ID=0, B(72,12,84) fits in L1! The tuning continued a bit after that, and then the assertion in gmmsearch.c happens -- enriched with the...

Only one attachment per comment -- so here's the error file.

Can you attach your res/sipsum.res from BLDdir/tune/blas/gemm? There's no such file there. Instead I'm attaching all files from that directory whose filenames start with "sip". Also, attach the updated error file: that assertion shows something has gone terribly wrong. OK. Just to be clear: this test was still based on git commit 3d8a2a2c -- "3.11.40 release", using the z13 patches above.

OK. This yields: ./xgmmsearch -p s kb=0, ku=4 xgmmsearch: /home/arnez/atlas-build/ATLAS//tune/blas/gemm/gmmsearch.c:2897: DoSyrk: Assertion `nb && kb' failed.

How should the OS know until which point in time the temporary files are needed, and when it is safe to remove them? Of course, a reboot will clean them up, but that can't be what you're suggesting here...

On Fri, Dec 07 2018, R. Clint Whaley wrote: You can just restart the install that died by issuing "make" in the BLDdir again, which was what I was advising you to do after saving the new opsrch.c. Yeah... but at that time I didn't have the original build tree anymore, because I had been playing around with z13 optimizations in parallel. So, after starting from scratch, my tuning started as usual, but then ran into trouble because /tmp was full. (I reported this separately: https://sourceforge.net/p/math-atlas/support-requests/1076/)...