possible issue with ifx

[prop_design]

hi,

i was creating a simple benchmark program and i ran into something really weird with ifx. i was getting up to 1.5 gflops using ifort. with ifx it drops way down to around .2 gflops. on other codes i wrote, the performance was about the same or a little better with ifx. so this is really odd.

c7.bat and c8.bat are the ifx compiler options i tried. c.bat is for sse2. the rest are avx-512. the a added to the name was to try some compiler options related to memory.

i attached the program. it's Fortran 77. however, i ran into the windows 2gb memory limit. there was odd performance behavior with the size of the matrix as well. 1000x1000 seems to work best. my cpu has a lot of variability. so i have it repeat the tests 5 times.

not sure if it matters, but my cpu is the intel core i5-1135g7. i have windows 10 home edition, which is up to date with patches etc.

there are a number of limitations with the program, due to my lack of programming skills. i have no doubt it could be made a lot better. it does what i need though. it also helps me to find the best compiler options.

anthony

[Ron_Green]

the bug ID on this is CMPLRLLVM-46530

[prop_design]

Hi,

I did attach the program, in a previous post. Intel is aware of the ifx issue as well. I did run into the Windows 2gb limit. However, I can work around that. It would be nice if somehow the  compiler could work around that limit though. To say it supports Fortran 77 on Windows turns out to really not be true, with the 2gb limit issue. The compiler can support Fortran 77 on Linux though. So that's a bummer. The only fix seems to be use a newer version of the Fortran language, which isn't an option for me.

What I mean is integer*8 is not being respected, in terms of the size of the arrays possible. They aren't even able to take up the space of integer*4. I hit a limit that is even below the stated Windows 2gb limit. I ran into numerous compiler errors and Windows itself even popped up at times saying it couldn't run the compiled program. The only way I found to deal with it was decrease the array size. I used trial and error to avoid the compiler and Windows errors.

I believe the last code I posted is working. It depends on the cpu though. So for some computers, some of the internal equations might need to be changed. The code was just intended to be a quick and simple way to measure single core peak gflops. I was talking to a friend of mine about it and he brought up some things that the code also explores. I learned everything I needed to from it and I appreciate the help I got from Intel and the forum users.

Anthony

[Steve_Lionel]

This has nothing to do with Fortran 77 nor the compiler. You are seeing a difference in operating systems, but are you saying you can have static data larger than 2GB on 32-bit Linux? (And where are you finding such a thing nowadays?)

[prop_design]

hi steve,

i've actually read a lot of your posts from many years ago, because they come up in google searches for fortran array size windows 2gb limit. what i was referring to is there is an option in the intel compiler, i think it's -mcmodel=large that will let linux run the way you would expect. moreover, my friend and i were surprised to see that integer*8 is not being adhered to. the array size limit i'm hitting is even lower than the stated windows 2gb limit. it stinks that the compiler option is only for linux. i saw if you use fortran 90 or higher there is something about allocating and deallocating arrays. however, i'm using fortran 77. i wasn't aware of this limit until i made this little test code. so it was a big surprise. i don't personally need to work with huge arrays. however, when the compiler says it supports fortran 77 and it supports windows, then you would expect integer*8 to actually function correctly. it doesn't even seem to be integer*4. as far as the array size goes. perhaps i don't understand it enough and may be confusing you.

what it made me think of though is if some kind of behind the scenes trick could be done for fortran 77. no compiler option needed. basically, if you assign integer*8 the compiler would do whatever it had to so that the arrays could actually be integer*8 in size. in the source code notes, this is what i tried and found:

C PARAMETER ( VL = 2.1474836480D9 )
C
C PARAMETER ( VL = 9.2233720368547760D18 )
C
C PARAMETER ( VL = 2.1474835910D9 )
C
C PARAMETER ( VL = 2.1464350710D9 )
C
C LARGEST ARRAY SIZE THAT WORKS. FOUND VIA TESTING.
C
C PARAMETER ( VL = 1.0D7 )
C
C OPTIMIZED FOR SPEED AND ACCURACY. FOUND VIA TESTING.
C
PARAMETER ( VL = 1.0D5 )
C

so you can see i'm no where near integer*8 and even way below integer*4. i understand that fortran 77 is an old language and the fix is using fortran 90 or higher. however, if something could be done about this, i think it would help people. especially with backwards compatibility and portability. that way if you compile on any os it works the same and as one would expect. it would also make the whole fortran 77 is supported by the compiler on windows actually true. as it stands, it's sort of true.

oh, on your last question, no I'm not saying on 32-bit linux. I'm talking about 64 bit windows and whatever linux is, i'm assuming it's 64-bit.  i don't use linux, so i wouldn't know. basically, i was just saying your compiler has an option for linux but not for windows. the whole behavior is just crazy. it really shouldn't take jumping through hoops and a bunch of research to get integer*8 to be what it's supposed to be. even adding a compiler option on linux is more than should be needed. i've never once questioned that integer*8 wouldn't actually be what it's supposed to be. so it was a big shock.

[prop_design]

I updated one of the documents in my previous upload. I found some more info in the Intel user manual and I looked at the Microsoft documentation again. Some interesting things in both. For some reason, the Intel compiler array limits are exactly half of what you would expect. Also, Microsoft .Net documentation says there is an option to allow large arrays. However, it's off by default and must be set. I don't know if that's something that could be used to fix the problem. I attached the updated *.pdf with more information than before.

04/13/23; updated the attachment

[jimdempseyatthecove]

If you are on 64-bit Windows and have a 64-bit application, static array sizes (COMMON, SAVE, module) are limited to less than 2GB (sum of sizes of all such variables in the object static data segment). This is an object file limitation. For larger arrays, use allocatable arrays .AND. use integer(8) variables/literals/parameters to allocate and index the arrays. Note that, literals without suffix to say otherwise are default integer (4).

Note, there was, and may still be, an issue with indexing with integer(4) variables/parameters/literals in which the offset into the array is calculated using sizeof the index. IOW (presumption on my part), if your index is integer(4), the largest offset is 2GB, so if the array is of REAL(8), then the integer(4) index max is 2G/8. Now this may have changed since this was observed, but it won't hurt to use integer(8) indicies and allocation values.

Jim Dempsey

[Steve_Lionel]

-mcmodel is a Linux option - Windows does not have an equivalent. My recommended solution is to build a 64-bit app and make the large arrays ALLOCATABLE, then allocate them to the desired size. You won't then be limited to 2GB.

[prop_design]

hi steve,

i took your advice and tried allocatable arrays. however, i'm still hitting some sort of size limit. it's not even 2gb, it's much lower than that. i attached the code. another oddity is if i run the regular version vs the allocatable version, using all the same settings, the allocatable version is slower. it's something like 85gflops vs 52gflops.

on a different code i tried gfortran and flang, just to see what would happen. they all came back with the same size limit of 1.0D6. It's a different code and seems to have a different size limit for some reason. i can't use gfortran or flang on this code because of the USE IFWIN call. in any event, i'm way below even the 2gb limit. so basically, i'm thoroughly confused as to what is going on.

i've never used allocatable arrays before, so i'm not sure if i did it right. i'm using windows 10 home and the program runs from a windows command prompt. i also tried increasing the windows page file size and rebooting. however, that didn't seem to help. i saw some stuff online saying that was something you had to do. so not sure if that's true or not. my computer has 16gb of physical ram.

the basic thing i was trying to figure out is a friend of mine was saying if you use integer*8 then the max vector size should be 2^64-1. the intel fortran compiler help says the limit is 2^63-1. which is exactly half. so that's rather odd as well. i'm basically at 10^7, for this code and 10^6 for a different code.

ps; i hadn't benchmarked gfortran in awhile. ifort is still creating *.exe files that run about 3x faster. this is the first time i tried flang. it's *.exe files ran at about the same speed as gfortran's. so ifort is still killing it! this was one of the reasons i switched to ifort a long time ago.

antthony

[Steve_Lionel]

There are several things that can limit the size of allocations; the 2**63 byte limit is theoretical. You are more constrained by a combination of pagefile/swapfile space and allocation pattern. RAM size is more a performance issue.

The program you have in the ZIP file is way too large for me to want to try to understand.

[prop_design]

thanks. lol at the large file. that's the super short file. you should see what all the 1000s of lines of code i created and maintained is like. this 'little' test program is nothing. but it's fine. i don't think there is anything more that can be done at this point.

[Ron_Green · Accepted solution]

bug CMPLRLLVM-46530 is fixed in 2023.2.0

[prop_design]

Thanks for the update Ron. Also, thanks to the Intel Fortran team for taking the time to look into the issue and fix it.