Will the next version of gravitational waves search AVX supports? If yes, is already known when this version is available?
This would indeed be nice to have, but actually would involve quite a bit of effort. here's why:
on the developer side:
-rewrite the Source code: the GW app uses handwritten assembly code (mostly SSE) which would have to be rewritten in AVX. A couple of person days for sure
- for compilation, you need to have a tool chain that supports AVX. The compilers currently used don't, and the Windows version would be especially problematic: currently, the Win apps are cross compiled on Linux. I'm not even sure there's already a version of MinGW out there that supports AVX
- for testing and profiling you need an AVX capable machine (I don't have one :-(. )
On the volunteer side,
- users need AVX capable machines.Â
- Â Because the BOINC client has to do the feature detection and then report it to the server, BOINC in a way has to support AVX as well. This does not only involve the query for CPU capabilities, because the
- Operating System needs to support AVX as well. even Windows 7 only supports AVX since Service Pack 1. windows XP does not support it at all. Under Linux, it depends on the kernel version.
Thank you for your reply. Other projects already support AVX or are working on it. For example, SETI@home beta or GIMPS. AVX offers 256-bit wide registers a doubling of computing speed compared to SSE2. All future Intel and AMD CPU will have this extension. The number of AVX compatible machines with Windows 7 will rise. AVX offers a great potential for the calculation of gravitational waves.
On the volunteer side,
- users need AVX capable machines.Â
- Â Because the BOINC client has to do the feature detection and then report it to the server, BOINC in a way has to support AVX as well. This does not only involve the query for CPU capabilities, because the
- Operating System needs to support AVX as well. even Windows 7 only supports AVX since Service Pack 1. windows XP does not support it at all. Under Linux, it depends on the kernel version.
HBE
Boinc client doesn't need to do AVX feature detection, Seti's v7 6.96 app does that itself, here's the verbose output of the v7 6.96 app from my Atom N450:
[pre]Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
v_GetPowerSpectrum 0.002360 0.00000 test
v_vGetPowerSpectrum 0.000796 0.00000 test
v_vGetPowerSpectrum2 0.000867 0.00000 test
v_vGetPowerSpectrumUnrolled 0.000746 0.00000 test
v_vGetPowerSpectrumUnrolled2 0.000759 0.00000 test
v_avxGetPowerSpectrum not supported on CPU
v_vGetPowerSpectrumUnrolled 0.000746 0.00000 choice
v_ChirpData 0.076210 0.00000 test
fpu_ChirpData 0.152218 0.00000 test
fpu_opt_ChirpData 0.062638 0.00000 test
v_vChirpData_x86_64 0.290106 0.00000 test
sse1_ChirpData_ak 0.057125 0.00000 test
sse1_ChirpData_ak8e 0.049614 0.00000 test
sse1_ChirpData_ak8h 0.046508 0.00000 test
sse2_ChirpData_ak 0.056205 0.00000 test
sse2_ChirpData_ak8 0.050376 0.00000 test
sse3_ChirpData_ak 0.150189 0.00000 test
sse3_ChirpData_ak8 0.082882 0.00000 test
avx_ChirpData_a not supported on CPU
avx_ChirpData_b not supported on CPU
avx_ChirpData_c not supported on CPU
avx_ChirpData_d not supported on CPU
sse1_ChirpData_ak8h 0.046508 0.00000 choice[/pre]
Thank you for your reply. Other projects already support AVX or are working on it. For example, SETI@home beta or GIMPS. AVX offers 256-bit wide registers a doubling of computing speed compared to SSE2. All future Intel and AMD CPU will have this extension. The number of AVX compatible machines with Windows 7 will rise. AVX offers a great potential for the calculation of gravitational waves.
The BOINC version I'm using now (6.12.34) doesn't list AVX as available, even on my rather new desktop with an Intel i7-2600 and Windows 7 SP1. Does it call it something else instead?
An idea of how to handle this - put both this AVX code and the non-AVX code into the same application program, and have it ask BOINC whether AVX is present in deciding which version of the code should be used. Requires that both give essentially the same answers, even if faster for AVX.
If Einstein@Home lacks a computer with AVX, they could create a Test application class and use it for test versions of new applications only. It should not be enabled for users by default; instead, only for volunteers that can find this setting and enable it.
Lack of a suitable compiler is a bigger problem, unless you can find some other way to generate object code from the new assembler routines, and in an object code format compatible with the preferred compiler.
It looks like you'd need an Intel C++ compiler to use this information, and their only free version is an evaluation version that will work for only 30 days. Is that long enough? Also, can that compiler generate object code files that the preferred compiler can use?
Ah I see, the app has several code paths and selects the best one at runtime. Nice.
HB
Einstein@home did this some five years ago. It was a pain to maintain and compile (actually link) the code. The next step, which made maintenance easier and also improved performance, was to compile complete applications for different CPU features (from the same code), and add a 'switcher' that selected one of these based on the features of the CPU it was running on. Finally we arrived at the server making the decision which app to send based on information from the Client.
Given my previous experience with that approach I don't find it 'nice'. I would strongly vote for adding AVX detection and reporting to the BOINC Client.
I tried to compile the GW App with various versions of icc a couple of times, the results being almost always disappointing. If it worked at all, the performance gain of the App was negligible or even negative compared to a gcc-compiled App with the 'hot loops' coded in sassembler.
I haven't tried the latest icc with AVX though, but I'm reluctant to put much work into that myself. If anyone out there want to try - the code is freely available and I would be happy to help him as much as I can (as much as my time allows).
Support AVX
)
This would indeed be nice to have, but actually would involve quite a bit of effort. here's why:
on the developer side:
-rewrite the Source code: the GW app uses handwritten assembly code (mostly SSE) which would have to be rewritten in AVX. A couple of person days for sure
- for compilation, you need to have a tool chain that supports AVX. The compilers currently used don't, and the Windows version would be especially problematic: currently, the Win apps are cross compiled on Linux. I'm not even sure there's already a version of MinGW out there that supports AVX
- for testing and profiling you need an AVX capable machine (I don't have one :-(. )
On the volunteer side,
- users need AVX capable machines.Â
- Â Because the BOINC client has to do the feature detection and then report it to the server, BOINC in a way has to support AVX as well. This does not only involve the query for CPU capabilities, because the
- Operating System needs to support AVX as well. even Windows 7 only supports AVX since Service Pack 1. windows XP does not support it at all. Under Linux, it depends on the kernel version.
HBE
Thank you for your reply.
)
Thank you for your reply. Other projects already support AVX or are working on it. For example, SETI@home beta or GIMPS. AVX offers 256-bit wide registers a doubling of computing speed compared to SSE2. All future Intel and AMD CPU will have this extension. The number of AVX compatible machines with Windows 7 will rise. AVX offers a great potential for the calculation of gravitational waves.
RE: On the volunteer
)
Boinc client doesn't need to do AVX feature detection, Seti's v7 6.96 app does that itself, here's the verbose output of the v7 6.96 app from my Atom N450:
[pre]Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
v_GetPowerSpectrum 0.002360 0.00000 test
v_vGetPowerSpectrum 0.000796 0.00000 test
v_vGetPowerSpectrum2 0.000867 0.00000 test
v_vGetPowerSpectrumUnrolled 0.000746 0.00000 test
v_vGetPowerSpectrumUnrolled2 0.000759 0.00000 test
v_avxGetPowerSpectrum not supported on CPU
v_vGetPowerSpectrumUnrolled 0.000746 0.00000 choice
v_ChirpData 0.076210 0.00000 test
fpu_ChirpData 0.152218 0.00000 test
fpu_opt_ChirpData 0.062638 0.00000 test
v_vChirpData_x86_64 0.290106 0.00000 test
sse1_ChirpData_ak 0.057125 0.00000 test
sse1_ChirpData_ak8e 0.049614 0.00000 test
sse1_ChirpData_ak8h 0.046508 0.00000 test
sse2_ChirpData_ak 0.056205 0.00000 test
sse2_ChirpData_ak8 0.050376 0.00000 test
sse3_ChirpData_ak 0.150189 0.00000 test
sse3_ChirpData_ak8 0.082882 0.00000 test
avx_ChirpData_a not supported on CPU
avx_ChirpData_b not supported on CPU
avx_ChirpData_c not supported on CPU
avx_ChirpData_d not supported on CPU
sse1_ChirpData_ak8h 0.046508 0.00000 choice[/pre]
Claggy
Hi! Ah I see, the app has
)
Hi!
Ah I see, the app has several code paths and selects the best one at runtime. Nice.
HB
RE: Thank you for your
)
The BOINC version I'm using now (6.12.34) doesn't list AVX as available, even on my rather new desktop with an Intel i7-2600 and Windows 7 SP1. Does it call it something else instead?
An idea of how to handle this - put both this AVX code and the non-AVX code into the same application program, and have it ask BOINC whether AVX is present in deciding which version of the code should be used. Requires that both give essentially the same answers, even if faster for AVX.
If Einstein@Home lacks a computer with AVX, they could create a Test application class and use it for test versions of new applications only. It should not be enabled for users by default; instead, only for volunteers that can find this setting and enable it.
Lack of a suitable compiler is a bigger problem, unless you can find some other way to generate object code from the new assembler routines, and in an object code format compatible with the preferred compiler.
I found some information on
)
I found some information on AVX:
http://software.intel.com/en-us/avx/
It looks like you'd need an Intel C++ compiler to use this information, and their only free version is an evaluation version that will work for only 30 days. Is that long enough? Also, can that compiler generate object code files that the preferred compiler can use?
RE: Hi! Ah I see, the app
)
Einstein@home did this some five years ago. It was a pain to maintain and compile (actually link) the code. The next step, which made maintenance easier and also improved performance, was to compile complete applications for different CPU features (from the same code), and add a 'switcher' that selected one of these based on the features of the CPU it was running on. Finally we arrived at the server making the decision which app to send based on information from the Client.
Given my previous experience with that approach I don't find it 'nice'. I would strongly vote for adding AVX detection and reporting to the BOINC Client.
BM
BM
I tried to compile the GW App
)
I tried to compile the GW App with various versions of icc a couple of times, the results being almost always disappointing. If it worked at all, the performance gain of the App was negligible or even negative compared to a gcc-compiled App with the 'hot loops' coded in sassembler.
I haven't tried the latest icc with AVX though, but I'm reluctant to put much work into that myself. If anyone out there want to try - the code is freely available and I would be happy to help him as much as I can (as much as my time allows).
BM
BM
GCC 4.6 should support AVX
)
GCC 4.6 should support AVX instructions as well.
http://gcc.gnu.org/gcc-4.6/changes.html
Quoted from the above URL:
"Support for Intel Core i3/i5/i7 processors with AVX is now available through the -march=corei7-avx and -mtune=corei7-avx options."
"AVX floating-point arithmetic can now be enabled by default at configure time with the new --with-fpmath=avx option."
Good to know, thx. Currently
)
Good to know, thx. Currently LALSuite doesn't compile cleanly with gcc-4.6, but I know that this is being worked on by the librarians.
BM
BM