It looks like 7h WUs will take about 10h.
OpenSuSE 10.3, AMD X2 65nm.
A real snail. :(
cu,
Michael
This looks like as if the code is not 64 bit clean. Possibly an issue in Pointer lengths in ComputeFStatistic.c ....
but i could be wrong ....
Well I think as soon there is a 64Bit Windows app, Akos will have a deeper look in the asm code. If it's true that he doesn't have the source, that's all he can do. But if you look at his Intel and his AMD quad, you can get an impression what can be done. :)
Well I think as soon there is a 64Bit Windows app, Akos will have a deeper look in the asm code. If it's true that he doesn't have the source, that's all he can do. But if you look at his Intel and his AMD quad, you can get an impression what can be done. :)
cu,
Michael
Well there' one thing that won't work ... there's NO inline asm support in vs2005 for 64 bit, so you need to use intrinsics instead ... or rewrite the code to use some external calls to the asm stuff...
EDIT
Second thing that won't work is that you cannot call a 64 bit compiler from the 32 bit cygwin environment that is used to compile the windows apps.
Wich leads to great trouble building "lal" since you have to create a solution file for this/and rework the script beeing used to compile the app ... (gsl, fftw3 etc compiles fine under vs2005)
Well there' one thing that won't work ... there's NO inline asm support in vs2005 for 64 bit, so you need to use intrinsics instead
If you would write an intrinsics version of the SSE code I'd be happy to put it into the source code. Probably my AltiVec version of the HotLoop is a better starting point for this than the current assembler version.
If you would write an intrinsics version of the SSE code I'd be happy to put it into the source code. Probably my AltiVec version of the HotLoop is a better starting point for this than the current assembler version.
BM
sorry but i don't have the time to do this. However first starting point would be to get rid of the cygwin stuff and building the lal or lalsupport libs natively as a vs solution.
However if you think you can't go that way, well you could try using the mingw cross compiler on a 64 bit linux to build native 64 bit windows apps.
It works and i already tested that one.
But IMO that's the wrong way to go...
Anyhow, there are at least 10 qualified programmers participating on E@H that could help you getting your code working....
To sad to see that E@H is open source since 2007 and the code is beeing held back since that...
And the Linux 64 bits 4.28 app now seems to confirm this (no cygwin there, no problems with inline assembler either). So if you don't expect any speedup, why go thru all the pain of changing the whole build process under windows?
And the Linux 64 bits 4.28 app now seems to confirm this (no cygwin there, no problems with inline assembler either). So if you don't expect any speedup, why go thru all the pain of changing the whole build process under windows?
Bikeman
no you got that wrong... sure i won't be faster the way it is compiled now cuz it's done the WRONG way.
As we've seen the code is not 64 bit clean... due to some "long"... issues ;)
However, if the code would be clean it's easy to get a speedup by at least 10% since we can safely assume that ANY 64 bit capable cpu running a 64 bit OS is able to use SSE2 instruction set... get the drift ?
Ok, I finished 2 WUs which took more than 41 ks instead of <25 ks. :(
At least it's really positive that there finally is a start in the 64Bit era. :)
Reading the AMD specs about 64Bit coding and optimizing for speed gives the impression to me, that it might be a lot of work until this app is performing well.
Imho it would be a good idea to give the source to some volunteer developers, because work done for 64Bit apps will probable be of little benefit for 32Bit apps. On the other side I don't think it will take too long until the 32Bit era is over.
After "downgrading" to 4.27 I get the following messages in my logfile:
2008-02-11 09:51:50 [Einstein@Home] Sending scheduler request: To fetch work
2008-02-11 09:51:50 [Einstein@Home] Requesting 360288 seconds of new work
2008-02-11 09:52:00 [Einstein@Home] Scheduler RPC succeeded [server version 601]
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__447_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0763.30_S5R2__140_S5R3a_2
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__446_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__445_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__444_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__443_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] Deferring communication for 6 min 28 sec
2008-02-11 09:52:00 [Einstein@Home] Reason: no work from project
It looks like 7h WUs will
)
It looks like 7h WUs will take about 10h.
OpenSuSE 10.3, AMD X2 65nm.
A real snail. :(
cu,
Michael
RE: It looks like 7h WUs
)
This looks like as if the code is not 64 bit clean. Possibly an issue in Pointer lengths in ComputeFStatistic.c ....
but i could be wrong ....
RE: RE: It looks like 7h
)
Well I think as soon there is a 64Bit Windows app, Akos will have a deeper look in the asm code. If it's true that he doesn't have the source, that's all he can do. But if you look at his Intel and his AMD quad, you can get an impression what can be done. :)
cu,
Michael
RE: Well I think as soon
)
Well there' one thing that won't work ... there's NO inline asm support in vs2005 for 64 bit, so you need to use intrinsics instead ... or rewrite the code to use some external calls to the asm stuff...
EDIT
Second thing that won't work is that you cannot call a 64 bit compiler from the 32 bit cygwin environment that is used to compile the windows apps.
Wich leads to great trouble building "lal" since you have to create a solution file for this/and rework the script beeing used to compile the app ... (gsl, fftw3 etc compiles fine under vs2005)
/EDIT
RE: Well there' one thing
)
If you would write an intrinsics version of the SSE code I'd be happy to put it into the source code. Probably my AltiVec version of the HotLoop is a better starting point for this than the current assembler version.
BM
BM
RE: If you would write an
)
sorry but i don't have the time to do this. However first starting point would be to get rid of the cygwin stuff and building the lal or lalsupport libs natively as a vs solution.
However if you think you can't go that way, well you could try using the mingw cross compiler on a 64 bit linux to build native 64 bit windows apps.
It works and i already tested that one.
But IMO that's the wrong way to go...
Anyhow, there are at least 10 qualified programmers participating on E@H that could help you getting your code working....
To sad to see that E@H is open source since 2007 and the code is beeing held back since that...
good luck to you all
@crunch3er As you have
)
@crunch3er
As you have noted yourself in another thread:
which I absolutely agree to.
And the Linux 64 bits 4.28 app now seems to confirm this (no cygwin there, no problems with inline assembler either). So if you don't expect any speedup, why go thru all the pain of changing the whole build process under windows?
Bikeman
RE: @crunch3er As you have
)
no you got that wrong... sure i won't be faster the way it is compiled now cuz it's done the WRONG way.
As we've seen the code is not 64 bit clean... due to some "long"... issues ;)
However, if the code would be clean it's easy to get a speedup by at least 10% since we can safely assume that ANY 64 bit capable cpu running a 64 bit OS is able to use SSE2 instruction set... get the drift ?
the rest ... you'll figure out by yourself ;)
Ok, I finished 2 WUs which
)
Ok, I finished 2 WUs which took more than 41 ks instead of <25 ks. :(
At least it's really positive that there finally is a start in the 64Bit era. :)
Reading the AMD specs about 64Bit coding and optimizing for speed gives the impression to me, that it might be a lot of work until this app is performing well.
Imho it would be a good idea to give the source to some volunteer developers, because work done for 64Bit apps will probable be of little benefit for 32Bit apps. On the other side I don't think it will take too long until the 32Bit era is over.
cu,
Michael
After "downgrading" to 4.27 I
)
After "downgrading" to 4.27 I get the following messages in my logfile:
2008-02-11 09:51:50 [Einstein@Home] Sending scheduler request: To fetch work
2008-02-11 09:51:50 [Einstein@Home] Requesting 360288 seconds of new work
2008-02-11 09:52:00 [Einstein@Home] Scheduler RPC succeeded [server version 601]
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__447_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0763.30_S5R2__140_S5R3a_2
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__446_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__445_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__444_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__443_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] Deferring communication for 6 min 28 sec
2008-02-11 09:52:00 [Einstein@Home] Reason: no work from project
This has happened a couple of times already.
cu,
Michael