64 bit desktop apps

[Mark Waddingham]

On 2017-06-07 22:14, hh via use-livecode wrote:
> 64bit mode usually makes apps slower. So what's Apple's intention?
> To make their own apps "relatively faster" by making all others slower?

Do you have some benchmarks to back that up? I'd be interested to know 
what sort of workloads the difference in processor affects.

For example, I ran the simple benchmarks we have in the engine source 
tree using Community 8.1.3 once for 32-bit and once for 64-bit. The 
first number is 64-bit, the second 32-bit:

Running RepeatForever...
	3152 / 3136 ms
Running RepeatCount...
	526 / 523 ms
Running RepeatWith...
	407 / 412 ms
Running ArrayNameKeys...
	Store[] 291 / 266 ms
	Fetch[] 215 / 217 ms
	Store[][] 465 / 413 ms
	Fetch[][] 318 / 313 ms
Running ArrayIndexKeys...
	Store[] 831 / 833 ms
	Fetch[] 734 / 681 ms
	Store[][] 1448 / 1403 ms
	Fetch[][] 1278 / 1253 ms
Running ArrayStringKeys...
	Store[] 309 / 313 ms
	Fetch[] 215 / 261 ms
	Store[][] 471 / 493 ms
	Fetch[][] 345 / 387 ms
Running VariableFetchLocal...
	Get Base 23 / 22 ms
	Get Base[<name>] 120 / 141 ms
	Get Base[<number>] 583 / 661 ms
	Get Base[<string>] 151 / 171 ms
	Get Base[<seq-1>] 307 / 310 ms
	Get Base[<name>][<name>] 152 / 177 ms
	Get Base[<number>][<number>] 1072 / 1081 ms
	Get Base[<string>][<string>] 214 / 240 ms
	Get Base[<seq-2>] 454 / 463 ms
Running VariableStoreLocal...
	Replace Into Base 32 / 31 ms
	Replace Into Base[<name>] 39 / 34 ms
	Replace Into Base[<number>] 180 / 174 ms
	Replace Into Base[<string>] 44 / 41 ms
	Replace Into Base[<seq-1>] 93 / 78 ms
	Replace Into Base[<name>][<name>] 48 / 42 ms
	Replace Into Base[<number>][<number>] 304 / 285 ms
	Replace Into Base[<string>][<string>] 61 / 54 ms
	Replace Into Base[<seq-2>] 120 / 121 ms

So, certainly for variable access and repeat loop overhead, the 
differences are within the margin of error for such measurements - which 
would probably go away if I ran them on a completely empty machine and 
with increased number of iterations. The story is the exactly the same 
for the 'strings' benchmarks we have there too.

Most of Apple's apps are 64-bit only and have been for quite some time 
as there is no value in them shipping universal versions on any OS since 
10.6 (the only reason they would have done in previous versions is for 
apps which they had not yet ported to Cocoa and away from QuickTime) - 
all that does is waste download bandwidth and disk space.

Also, on the whole, Intel 64-bit machine code is can be much more 
efficient than 32-bit. The 64-bit Intel architecture actually has a 
measurable number of registers! 32-bit Intel processors have a huge 
amount of logic inside them to alias memory locations and such 
(essentially meaning memory accesses under specific conditions are akin 
to accessing registers). Of course all that costs silicon which could be 
used for better things - like caching and multiple cores. Basically, the 
64-bit Intel architecture is superior to the 32-bit one which does show 
its age quite a bit.

FWIW, when we got LiveCode on 64-bit Linux, Fraser did some performance 
tests which indicated on the whole, it ran about 5-10% faster than its 
32-bit counterpart. This was, admittedly, mainly in the area of graphics 
- since the types of things you do to rasterize graphics at this level 
benefits disproportionately from the number of registers available.

The thing is that most users won't ever notice whether an app is 32-bit 
or 64-bit because Apple's approach (universal binaries) means that it 
isn't possible to tell unless you go digging in Activity Monitor. (One 
would expect for this to be the case - Apple have done the processor 
architecture switch thing 3 times now - and in those cases it was to 
completely different architectures).

The main reason to not bother with 32-bit builds when there is no reason 
to is that it makes you much more efficient from the engineering point 
of view. It removes any question (when writing code) as to whether "is 
this correct for 32 and 64-bit" (admittedly, you try and structure your 
source base so only specific areas suffer from this overhead - but it 
still is there in the back of your mind). It means you only have to 
compile your source-base once (you don't magically get 64-bit code when 
compiling, you compile once for 32-bit and once for 64-bit). It 
eliminates one split in the test matrix. It halves the size of all your 
code deliverables - which is good for disk space and bandwidth (which, 
whilst less of an issue as time goes on - people do still tend to notice 
the difference between 500Mb download a 1Gb download!).

So, the reason Apple are doing it will undoubtedly be because of 
efficiency. It means they can focus all their energies on 64-bit Intel 
architecture (for Mac), and put all there resources into building and 
testing the 64-bit version of Mac.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps