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. _______________________________________________ use-livecode mailing list email@example.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode