Provide 64bit version of SpeedCrunch

[Former user]

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 [e-mail] on 2010-08-23 15:59:25

[Former user]

``` 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

[Former user]

``` 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

[Former user]

``` ...are there any plans to compiled the 64bit version? ```

Reported by `[e-mail]` on 2011-12-02 10:06:36

[Former user]

``` 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

[Former user]

Reported by helder.pereira.correia on 2013-03-24 06:38:59 - Labels added: Type-Task, OpSys-Windows

[Former user]

Reported by helder.pereira.correia on 2013-12-30 03:24:22

[Former user]

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

[Former user]

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

[Former user]

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

[Former user]

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

[Former user]

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

[Former user]

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

[Former user]

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

[Former user]

You should had said that in the first place.

Reported by JouniJarvis on 2014-08-03 18:02:25

[Former user]

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

[Former user]

Bah, my focus was figuring out what 64-bit would allow.

Reported by JouniJarvis on 2014-08-03 18:22:04

[Former user]

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