64 bit desktop apps

[hh]

Thanks for the enlightening explanation.
Of course I don't go into a technical discussion with an expert.

Only two remarks:

1) You are comparing 64bit and 32bit modes on a 64bit architecture.
This is the correct answer for my cheeky post above (by the way that
wasn't targeted, to the special case LiveCode and was a bit caused by
the fact that the first 64bit-Finder was 80-100% slower than the 32bit
variant).

2) My simple user experiences are that some 32bit apps perform on a
32bit architecture obviously faster than the 64bit variant on 64bit
architecture.

For example on Mac LC 6.5-standalones run the same optimized code (with
large imageData) on 32bit-architecture/slower CPU still 3-5 times faster
than the 64bit-LC 8.1.4 standalones variant on 64bit-architecture.

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