Provide 64bit version of SpeedCrunch
Originally reported on Google Code with ID 355
With the release of Win7 more and more systems based on a 64bit system.
So more and more programs are offered in an old 32bit AND a new 64bit version.
Could SpeedCrunch be released in a 64bit version too?
It would be slightly faster and need no 32bit compatbility flag and no conversion VM
overhead stuff in a 64bit Win7.
It is only a simple re-compile with the 64bit flag
and should be creatable within minutes.
Thank you
Ben
Reported by bxstover@yahoo.co.uk
on 2010-08-23 15:59:25
Comments (18)
-
Account Deleted -
Account Deleted ``` Here is the source to prove my point. http://www.viva64.com/terminology/WoW64.html The performance penalty for WOW64 emu layer is about 2% Pretty marginal. Besides compiler optimization, I forgot to mention that CPUs need to frequently switch between x86 and x64 mode which cause delay. So, running x64 program in x64 OS will faster than x86 in x64 and x86 in x86 assuming modern CPU and enough RAM presented. Faster performance means energy efficiency and lower power consumption. ```
Reported by `cecilyen` on 2010-11-09 21:22:28
-
Account Deleted ``` ...are there any plans to compiled the 64bit version? ```
Reported by `bxstover@yahoo.co.uk` on 2011-12-02 10:06:36
-
Account Deleted ``` This might be not so easy to do as there isn't any official Qt SDK for windows 64bit (only 32bit), so the devs would need to recompile the whole framework first (I don't even know if the mingw compiler would support this). When Qt gets a win64bit support there probably won't be any problems to get windows 64bit binaries of apps written in it. ```
Reported by `cyberkiller8` on 2012-06-12 11:58:11
-
Account Deleted Reported by
helder.pereira.correia
on 2013-03-24 06:38:59 - Labels added: Type-Task, OpSys-Windows -
Account Deleted Reported by
helder.pereira.correia
on 2013-12-30 03:24:22 -
Account Deleted I'd say that the overhead of building 64-bit Qt, 64-bit SpeedCrunch and an extra installer is medium. It pays off if there is a real benefit for SpeedCrunch as 64-bit vs 32-bit version. As I understand (as already mentioned) the main benefits of 64-bit is handling of big data and more optimized CPU instructions. Does SpeedCrunch really profit from one of these, or is it rather lightweight on Memory and CPU? This is a genuine question, please give me some arguments as motivation :)
Reported by
alessandro.portale
on 2013-12-30 06:28:28 -
Account Deleted I don't think the user perception of the application is any better when built for 64-bit executable and machine. There is nothing computationally complex that would justify the improvement over the maintenance burden of added builds and downloads. At least at this point. I keep this an open matter though.
Reported by
helder.pereira.correia
on 2013-12-30 06:34:50 -
Account Deleted QT now provide pre-built 64-bit libraries for Windows, so at least you wouldn't have to manually compile QT any more.
Reported by
alan.n.davies
on 2013-12-31 09:57:41 -
Account Deleted We have to build our own with a much reduced feature set so that the binaries stay small.
Reported by
helder.pereira.correia
on 2014-01-01 19:32:08 -
Account Deleted 64-bit would allow for 4 294 967 296 times larger integers, among other things I don't know about.
Reported by
JouniJarvis
on 2014-07-31 23:00:37 -
Account Deleted I am searching the fetaure list of SpeedCrunch but don't find it. Anyways, I believe that the current 32-bit version can already handle much larger values than 2^31, due to it's own math library. But certainly that math library could benefit from 64-bit and compute even higher numbers faster.
Reported by
alessandro.portale
on 2014-08-01 06:48:48 -
Account Deleted The arbitrary precision of our math library wouldn't benefit from a 64-bit build at all. We don't use standard CPU floating point.
Reported by
helder.pereira.correia
on 2014-08-03 17:41:23 -
Account Deleted You should had said that in the first place.
Reported by
JouniJarvis
on 2014-08-03 18:02:25 -
Account Deleted The focus of the OP and the commentators that followed were not the math engine at all, unlike you.
Reported by
helder.pereira.correia
on 2014-08-03 18:17:28 -
Account Deleted Bah, my focus was figuring out what 64-bit would allow.
Reported by
JouniJarvis
on 2014-08-03 18:22:04 -
Account Deleted Maybe this makes difference: SpeedCrunch 0.11 x86: 2**664 = 7.65450517290209755773e+199 Python 3.4.2 x64: >>> ii=2**64 >>> for i in range(1024,1024*2): print( '%s\t\t%s'%(i,((2**i)/(ii))) ) 1024 9.7453140114e+288 1025 1.94906280228e+289 1026 3.89812560456e+289 1027 7.79625120912e+289 1028 1.559250241824e+290 1029 3.118500483648e+290 1030 6.237000967296e+290 1031 1.2474001934592e+291 1032 2.4948003869184e+291 1033 4.9896007738368e+291 1034 9.9792015476736e+291 1035 1.99584030953472e+292 1036 3.99168061906944e+292 1037 7.98336123813888e+292 1038 1.596672247627776e+293 1039 3.193344495255552e+293 1040 6.386688990511104e+293 1041 1.2773377981022207e+294 1042 2.5546755962044414e+294 1043 5.109351192408883e+294 1044 1.0218702384817765e+295 1045 2.043740476963553e+295 1046 4.087480953927106e+295 1047 8.174961907854212e+295 1048 1.6349923815708425e+296 1049 3.269984763141685e+296 1050 6.53996952628337e+296 1051 1.307993905256674e+297 1052 2.615987810513348e+297 1053 5.231975621026696e+297 1054 1.0463951242053392e+298 1055 2.0927902484106784e+298 1056 4.185580496821357e+298 1057 8.371160993642713e+298 1058 1.6742321987285427e+299 1059 3.3484643974570854e+299 1060 6.696928794914171e+299 1061 1.3393857589828342e+300 1062 2.6787715179656683e+300 1063 5.357543035931337e+300 1064 1.0715086071862673e+301 1065 2.1430172143725346e+301 1066 4.2860344287450693e+301 1067 8.572068857490139e+301 1068 1.7144137714980277e+302 1069 3.4288275429960554e+302 1070 6.857655085992111e+302 1071 1.3715310171984222e+303 1072 2.7430620343968443e+303 1073 5.486124068793689e+303 1074 1.0972248137587377e+304 1075 2.1944496275174755e+304 1076 4.388899255034951e+304 1077 8.777798510069902e+304 1078 1.7555597020139804e+305 1079 3.511119404027961e+305 1080 7.022238808055922e+305 1081 1.4044477616111843e+306 1082 2.8088955232223686e+306 1083 5.617791046444737e+306 1084 1.1235582092889474e+307 1085 2.247116418577895e+307 1086 4.49423283715579e+307 1087 8.98846567431158e+307 Traceback (most recent call last): File "<pyshell#6>", line 2, in <module> print( '%s\t\t%s'%(i,((2**i)/(ii))) ) OverflowError: integer division result too large for a float You can get the whole number of 8.98846567431158e+307 with http://www.easysurf.cc/scintd.htm
Reported by
JouniJarvis
on 2015-06-23 16:33:31 -
repo owner - changed status to wontfix
- Log in to comment
``` I think the penalty of using x86 binary in x64 OS is minimal. However, in general, x64 binary should run faster than x86 one because the compiler optimize the code according to modern CPU architecture instead of old 586 or even 486 architecture. I believe it worths the time to build native x64 binary for Windows. ```
Reported by `cecilyen` on 2010-11-09 16:42:33