Automatically Tuned Linear Algebra Soft. Activity
Brought to you by:
rwhaley,
tonyc040457
Activity for Automatically Tuned Linear Algebra Soft.
-
sL1pKn07 created ticket #1096
fail configure steps. errors regarding to incompatible pointer type
-
Luis Fernandez Menchero created ticket #1095
Atlas 3.10.3 not compiling with GNU-GCC 14.1
-
Vladislav NB created ticket #1094
Compilation error 821 at E5-2650v2 Ubuntu 24.04
-
Taketo Kabe posted a comment on ticket #1093
patch part 2, fixing cryptic error like xuserflag: /home/kabe/r9builds/atlas-r9/BUILD/ATLAS/i386_base/..//tune/blas/gemm/userflag.c:242: GoGetThem: Assertion `fgets(ln, 512, fpin)' failed.
-
The patch only fixed one of the similar instances. This is the complete patch part 1.
-
Compilation fails when "gcc" expands to more than 256 characters
-
Federico Marocco created ticket #1092
Rank mismatch in argument 'strue1'
-
Tomasz Kłoczko created ticket #86
RFE: migrate VCS to git
-
jeyaraj created ticket #1091
ATLAS3.10.installation failed compiling with gcc 11.2. on RHEL 8.4
-
Marcello Pietrobon posted a comment on ticket #1089
I've created a separate issue for the gcc problem in #1090 bug assigning alternate gcc compiler on archlinux because it's actually a completely separate one.
-
SOLVED. For the library to compile you need not only two fix the blas/C/testing/ directory as described in File: gfortran-10.patch but also fix the two equivalent files in blas/F77/ , in such way that you have: [ATLAS3.10.3]$ grep -rnF ",STEMP," src/blas/f77reference/srotmg.f:55: + SQ2,STEMP,SU,TWO,ZERO interfaces/blas/C/testing/c_dblat1.f:250: CALL STEST1(DNRM2TEST(N,SX,INCX),STEMP(1),STEMP,SFAC) interfaces/blas/C/testing/c_dblat1.f:254: CALL STEST1(DASUMTEST(N,SX,INCX),STEMP(1),STEMP,SFAC) interfaces/blas/C/testing/c_sblat1.f:250:...
-
bug assigning alternate gcc compiler on archlinux
-
Atlas fails fortran tuning tests + bug assigning alternate gcc compiler on archlinux
-
Elijah Encarnacion posted a comment on discussion Help
cannot detect CPU throttling
-
-
cannot detect CPU throttling
-
these is our specs
-
cannot detect CPU throttling
-
Aurelien Verdier posted a comment on discussion Help
Hello, I also have trouble with clapack_dpotrf I have installed ATLAS 3.10.3 manually in order to install SCAMP (2.10.0) However when I want to configure (./configure using --with-atlas-libdir and --with-atlas-incdir) he can find clapack.h but not clapack_dportrf Do you have any idea on how to resolve this problem ? Cheers, Aurelien
-
Stanley modified a comment on discussion Help
We are not able to install ATLUS on SOLARIS 11.4 server and while compling we got the error (Please find the details in the file enclosed) . Kindly guide us to install. ATLAS download from GIT repo (https://github.com/jeffreyadams/atlasofliegroups)
-
We are not able to install ATLUS on SOLARIS 11.4 server and we get the error in the make file. Kindly guide us to install. ATLAS download from GIT repo (https://github.com/jeffreyadams/atlasofliegroups) Attached screenshot for your reference. Regards, Stanley
-
Tran Thi Thai posted a comment on discussion Help
Hi guide, I am trying to install ATLAS in my desktop. However, I can't turn off CPU throttling before installation. I tried several ways, such as nano /etc/default/grub..... cpufrequtils.... But it doesn't work. Is there any difference between desktop and PC since I already successed with my PC . somebody can help me ?
-
ewtoombs posted a comment on ticket #962
I'm seeing the following test failure: src/ATLAS/build/bin/ATLrun.sh src/ATLAS/build/bin xsqrtst_pt -n 1 477 -m 1 517 -U 2 u l -S 2 r l Rt Maj M N lda TIME MFLOP RESIDUAL == === ===== ===== ===== ========== ========== ========= QR Col 517 477 517 4.3782e-02 3731.83 1.75e+04 QL Col 517 477 517 4.2532e-02 3841.51 1.53e+04 RQ Col 517 477 517 4.3040e-02 3796.62 1.08e+04 LQ Col 517 477 517 4.2694e-02 3827.39 1.04e+04 4 cases ran, 4 cases failed, 0 cases passed This was while building the AUR's atlas-lapack...
-
Christopher Chavez posted a comment on ticket #1082
On macOS, ATLAS fails to build with Xcode 12 which now considers implicit function declarations to be errors rather than warnings. See https://trac.macports.org/ticket/61258
-
zan posted a comment on ticket #1088
It can take quite a long time to tune the build. If it is progressing properly, I would leave it be. Although some shortcuts are employed to try to shorten the search time for common build targets, a normal full tune and build can take a good 2-3 days to complete on a system like the one you are using. There are a lot of parameters to tune for, and you can't parallelize much of the search as the tests would interfere with one another. On 04/07/2020 01:13, J. Hart wrote: [support-requests:#1088] build...
-
J. Hart created ticket #1088
build still running at 36 hours
-
Bastien Jeannelle created ticket #1087
Impossible to compile on Tiny piCore 9.0.3
-
Sukanya Chakrabarti posted a comment on ticket #1086
I tried to continue the build despite the error and am attaching here the ERROR.log. Please let me know if you have any suggestions. It seems to fail in R1Tune. Thanks Sukanya
-
can't configure ATLAS version 3.10.3 on my MAC
-
Ahmet Afsin Akin created ticket #1085
Atlas 3.11.41 build error
-
Clayton created ticket #1084
lib/Makefile does not exist
-
Demitri posted a comment on ticket #1083
A quick update here. I'm starting the build now with a few options preselected to avoid the probe: ../configure --prefix=/usr/local/atlas-3.10.3 --with-netlib-lapack-tarfile=/usr/local/src/lapack-3.8.0.tar.gz --force-clang=/usr/bin/clang -A Corei464 -O OSX -b 64 -V 960 The -V 960 selects AVX, SSE1, SSE2, SSE3. This gets me to a point where I can call make. This builds for a few seconds, then fails. One of the errors is this: clang: error: unsupported option '-V -Wno-framework-include-private-from-public'...
-
Unable to compile on iMac Pro (Intel Xeon W-2140B)
-
Jakub Martisko created ticket #1082
[Question] Several "implicit declaration of function" warnings
-
Lukas posted a comment on ticket #1081
Thank you! I have changed the software using the ATLAS blas to referring to libtatlas.so in stead of libcblas and it seems to be working. Just wanted to let you know that everything works again. Feel free to close again!
-
Nicolas Cellier posted a comment on ticket #21
Sorry, I did load ATLAS 3.10.3, I compile for Mingw64 target via cygwin64, and I still have the same problem. I do not see the protection for escaping '(' and ')' in function GetPathEnvVar() in file ATLAS/CONFIG/src/atlconf_misc.c as suggested by Li Peng it's just a few lines else if(path[i] = '(') { *p = '\\'; p[1]='('; p+=2; } else if(path[i] = ')') { *p = '\\'; p[1]=')'; p+=2; }
-
R. Clint Whaley modified ticket #1081
configure --shared does not build libcblas.so
-
Yes, all those separate libraries are built into 2 combined libraries for dynamic linking: libsatlas.a: all serial routines libtatlas.a: all threaded routines So, closing this as not an error, feel free to reopen if you have questions or unresolved problems!
-
configure --shared does not build libcblas.so
-
Mohammad Akhlaghi created ticket #1080
Building with GCC on Mac OS
-
Andrew Janke posted a comment on ticket #930
No matter whether you install gcc via MacPorts or Homebrew there is trouble with using AVX instructions. By default the gcc installation will use the GNU Assembler (also installed via MacPorts or Homebrew) instead of the Assembler that comes with Xcode. I believe this is because the pre-built binary "bottles" for Homebrew are built for an older architecture for maximum portability. If you instead do brew install -s <gcc> to build it from source when you install, it will end up optimized for your...
-
Peter Shhkam created ticket #1079
make check fails with xsrqtst
-
Andreas Arnez posted a comment on ticket #1075
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...
-
make check fails with xsrqtst
-
Almost sure I unpacked an old error file, instead of the one you posted (I find this error now, but didn't see before). Try restarting after saving the modified gmmsearch.c to ATLAS/tune/blas/gemm I think the error is due to the stuff where I said I suspected performance would be bad: I think some block factor may be less than 4 or so, and that's causing the zero. For now, I tried just allowing such a small block factor rather than assertion, lets see if that works or now.
-
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...
-
At least that assertion is the one we fixed earlier, unless the error file is from a prior install? If you have lost the patches, reapply the opsrch.c and gmmsearch.c that I gave you and restart. I don't think the results are looking good (using way to small of block factors for some cases), but we can worry about performance once we've got something working . . .
-
It died this time becase you lost the opsrch patch I gave you several messages above.
-
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.
-
Well, I honestly thought OSes cleaned up /tmp as needed by deleting old files. Gave a quick scope to extract, and found one place where I open up files other than using tmpfile(), and and I added a remove call at end. Not sure if this will fix the issue you are having, but here's the latest update I added to git. Let me know if this helps, Clint
-
Can you attach your res/sipsum.res from BLDdir/tune/blas/gemm? Also, attach the updated error file: that assertion shows something has gone terribly wrong.
-
Possible bug in the GetFixedCaseNode function
-
The file emit_mm.c no longer exists in latest git branch. As for stable, the routine GetFixedCaseNode is not called, so this cannot cause a bug (same true of developer that has emit_mm used). Regards, Clint
-
Possible bug in the GetFixedCaseNode function
-
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...
-
Save this over your gmmsearch.c, and restart, and give me the printout (it should still die with assertion failed, but should give us more information so I can diagnose).
-
ATLAS tuning leaves lots of temp files on disk
-
How is this an ATLAS problem? Isn't that a failure of your OS to clean up /tmp when its full?
-
Robinson, Melvin D. posted a comment on ticket #1071
I had some problems building with FreeBSD, but was eventually able to get it to work. I had particular problems using make, but when changing to gmake things started working better.
-
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/)...
-
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/)...
-
ATLAS tuning leaves lots of temp files on disk
-
On 12/7/18 11:04 AM, Andreas Arnez wrote: OK. Unfortunately it seems I pasted the wrong version of atlas_cache.h above. In the failing run that yielded the the error file, cachesrch.c actually did not find an L2 private cache. In order to avoid this kind of variation between tuning runs in the future, I added a patch that reads the cache sizes from /proc/cpuinfo instead. So I've started another tuning run with this patch. It will probably take a while now. You can just restart the install that died...
-
I'll check that and adjust the patch accordingly. This SVN commit fixed the bug: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=253543
-
OK. Unfortunately it seems I pasted the wrong version of atlas_cache.h above. In the failing run that yielded the the error file, cachesrch.c actually did not find an L2 private cache. In order to avoid this kind of variation between tuning runs in the future, I added a patch that reads the cache sizes from /proc/cpuinfo instead. So I've started another tuning run with this patch. It will probably take a while now.
-
OK, not too badly wrong then. You might try manually saving this file to BLDdir/include and BLDdir/tune/sysinfo/res/ on your next restart, but I don't think it will make much difference.
-
Do you know what versions of GCC vec_madd are broken on? Your patch is always using the builtin, but I think it'd be more general if I could test the version macro and only use the builtin on old compilers with broken support.
-
Save this file over your present ATLAS/tune/blas/gemm/opsrch.c, and restart, and let me know what happens.
-
No, this is the result from cachesrch.c. The L1 cache size is actually correct. The other levels are wrong. In fact the L2 data cache on this machine is private, but has only 2MB, and the unified L3 has 64MB total, but is shared among 8 cores.
-
This guy is saying there are three levels of cache: L1: 128K, private to each core L2: 16MB, private to each core L3: 32MB, shared amongst cores Are these L2 & L3 caches really there and that big? If so, I assume the L2 cache is actually shared, not private (i.e. each core does not have a 16MB L2 that is unshared)?
-
/* generated by ATLAS/tune/sysinfo/cachesrch.c */ #ifndef ATLAS_CACHE_H #define ATLAS_CACHE_H 1 #define L1C_SZ 131072 #ifdef SREAL #define L1C_ELTS 32768 #elif defined(DREAL) || defined(SCPLX) #define L1C_ELTS 16384 #elif defined(DCPLX) #define L1C_ELTS 8192 #endif #define L2C_SZ 16777216 #ifdef SREAL #define L2C_ELTS 4194304 #elif defined(DREAL) || defined(SCPLX) #define L2C_ELTS 2097152 #elif defined(DCPLX) #define L2C_ELTS 1048576 #endif #define L3C_SZ 33554432 #ifdef SREAL #define L3C_ELTS 8388608...
-
Please post your BLDdir/include/atlas_cache.h
-
This patch results in the error file I've uploaded. Without the patch ATLAS fails much earlier with the syntax error shown above.
-
Does this patch result in the error file you've uploaded, or is that error file now out of date?
-
Here's the patch that I used. It fixes some of the obvious problems with the IBM z13 build, but then leads to the assertion above.
-
ATLAS doesn't build on IBM z13
-
Hm, this yields: PER-CORE: 5.791650e+03, 5.788728e+03, 5.787536e+03, 5.784638e+03 ALL CORES: min=5784.64, max=5791.65, avg=5788.14 I'm using gcc version 9.0.0 20181127 (experimental), which I built myself from sources with last week's git commit 62b8ade669. So, what does this mean? Do we need to open a bug against upstream GCC?
-
Something is wrong with your machine, I think. I've also got a Corei4X64AVXZ, and when I run the kernel getting you 9 MFLOPs, I get 5710 MFLOPs. My machine is a 3.3 GHz machine. I can only think of two reasons performance is so low: (1) No x87 hardware, that code being emulated (2) fpstack overflow/underflow has occured (2) could happen if your OS or compiler is not obeying the ABI. To see if this is the case, edit line 80 of file ATLAS/tune/blas/gemm/AMMCASES/ATL_amm6x1x1_x87.S from: lea (K, K,...
-
You can easily do that yourself. In ATLAS/tune/blas/gemm/AMMCASES/*.idx, just remove all lines describing that kernel (search for name of file, then delete all lines joined to that one with '\' line extension char). This should not cause any problem, since obviously a kernel running 1000s of times slower is not going to be used :)
-
I'm building with "-Si archdef 0", because I wanted to compare a (hopefully) successful tuning run on x86-64 to a failing tuning run on z14. And as far as I can tell, the long tuning time is largely dominated by measurements of this slow kernel. Would it be useful/possible to disable this kernel on modern x86-64 systems?
-
I'm 99.9% sure this error will not cause any problems, and has been occuring for me on every machine. The tuning of level3 needs to be redone to match new l3blas that we are working on in branch, and in meantime I think there are tuning steps that aren't being used.
-
create & post error file as outlined here: http://math-atlas.sourceforge.net/faq.html#help Latest ATLAS takes insanely long to tune, but if you are in c I think that means you are close to done. Not sure why it is taking so long to install, since I have arch defs for that platform, but maybe your number of cores is hugely different. I will have to look in logs to see if my x87 code runs as slow as what you are seeing on that arch. If so, my guess is they removed the hardware for x87, and are doing...
-
The tuning continues, but I don't know whether it will complete successfully, because the tuning is still running. Up to this point the directory tune/blas/level3 remains empty, though. Is this expected?
-
ATL_amm6x1x1_x87.S delays tuning on x86-64
-
I don't think this error has any effect: its generating a header file that is no longer being used by ATLAS as far as I can tell. I will need to remove the install call to his tuning step, and make sure I get no problems to ensure this is accurate, which I can't do at moment (laptop at conference).
-
‘ATL_opsq_66MB’ undeclared
-
does this error stop installation, or does it continue and create working libraries?
-
‘ATL_opsq_66MB’ undeclared
-
I made a mistake. It is the code on github that gives me this error.
-
ATL_stGetTrsmInfo ATL_dtGetTrsmInfo
-
Your ticket says both stable & devel, but it sounds like git only, right? Do you get this error with latest developer release (which is no longer terribly behind git)?
-
ATL_stGetTrsmInfo ATL_dtGetTrsmInfo
-
owen created ticket #1071
atlas fails to compile; FreeBSD [reference-lapack | openblas]
-
Automatically Tuned Linear Algebra Soft. released /Developer (unstable)/3.11.41/atlas3.11.41.tar.bz2
-
-
HERK reads C for BETA=0
-
HERK completely rewritten in 3.11.40, and this fixed in 3.10.3, so closing.
1 >