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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
