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 Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to