From a friend with the low-end MacBook Pro (base model $999): 4K video
stream editing in real time with no dropouts, 11 hours of streaming
YouTube video on battery.
Compiling an app in Xcode was so much faster they didn't believe it
had compiled (took several minutes on the Intel MacBook Pro 13" 4 TB4
port machine). Apps open "shockingly fast."
From a friend with the low-end MacBook Pro (base model $999): 4K video
stream editing in real time with no dropouts, 11 hours of streaming
YouTube video on battery.
Compiling an app in Xcode was so much faster they didn't believe it had compiled (took several minutes on the Intel MacBook Pro 13" 4 TB4 port machine). Apps open "shockingly fast."
From a friend with the low-end MacBook Pro (base model $999): 4K video
stream editing in real time with no dropouts, 11 hours of streaming
YouTube video on battery.
On 2020-11-17 13:01, Lewis wrote:
From a friend with the low-end MacBook Pro (base model $999): 4K video
stream editing in real time with no dropouts, 11 hours of streaming
YouTube video on battery.
Have now seen proper benchmarks (more coming I am sure) and the
performance compared to previous Mac Books is much higher, and thermal thorottling on the fan-less MacBook Air only starts after about 10
miunutes of heavy duty use.
Surprised Apple didn't put out proper benchmark results in its keynote
if the machines were so good. The keynote made it look like a lot of marketing vapourware with their meaningless performance graphs without
any numbers/scale.
On 2020-11-17 13:01, Lewis wrote:
From a friend with the low-end MacBook Pro (base model $999): 4K video
stream editing in real time with no dropouts, 11 hours of streaming
YouTube video on battery.
Have now seen proper benchmarks (more coming I am sure) and the
performance compared to previous Mac Books is much higher, and thermal thorottling on the fan-less MacBook Air only starts after about 10
miunutes of heavy duty use.
Surprised Apple didn't put out proper benchmark results in its keynote
if the machines were so good. The keynote made it look like a lot of marketing vapourware with their meaningless performance graphs without
any numbers/scale.
On 2020-11-18, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
On 2020-11-17 13:01, Lewis wrote:
From a friend with the low-end MacBook Pro (base model $999): 4K video
stream editing in real time with no dropouts, 11 hours of streaming
YouTube video on battery.
Have now seen proper benchmarks (more coming I am sure) and the
performance compared to previous Mac Books is much higher, and thermal
thorottling on the fan-less MacBook Air only starts after about 10
miunutes of heavy duty use.
Surprised Apple didn't put out proper benchmark results in its keynote
if the machines were so good. The keynote made it look like a lot of
marketing vapourware with their meaningless performance graphs without
any numbers/scale.
phooey to benchmarks!
it's the experience that counts, and it's truly amazing
Apple's engineers have done an astonishing job with M1
phooey to benchmarks!
Yes, like when editing a 4K video?
Are you really? Or are you just doing your usual FUD trolling? Because
Apple does not put out "proper benchmark results" and never has. Mostly because nearly no one cares but also because they are mostly
meaningless. What matters i s "how much faster can I do X" and there was plenty of that.
Hint: geek bench saw no difference between MacBook Air and Pro. But the
more elaborate ones did (though not as big as expected) because
eventually the Air does throttle down due to heat.
It was a missed opportunity for Apple.
On 2020-11-18 04:22, Joanna Shuttleworth wrote:
phooey to benchmarks!
When rendering of a video is done in minutes instead of hours, it makes
a huge difference to the "experience". Geekbench does a quick and
dirty test, but the more advanced benchmarks (such as the cinema 4D one)
will test the machine in a load similar to rendering a long video. This
means using all cores long enough to trigger any head mitigation (fans
and/or slowing down speed).
Hint: geek bench saw no difference between MacBook Air and Pro. But the
more elaborate ones did (though not as big as expected) because
eventually the Air does throttle down due to heat.
On 2020-11-18 09:51, Lewis wrote:
Yes, like when editing a 4K video?
Editing a 4K video with only 8GB of RAM may work if tyat video is 10
seconds long, but doubtful we're talking about editing a full episode
of Mandalorians with all the special effects.
Are you really? Or are you just doing your usual FUD trolling? Because
Apple does not put out "proper benchmark results" and never has. Mostly
because nearly no one cares but also because they are mostly
meaningless. What matters i s "how much faster can I do X" and there was
plenty of that.
Apple focused a LOT on videos editing during keynote. There are 2
classes of usesr that really care about real performance: video editors
and gamers (who rely more on the GPU).
It was a missed opportunity for Apple.
I think it was Dan Moren from Six Colors who said on a podcast that
rendering an 80GB 4K video on a MacBook Air took about 205%
On 2020-11-18 09:51, Lewis wrote:
Yes, like when editing a 4K video?
Editing a 4K video with only 8GB of RAM may work if tyat video is 10
seconds long, but doubtful we're talking about editing a full episode
of Mandalorians with all the special effects.
Are you really? Or are you just doing your usual FUD trolling? Because
Apple does not put out "proper benchmark results" and never has. Mostly
because nearly no one cares but also because they are mostly
meaningless. What matters i s "how much faster can I do X" and there was
plenty of that.
Apple focused a LOT on videos editing during keynote. There are 2
classes of usesr that really care about real performance: video editors
and gamers (who rely more on the GPU).
If the target audience was video editing, then yes, Apple should have
had real benchmarks since the M1 macs appear to have substantial
erformance improvements. But having vague grand statements, graphs
without any numbers/scale, it poited to Apple not being too happy with performance and not wantint to provide real numbers.
It was a missed opportunity for Apple.
Also, the MacBook Air M1 is faster emulating/translating Intel code that
the Intel chips running the code natively.
On 2020-11-20 12:28:53 +0000, Lewis said:
<snip>
Also, the MacBook Air M1 is faster emulating/translating Intel code that
the Intel chips running the code natively.
I'm not exactly sure what you're alluding to here. Maybe you mean
running Intel code Windows apps under Crossover or similar.
The M1 doesn't translate Intel Mac apps on the fly like the old Rosetta
or emaultors like VirtualPC did. M1 Macs translate Intel apps only
*once*, the first time they're opened (which means it can take a while
for the app to open that first time - Microsoft have said it can take up
to 20secs with their Office apps). After that the apps are always
running natively on Apple Silicon via a Universal Binary app,
Further, you can force Rosetta x86 even if the arm code is in the
binary. <quibble=off).
... mostly, <quibble=on> but some plugins may need to be JIT, kexts
(which are on their way out). Further, you can force Rosetta x86 even
if the arm code is in the binary. <quibble=off).
For example, if you want to install homebrew, you do this by forcing Terminal.app (or whatever terminal emulator you use) to run as x86, at
which point Homebrew happily installs and compiles everything.
On 2020-11-20 16:44, Lewis wrote:
For example, if you want to install homebrew, you do this by forcing
Terminal.app (or whatever terminal emulator you use) to run as x86, at
which point Homebrew happily installs and compiles everything.
If terminal.App runs as a translated image, it may create the window,
window decorations and drive the user in put and didsplay in translated
mode, but wouldn't the bash environment that is created (with input and output to the therminal) not be ARM native ?
Does Rosetta 2 kicks in when you try to run a unx/command line binary compiled for Intel? If so, how does the "fat binary" get stored when
Unix binaries don't have the .app directory structure ?
On 2020-11-20 16:11, Alan Browne wrote:
... mostly, <quibble=on> but some plugins may need to be JIT, kexts
(which are on their way out). Further, you can force Rosetta x86 even
if the arm code is in the binary. <quibble=off).
Have not seen any information on whether the JIT capability is real time emulation, or whether Rosetta takes the JOT code, translates it all and
then branches to it. Since the logic in Rosetta 2 was designed for
"batch" translation, I would suspect the JIT aspect still takes all the
Intel code, translates it and then branches to it, as opposed to Rosetta
2 having not only a translator but also real time emulator.
On 2020-11-20 16:11, Alan Browne wrote:
... mostly, <quibble=on> but some plugins may need to be JIT, kexts
(which are on their way out). Further, you can force Rosetta x86 even
if the arm code is in the binary. <quibble=off).
Have not seen any information on whether the JIT capability is real time emulation,
You suspect it... ...based on nothing.
On 2020-11-20 22:34, Alan Baker wrote:
You suspect it... ...based on nothing.
Translators and emulators and extremely different beasts. Apple, wrote a translator for Rosetta 2. It would make sense for it to process JOt by letting it download, translate it and then branch to it, instead of
Apple having written an emulator that can run the JOT real time, like
Rosetta or the 68k to PowerPC emulator.
You're thinking it will be a very narrowly scoped thing. Apple didn't invest billions in the transition to go cheap on Rosetta 2.
Very
little will be JIT translated.
Rosetta 2 is a temporary thing.
On 2020-11-20 22:34, Alan Baker wrote:
You suspect it... ...based on nothing.
Translators and emulators and extremely different beasts. Apple, wrote a translator for Rosetta 2. It would make sense for it to process JOt by letting it download, translate it and then branch to it, instead of
Apple having written an emulator that can run the JOT real time, like
Rosetta or the 68k to PowerPC emulator.
On 2020-11-22 18:48, Alan Browne wrote:
You're thinking it will be a very narrowly scoped thing. Apple didn't
invest billions in the transition to go cheap on Rosetta 2.
Rosetta 2 is a temporary thing. With Apple having pruned off all old
code by renmoving ability to run 32 buts in previous version, all that
is left in the ecosystem are 64 bit apps that are current and being developped, so the transition will happen very fast.
Very
little will be JIT translated.
Rhe examples provided by Apple are plug-ins that are downloaded by app
and executed. (think pre-compiled java)
Doesn't mean Rosetta is not a much more capable thing than you're claiming.
On 2020-11-23 16:52, Alan Browne wrote:
Doesn't mean Rosetta is not a much more capable thing than you're claiming.
Apple planned thsi transition better than previous ones by removing all legacy APIs, removing all 32 biut support before transition started.
This means Rosetta 2 is much simpler than previous architecture
emulators, and more importantly, because Apple culled dead applicatiosn
when it renoved support for 32 bits and older APIs, there are a lot
fewer "dead" application that will remain Intel forever, which means
the expected need for Rosetta 2 will be shorter than Rosetta or the
emulator between 68K and PowerpC.
Prettyu sire Apple will monitor JIT Rosetta 2 need and what types of applications ise it. Would a natime ARM application request JIT content
that is x86 binary? Or would they request Java "neutral" code that runs
on any platform? It really depends on the types of JIT that will feed
the computer x86 binary code ocne the app has been compiled native for ARM.
On 2020-11-23 16:52, Alan Browne wrote:
Doesn't mean Rosetta is not a much more capable thing than you're claiming.
Apple
On 2020-11-24 01:05, JF Mezei wrote:
On 2020-11-23 16:52, Alan Browne wrote:
Doesn't mean Rosetta is not a much more capable thing than you're claiming. >>Apple
Blather snipped. Still waiting on the citation/link to your other claim about Rosetta.
You're going to be waiting for the end of time to hurry up and arrive
before you get that from FUDmiester.
https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code
On 2020-11-25 10:01, Lewis wrote:
You're going to be waiting for the end of time to hurry up and arrive
before you get that from FUDmiester.
IO cannot find exact text as the only page on the Apple Developper that
I can find on Rosetta 2 is very generitc and without details.
I woudl have to go back to my posting to see when I first found out
about how Rosetta worked, as I suspect now thatr it was a hint given
during keynote. I had been very curious on how Apple would do it from he
June announcement so had eyes and ears open.
One hint that what I am saying is true:
The inability for a native ARM to invoke translated code (hence the
ability to launch the tramslated version of the app even if a native ARM
is available).
COnsider that the translated unit will expect arguments in Intel format
and return in Intel format (or does callbacks in Intel formats), while
the native ARM code expects subroutines intrerfaces with the ARM format/stsnaard for argument passing, register saving etc. If you invoke
the translated main program, it does all its calls in Intel format and
can then interface with other translated modules that are also Intel
format calling standard.
Another hint of the differences in Intel vs ARM calling standard:
https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code
Don't Redeclare a Function to Have Variable Parameters
The x86_64 and arm64 architectures have different calling conventions
for variadic functions—functions with a variable number of parameters.
On 2020-11-25 10:01, Lewis wrote:
You're going to be waiting for the end of time to hurry up and arrive
before you get that from FUDmiester.
IO cannot find exact text as the only page on the Apple Developper that
I can find on Rosetta 2 is very generitc and without details.
I woudl have to go back to my posting to see when I first found out
about how Rosetta worked, as I suspect now thatr it was a hint given
during keynote. I had been very curious on how Apple would do it from he
June announcement so had eyes and ears open.
COnsider that the translated unit will expect arguments in Intel format
and return in Intel format (or does callbacks in Intel formats), while
the native ARM code expects subroutines intrerfaces with the ARM
Another hint of the differences in Intel vs ARM calling standard:
On 2020-11-25 10:01, Lewis wrote:
You're going to be waiting for the end of time to hurry up and arrive
before you get that from FUDmiester.
IO cannot find exact text as the only page on the Apple Developper that
I can find on Rosetta 2 is very generitc and without details.
I woudl have to go back to my posting to see when I first found out
about how Rosetta worked, as I suspect now thatr it was a hint given
during keynote. I had been very curious on how Apple would do it from he
June announcement so had eyes and ears open.
One hint that what I am saying is true:
The inability for a native ARM to invoke translated code (hence the
ability to launch the tramslated version of the app even if a native ARM
is available).
COnsider that the translated unit will expect arguments in Intel format
and return in Intel format (or does callbacks in Intel formats), while
the native ARM code expects subroutines intrerfaces with the ARM format/stsnaard for argument passing, register saving etc. If you invoke
the translated main program, it does all its calls in Intel format and
can then interface with other translated modules that are also Intel
format calling standard.
Lying about things about which you you know nothing.
In article <rpmig4$5qa$3@dont-email.me>,
Alan Baker <notonyourlife@no.no.no.no> wrote:
Lying about things about which you you know nothing.
Why not then answer the questions instead being offended
questions are asked?
| Sysop: | Gate Keeper |
|---|---|
| Location: | Shelby, NC |
| Users: | 790 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 39:36:52 |
| Calls: | 12,115 |
| Calls today: | 5 |
| Files: | 5,294 |
| D/L today: |
72 files (9,959K bytes) |
| Messages: | 564,927 |