There will definitely be diminishing returns on the efforts. If you provide SSE2, then I'm sure people will want SSE3, SSSE3, SSE4, etc... My guess, based on what is being seen with SETI, is that SSE3 is where meaningful improvements would stop. For AMD processors, it became apparent that SSE3 had negligible differences (perhaps due to missing HyperThreading?)...
In the new code we tried to avoid double precision as much as possible, so we already can perform most calculations in SSE. In the two functions that take the most time there is not much left to the compiler to optimize. Benefits from double-precision vectorization, more registers etc. are actually pretty minimal (e.g. the current kernel loop only uses 5 of 8 xmm registers, there is simply no benefit from having twice as many or even more).
There are a few specific features of SSE2 that are helpful, but only if the instructions are carefully placed into the code, probably in assembler (inline assembler in the code or using some well-coded math library). The full-blown 64Bit/SSE2 experiment where I left most to the compiler was nothing less than disappointing.
I installed the app on my Kubuntu 64 laptop, as well as my old Slackware 12.0 Athlon 1200. The Kubuntu laptop runs the _1 app, and the Slack box runs the _0 app since it doesn't have SSE. Looks good so far. Don't give up on the 64 bit Linux app, though. I and I'm sure several others are chomping at the bit to test the next version. It's something that'll have to be done sooner rather than later as it'll get harder and harder to find a new 32 bit machine after another year or two.
It's something that'll have to be done sooner rather than later as it'll get harder and harder to find a new 32 bit machine after another year or two.
True, but I guess the transition on the software (Operating System) side will be much slower, at least for the consumer segment. Most retail consumer PCs are perfectly 64bit capable now but still sold with 32bit Vista or XP editions installed. Those installations will have to be supported for many years to come (just as E@H now still supports non SSE hardware). The 64 bit OSes are pretty good at running 32 bit applications, so personally I don't see any urgency to offer native 64bit apps, unless there is a way to get a real significant performance boost from it.
I installed the new app, too, and so far it seems to be running okay in terms of not showing signs of immediate crashes and my SSE capable CPU running the faster Nr. 1 app...
True, but I guess the transition on the software (Operating System) side will be much slower, at least for the consumer segment. Most retail consumer PCs are perfectly 64bit capable now but still sold with 32bit Vista or XP editions installed. Those installations will have to be supported for many years to come (just as E@H now still supports non SSE hardware). The 64 bit OSes are pretty good at running 32 bit applications, so personally I don't see any urgency to offer native 64bit apps, unless there is a way to get a real significant performance boost from it.
Without a major gain from a 64 bit OS I suspect most people will still run 32bits for the next few years. The only userworld apps that currently benefit from the extra ram addressing are image/music/video editing software.
Games will probably start to show a benefit in annother year or two. At the higher end 2GB is already more or less needed, and newer generations of gfx card will eat ever larger chunks of the address space for DMA to their memory so there's not much headroom left in win32.
For the much simpler needs of Joe Intarweb there's nothing really on the horizon that would need the extra ram. Vista's memory hungry, but unless you're using heavy duty software there's little gain above 2GB. Eventually this'll change due to 3rd party bloat (I'm waiting for HP to start shipping drivers on a DVD to avoid needing multiple CDs), but except possibly to reduce the total number of SKUs they need to maintain I don't expect to see Dell, HP, etc start selling Vista64 on consumer machines anytime soon.
I'd be surprised if windows7 isn't 64bit only, but that's ETA 2011.
I'd be surprised if windows7 isn't 64bit only, but that's ETA 2011.
I would be surprised if it is 64bit only, Intel is still making very capable laptop CPUs based on Core Duo that are not 64bit capable, those will not be outdated by 2011. For 4GB+ memory theres always PAE, if a few geeks can make it work perfectly on Linux desktops theres no good reason why the MS army of programmers cant do it.
I'd be surprised if windows7 isn't 64bit only, but that's ETA 2011.
I would be surprised if it is 64bit only, Intel is still making very capable laptop CPUs based on Core Duo that are not 64bit capable, those will not be outdated by 2011. For 4GB+ memory theres always PAE, if a few geeks can make it work perfectly on Linux desktops theres no good reason why the MS army of programmers cant do it.
If MS was concerned about making it's latest and greatest run on old hardware you'd probably be right. While true at one point, unfortunately I don't think that's the case anymore. *cough*VistaRamRequirements*cough*. Intel's already largely phased the core duo family out except in the lowest performing segment of the market, and given their plans to largely due the same with the 65nm core2 series this year except for a long thin tail for embedded systems the core1 architecture's not going to be around much longer.
Regarding PAE I think it's a nonstarter at this point. MS was able to make all of it's software work, but they can't force 3rd party software/driver writers to do the same. PAE was a bandaid until true 64bit hardware was available, and for nonWTFy code changing to native 64 bit is suppoosed to be alot easier. On windows PAE never really went beyond the high end server market in any meaningful way. Excepting legacy devices the makers no longer care about win64 driver support is supposed to be a dead issue at this point, and alot of media creation applications are available in 64bit versions already.
EDIT: highend windows server software's going 64bit only rather than maintianing both 64 and 32-pae codebases which would farther argue against new apps moving to PAE instead of x64.
RE: There will definitely
)
In the new code we tried to avoid double precision as much as possible, so we already can perform most calculations in SSE. In the two functions that take the most time there is not much left to the compiler to optimize. Benefits from double-precision vectorization, more registers etc. are actually pretty minimal (e.g. the current kernel loop only uses 5 of 8 xmm registers, there is simply no benefit from having twice as many or even more).
There are a few specific features of SSE2 that are helpful, but only if the instructions are carefully placed into the code, probably in assembler (inline assembler in the code or using some well-coded math library). The full-blown 64Bit/SSE2 experiment where I left most to the compiler was nothing less than disappointing.
BM
BM
I installed the app on my
)
I installed the app on my Kubuntu 64 laptop, as well as my old Slackware 12.0 Athlon 1200. The Kubuntu laptop runs the _1 app, and the Slack box runs the _0 app since it doesn't have SSE. Looks good so far. Don't give up on the 64 bit Linux app, though. I and I'm sure several others are chomping at the bit to test the next version. It's something that'll have to be done sooner rather than later as it'll get harder and harder to find a new 32 bit machine after another year or two.
RE: It's something that'll
)
True, but I guess the transition on the software (Operating System) side will be much slower, at least for the consumer segment. Most retail consumer PCs are perfectly 64bit capable now but still sold with 32bit Vista or XP editions installed. Those installations will have to be supported for many years to come (just as E@H now still supports non SSE hardware). The 64 bit OSes are pretty good at running 32 bit applications, so personally I don't see any urgency to offer native 64bit apps, unless there is a way to get a real significant performance boost from it.
CU
Bikeman
I installed the new app, too,
)
I installed the new app, too, and so far it seems to be running okay in terms of not showing signs of immediate crashes and my SSE capable CPU running the faster Nr. 1 app...
RE: True, but I guess the
)
Without a major gain from a 64 bit OS I suspect most people will still run 32bits for the next few years. The only userworld apps that currently benefit from the extra ram addressing are image/music/video editing software.
Games will probably start to show a benefit in annother year or two. At the higher end 2GB is already more or less needed, and newer generations of gfx card will eat ever larger chunks of the address space for DMA to their memory so there's not much headroom left in win32.
For the much simpler needs of Joe Intarweb there's nothing really on the horizon that would need the extra ram. Vista's memory hungry, but unless you're using heavy duty software there's little gain above 2GB. Eventually this'll change due to 3rd party bloat (I'm waiting for HP to start shipping drivers on a DVD to avoid needing multiple CDs), but except possibly to reduce the total number of SKUs they need to maintain I don't expect to see Dell, HP, etc start selling Vista64 on consumer machines anytime soon.
I'd be surprised if windows7 isn't 64bit only, but that's ETA 2011.
RE: I'd be surprised if
)
I would be surprised if it is 64bit only, Intel is still making very capable laptop CPUs based on Core Duo that are not 64bit capable, those will not be outdated by 2011. For 4GB+ memory theres always PAE, if a few geeks can make it work perfectly on Linux desktops theres no good reason why the MS army of programmers cant do it.
Team Philippines
RE: RE: I'd be surprised
)
If MS was concerned about making it's latest and greatest run on old hardware you'd probably be right. While true at one point, unfortunately I don't think that's the case anymore. *cough*VistaRamRequirements*cough*. Intel's already largely phased the core duo family out except in the lowest performing segment of the market, and given their plans to largely due the same with the 65nm core2 series this year except for a long thin tail for embedded systems the core1 architecture's not going to be around much longer.
Regarding PAE I think it's a nonstarter at this point. MS was able to make all of it's software work, but they can't force 3rd party software/driver writers to do the same. PAE was a bandaid until true 64bit hardware was available, and for nonWTFy code changing to native 64 bit is suppoosed to be alot easier. On windows PAE never really went beyond the high end server market in any meaningful way. Excepting legacy devices the makers no longer care about win64 driver support is supposed to be a dead issue at this point, and alot of media creation applications are available in 64bit versions already.
EDIT: highend windows server software's going 64bit only rather than maintianing both 64 and 32-pae codebases which would farther argue against new apps moving to PAE instead of x64.
Working fine on my Fedora 7
)
Working fine on my Fedora 7 box.
Kathryn :o)
Einstein@Home Moderator
core_client_version
)
core_client_version 5.10.28
Detected CPU type 1 (automatically detected)
resultid=93030004
the result is much faster on my ubuntu linux 7.10
4.31 round 32000 sec
4.38 round 21000 sec
no problems at all, next result will finish in short time.
kboincspy told me round 7000 MegaFLOPS for 4.31
and round 10000 MegaFLOPS for 4.38 with CPU type 1
Matthias
It works fine with Ubuntu
)
It works fine with Ubuntu 7.10 for SSE capable comp.