• Apple Silicon M1 Chip in MacBook Air Outperforms High-End 16-Inch MacBook Pro and All iOS Devices

    From Jolly Roger@jollyroger@pobox.com to comp.sys.mac.system,comp.sys.mac.hardware.misc,misc.phone.mobile.iphone,comp.mobile.ipad on Thursday, November 12, 2020 17:37:00
    From Newsgroup: comp.sys.mac.system

    Apple's chip design team is *killing* it!i Bravo!

    Apple Silicon M1 Chip in MacBook Air Outperforms High-End 16-Inch
    MacBook Pro and All iOS Devices

    ---

    Apple introduced the first MacBook Air, MacBook Pro, and Mac mini with
    M1 Apple Silicon chips yesterday, and as of today, the first benchmark
    of the new chip appears to be showing up on the Geekbench site.

    <https://jmp.sh/X57oksC>

    The M1 chip, which belongs to a MacBook Air with 8GB RAM, features a single-core score of 1687 and a multi-core score of 7433. According to
    the benchmark, the M1 has a 3.2GHz base frequency.

    When compared to existing devices, the M1 chip in the MacBook Air
    outperforms all iOS devices. For comparison's sake, the iPhone 12 Pro
    earned a single-core score of 1584 and a multi-core score of 3898, while
    the highest ranked iOS device on Geekbench's charts, the A14 iPad Air,
    earned a single-core score of 1585 and a multi-core score of 4647.

    <https://jmp.sh/E0RKkIv>
    Single Core benchmarks

    In comparison to Macs, the single-core performance is better than *any*
    other available Mac, and the multi-core performance beats out all of the
    2019 16-inch MacBook Pro models, including the 10th-generation high-end
    2.4GHz Intel Core i9 model. That high-end 16-inch MacBook Pro earned a single-core score of 1096 and a multi-core score of 6870.

    Though the M1 chip is outperforming the 16-inch MacBook Pro models when
    it comes to raw CPU benchmarks, the 16-inch MacBook Pro likely offers
    better performance in other areas such as the GPU as those models have high-power discrete GPUs.

    <https://jmp.sh/qkyu8hL>
    Multi Core benchmarks

    It's worth noting that there are likely to be some performance
    differences between the MacBook Pro and the MacBook Air even though
    they're using the same M1 chip because the MacBook Air has a fanless
    design and the MacBook Pro has an new Apple-designed cooling system.
    There's also a benchmark for the Mac mini, though, and it has about the
    same scores.

    The Mac mini with M1 chip that was benchmarked earned a single-core
    score of 1682 and a multi-core score of 7067.

    Update: There's also a benchmark for the 13-inch MacBook Pro with M1
    chip and 16GB RAM that has a single-core score of 1714 and a multi-core
    score of 6802. Like the MacBook Air, it has a 3.2GHz base frequency. A
    few other MacBook Air benchmarks have surfaced too with similar scores,
    and the full list is available on Geekbench.

    <https://www.macrumors.com/2020/11/11/m1-macbook-air-first-benchmark/>

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Arlen Holder@arlen_holder@newmachines.com to comp.sys.mac.system,comp.sys.mac.hardware.misc,misc.phone.mobile.iphone,comp.mobile.ipad on Thursday, November 12, 2020 17:54:24
    From Newsgroup: comp.sys.mac.system

    On 12 Nov 2020 17:37:00 GMT, Jolly Roger wrote:
    Apple's chip design team is *killing* it!i Bravo!

    See also the actual _facts_ (not utter bullshit from Apple MARKETING)...

    o The new ARM technology TSMC Silicon powered MacBook Pro maxes out at 16GB of RAM & the M1 supports only 2 USB ports
    <https://groups.google.com/g/comp.sys.mac.system/c/5QbTpwJFT-0>

    o The new TSMC Silicon powered MacBook Pro can't use an eGPU (support for all non-Apple GPUs would be dropped)
    <https://groups.google.com/g/comp.sys.mac.system/c/_jHTerfLHF8>

    o Which Apple CPUs, bootroms, & SEP secure enclave coprocessors do NOT already have well-known unpatchable fatal design flaws?
    <https://groups.google.com/g/misc.phone.mobile.iphone/c/6WKS9KpSyJA/m/ycaYwqSsCQAJ>

    o Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs
    <https://groups.google.com/g/comp.sys.mac.system/c/qgnkyly9Aj4>

    o Did Apple (yet again) fail in chip design (just like they did with modems) this time with graphics chips?
    <https://groups.google.com/g/comp.sys.mac.system/c/Bz7wouZhKcU>

    o Yet another of the never-ending plethora of unpatchable security flaws in Apple's chips widely reported in the news today
    <https://groups.google.com/g/comp.sys.mac.system/c/l9nwDIdIIkU/m/FxNf1USgAwAJ>

    etc.
    --
    Jolly Roger isn't archived in dejagoogle... but he is archived here: <http://comp.sys.mac.system.narkive.com> <http://comp.sys.mac.hardware.misc.narkive.com> <http://misc.phone.mobile.iphone.narkive.com> <http://comp.mobile.ipad.narkive.com>

    From: Jolly Roger <jollyroger@pobox.com>
    Newsgroups:
    comp.sys.mac.system,comp.sys.mac.hardware.misc,misc.phone.mobile.iphone,comp.mobile.ipad
    Subject: Apple Silicon M1 Chip in MacBook Air Outperforms High-End
    16-Inch MacBook Pro and All iOS Devices
    Date: 12 Nov 2020 17:37:00 GMT
    Message-ID: <i15a5sFk7a8U1@mid.individual.net>

    Apple's chip design team is *killing* it!i Bravo!

    Apple Silicon M1 Chip in MacBook Air Outperforms High-End 16-Inch
    MacBook Pro and All iOS Devices

    ---

    Apple introduced the first MacBook Air, MacBook Pro, and Mac mini with
    M1 Apple Silicon chips yesterday, and as of today, the first benchmark
    of the new chip appears to be showing up on the Geekbench site.

    <https://jmp.sh/X57oksC>

    The M1 chip, which belongs to a MacBook Air with 8GB RAM, features a single-core score of 1687 and a multi-core score of 7433. According to
    the benchmark, the M1 has a 3.2GHz base frequency.

    When compared to existing devices, the M1 chip in the MacBook Air
    outperforms all iOS devices. For comparison's sake, the iPhone 12 Pro
    earned a single-core score of 1584 and a multi-core score of 3898, while
    the highest ranked iOS device on Geekbench's charts, the A14 iPad Air,
    earned a single-core score of 1585 and a multi-core score of 4647.

    <https://jmp.sh/E0RKkIv>
    Single Core benchmarks

    In comparison to Macs, the single-core performance is better than *any*
    other available Mac, and the multi-core performance beats out all of the
    2019 16-inch MacBook Pro models, including the 10th-generation high-end 2.4GHz Intel Core i9 model. That high-end 16-inch MacBook Pro earned a single-core score of 1096 and a multi-core score of 6870.

    Though the M1 chip is outperforming the 16-inch MacBook Pro models when
    it comes to raw CPU benchmarks, the 16-inch MacBook Pro likely offers
    better performance in other areas such as the GPU as those models have high-power discrete GPUs.

    <https://jmp.sh/qkyu8hL>
    Multi Core benchmarks

    It's worth noting that there are likely to be some performance
    differences between the MacBook Pro and the MacBook Air even though
    they're using the same M1 chip because the MacBook Air has a fanless
    design and the MacBook Pro has an new Apple-designed cooling system.
    There's also a benchmark for the Mac mini, though, and it has about the
    same scores.

    The Mac mini with M1 chip that was benchmarked earned a single-core
    score of 1682 and a multi-core score of 7067.

    Update: There's also a benchmark for the 13-inch MacBook Pro with M1
    chip and 16GB RAM that has a single-core score of 1714 and a multi-core
    score of 6802. Like the MacBook Air, it has a 3.2GHz base frequency. A
    few other MacBook Air benchmarks have surfaced too with similar scores,
    and the full list is available on Geekbench.

    <https://www.macrumors.com/2020/11/11/m1-macbook-air-first-benchmark/>

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system,comp.sys.mac.hardware.misc,misc.phone.mobile.iphone,comp.mobile.ipad on Thursday, November 12, 2020 10:01:28
    From Newsgroup: comp.sys.mac.system

    On 2020-11-12 9:54 a.m., Arlen Holder wrote:
    On 12 Nov 2020 17:37:00 GMT, Jolly Roger wrote:
    Apple's chip design team is *killing* it!i Bravo!

    See also the actual _facts_ (not utter bullshit from Apple MARKETING)...

    o The new ARM technology TSMC Silicon powered MacBook

    Since that is utter bullshit, why should I bother looking further.

    Apple designs its own chips, Arlen.

    Accept it.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Jolly Roger@jollyroger@pobox.com to comp.sys.mac.system,comp.sys.mac.hardware.misc,misc.phone.mobile.iphone,comp.mobile.ipad on Thursday, November 12, 2020 18:03:37
    From Newsgroup: comp.sys.mac.system

    On 2020-11-12, Alan Baker <notonyourlife@no.no.no.no> wrote:
    On 2020-11-12 9:54 a.m., Arlen Holder wrote:
    On 12 Nov 2020 17:37:00 GMT, Jolly Roger wrote:
    Apple's chip design team is *killing* it!i Bravo!

    See also the actual _facts_ (not utter bullshit from Apple MARKETING)...

    o The new ARM technology TSMC Silicon powered MacBook

    Since that is utter bullshit, why should I bother looking further.

    Apple designs its own chips, Arlen.

    Accept it.

    Poor little butt-hurt Arleen is a pathetic waste of life.

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system,comp.sys.mac.hardware.misc,misc.phone.mobile.iphone,comp.mobile.ipad on Thursday, November 12, 2020 10:13:53
    From Newsgroup: comp.sys.mac.system

    On 2020-11-12 10:03 a.m., Jolly Roger wrote:
    On 2020-11-12, Alan Baker <notonyourlife@no.no.no.no> wrote:
    On 2020-11-12 9:54 a.m., Arlen Holder wrote:
    On 12 Nov 2020 17:37:00 GMT, Jolly Roger wrote:
    Apple's chip design team is *killing* it!i Bravo!

    See also the actual _facts_ (not utter bullshit from Apple MARKETING)... >>>
    o The new ARM technology TSMC Silicon powered MacBook

    Since that is utter bullshit, why should I bother looking further.

    Apple designs its own chips, Arlen.

    Accept it.

    Poor little butt-hurt Arleen is a pathetic waste of life.


    This one is particularly hilarious because he drones on endlessly about
    how he is never factually incorrect.

    :-)
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Friday, November 13, 2020 10:19:50
    From Newsgroup: comp.sys.mac.system

    In message <i15a5sFk7a8U1@mid.individual.net> Jolly Roger <jollyroger@pobox.com> wrote:
    The M1 chip, which belongs to a MacBook Air with 8GB RAM,

    and:

    In comparison to Macs, the single-core performance is better than *any*
    other available Mac, and the multi-core performance beats out all of the
    2019 16-inch MacBook Pro models, including the 10th-generation high-end 2.4GHz Intel Core i9 model. That high-end 16-inch MacBook Pro earned a single-core score of 1096 and a multi-core score of 6870.

    Suck it, JF.

    --
    A marriage is always made up of two people who are prepared to swear
    that only the other one snores.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Friday, November 13, 2020 12:39:59
    From Newsgroup: comp.sys.mac.system

    On 2020-11-13 05:19, Lewis wrote:
    In message <i15a5sFk7a8U1@mid.individual.net> Jolly Roger <jollyroger@pobox.com> wrote:
    The M1 chip, which belongs to a MacBook Air with 8GB RAM,

    and:

    In comparison to Macs, the single-core performance is better than *any*
    other available Mac, and the multi-core performance beats out all of the
    2019 16-inch MacBook Pro models, including the 10th-generation high-end
    2.4GHz Intel Core i9 model. That high-end 16-inch MacBook Pro earned a
    single-core score of 1096 and a multi-core score of 6870.

    Suck it, JF.

    Don't be a child about it. The poor bastard just plunked down hard
    earned cash to upgrade his Mac Pro (which he neither needed nor could
    afford at the time )...

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Friday, November 13, 2020 12:45:36
    From Newsgroup: comp.sys.mac.system

    On 2020-11-12 12:37, Jolly Roger wrote:
    Apple's chip design team is *killing* it!i Bravo!

    Apple Silicon M1 Chip in MacBook Air Outperforms High-End 16-Inch
    MacBook Pro and All iOS Devices...

    This is all making me wonder if I shouldn't wait for the next Mx Mini
    and get one really nice display and a new sidebar display in lieu of a
    new iMac - although I expect that to be a real killer too when it comes out.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Friday, November 13, 2020 20:27:19
    From Newsgroup: comp.sys.mac.system

    In message <PxzrH.448161$I15.90313@fx36.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-13 05:19, Lewis wrote:
    In message <i15a5sFk7a8U1@mid.individual.net> Jolly Roger <jollyroger@pobox.com> wrote:
    The M1 chip, which belongs to a MacBook Air with 8GB RAM,

    and:

    In comparison to Macs, the single-core performance is better than *any*
    other available Mac, and the multi-core performance beats out all of the >>> 2019 16-inch MacBook Pro models, including the 10th-generation high-end
    2.4GHz Intel Core i9 model. That high-end 16-inch MacBook Pro earned a
    single-core score of 1096 and a multi-core score of 6870.

    Suck it, JF.

    Don't be a child about it. The poor bastard just plunked down hard
    earned cash to upgrade his Mac Pro (which he neither needed nor could
    afford at the time )...

    that doesn't excuse his constant stream of pig-ignorance and bullshit
    and constant harping about how things worked on the VAX 30 years ago.

    --
    ARE YOU FAMILIAR WITH THE WORDS 'DEATH WAS HIS CONSTANT COMPANION'?
    'But I don't usually see you!'
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Friday, November 13, 2020 20:32:33
    From Newsgroup: comp.sys.mac.system

    In message <4DzrH.138070$nI.135911@fx21.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-12 12:37, Jolly Roger wrote:
    Apple's chip design team is *killing* it!i Bravo!

    Apple Silicon M1 Chip in MacBook Air Outperforms High-End 16-Inch
    MacBook Pro and All iOS Devices...

    This is all making me wonder if I shouldn't wait for the next Mx Mini
    and get one really nice display and a new sidebar display in lieu of a
    new iMac - although I expect that to be a real killer too when it comes out.

    I suspect that the next machines to be released will be the 14" MBP
    (repalcing the current 13" 4 TB3 port MBP), the 16" MBP, and the iMac.
    They will all sport, essentially, two M1 chips, and support for much
    more RAM and at least four USB-4 ports.

    I suspect the new large iMac, if not both, will take its cues from the
    iMac Pro, which will vanish.

    Somewhere I there will be a secon Mac mini Pro, also supporting 4 ports
    and more RAM to replace the current Intel mini wtih 4xTB3 ports.

    No evidence, just a guess.

    I need to send out an invoice to cover my upcoming purchase of a new
    mini. :)

    --
    Real magic is the hand around the bandsaw, the thrown spark in the
    powder keg, the dimension-warp linking you straight into the
    heart of a star, the flaming sword that burns all the way to the
    pommel. --Moving Pictures
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 13, 2020 17:15:17
    From Newsgroup: comp.sys.mac.system

    On 2020-11-13 15:27, Lewis wrote:

    that doesn't excuse his constant stream of pig-ignorance and bullshit
    and constant harping about how things worked on the VAX 30 years ago.


    Constant? Really? you can't find a better insult?


    The VAX examnple is relevat because VMS made the memory differences
    quite visible to the system manager because different areas of the OS
    were set as parameters in SYSGEN. On the OS-X, because the memory
    management is totally opaque to the user, you don't really see the
    difference. But the difference happens.

    Because for OS_X, the move was gradual, (first introduction of 64 bit on
    8086, and now move to ARM), this move will be far less visible and small
    impact that if the move had been from 32 bit 8086 to 64 bt ARM.

    But just because the impact of this move is less doesn't mean that there
    isn't an impact, and it certainly does not mean you can halve the memory
    of your machines and expect same performance.

    Lets see how the Cinema 4D performance tests do. These tests require
    lots of RAM, and spin the cores at max for a long enough tome to cause
    them to heat up and throttle down if inadequately cooled.

    A geekbench test that does not require much memory won't see a
    difference bexause the latop only has half the memory. But a real app
    that does video rendering will



    Agian, this is in response from you or some of your evil twins that
    going from Intel to ARM reduces memory needs, hence the M1 having 8 to
    15 vs 16 or 32 on Intel.

    Going from CISC to RISC does NOT reduce memory footprint of binaries.
    The difference berwene VAX and ALPHA was huge because VAX has a very uppsercase/biold/underline first C in CISC. The 8086 is far less
    complex so the difference with ARM is not as striking.

    However, just because memory footprint woN't increase as much does not
    mean you can argue it now runs with half the memory. Memory footprint
    still increases with RISC vs CISC.


    This is especially true when you consider that initially, many apps will
    be translated from Intel and more bloated than if compile and optimised
    for ARM.


    So I maintain my argument that reducing memory by half on its laptops is
    not going to be good.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Friday, November 13, 2020 17:20:47
    From Newsgroup: comp.sys.mac.system

    In article <VzDrH.541236$HY4.328729@fx37.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    The VAX examnple is relevat

    no it isn't, nor has it been for 30-40 years.




    So I maintain my argument that reducing memory by half on its laptops is
    not going to be good.

    be prepared to lose.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 14, 2020 00:48:43
    From Newsgroup: comp.sys.mac.system

    In message <VzDrH.541236$HY4.328729@fx37.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-13 15:27, Lewis wrote:

    that doesn't excuse his constant stream of pig-ignorance and bullshit
    and constant harping about how things worked on the VAX 30 years ago.

    Constant? Really? you can't find a better insult?

    Stating facts is not an insult.

    The VAX examnple is relevat

    Nope.

    Hint: as soon as you string the letters V A and X together, no one
    reads any further.


    --
    Matters in hand. He'd put matters in hand all right. If he closed his
    eyes he could see the body tumbling down the steps. Had there
    been a hiss of shocked breath, down in the darkness of the hall?
    He'd been certain they were alone. Matters in hand! He'd tried to
    wash the blood off his hands. If he could wash the blood off, he
    told himself, it wouldn't have happened. He'd scrubbed and
    scrubbed. Scrubbed till he screamed. --Wyrd Sisters
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Friday, November 13, 2020 20:06:30
    From Newsgroup: comp.sys.mac.system

    In article <slrnrquabb.1fdt.g.kreme@ProMini.lan>, Lewis <g.kreme@kreme.dont-email.me> wrote:

    In message <VzDrH.541236$HY4.328729@fx37.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    The VAX examnple is relevat

    Nope.

    Hint: as soon as you string the letters V A and X together, no one
    reads any further.

    you're missing out on additional laughs.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Saturday, November 14, 2020 04:25:33
    From Newsgroup: comp.sys.mac.system

    On 2020-11-13 19:48, Lewis wrote:

    Hint: as soon as you string the letters V A and X together, no one
    reads any further.

    Since you don't actually read my posts and just find any spot where you
    can start insulting me, it doesn't matter. But admitting you don't read
    the post should send a message that your insults are not based on facts,
    just just automatically insult withourt reading, and whenever
    challenged to provide actual facts to show I was wrong, you refuse.

    I have experience going from one platform to another where memory
    requireements differences were very visible to the system manager. Yet,
    you instead choose to discredit and insult me.

    When the 8086 went from 32 to 64 bits, the transition was basically
    invisible because neither Windows nor OS-X exposes one to the intricate
    memory management now done by the OS automatically. And more
    importantly, compatibility means that existing 32bit binaries ran
    unchanged using 32 bit addresses and opcodes. The change was gradual as
    more and more applicatiosn were compiled in 64 bit mode.

    In the acse of Apple, the progressive move to 64 biuts was compensated
    by progressive removal of 32 bit frameworks and eventually removal of
    all 32 bit frameworks which meant only one copy loaded onto memory.

    But with this all done before move to ARM, the move to ARM does expose
    the binary size to how many ARM opcodes are necessary to replace 8086
    ones.

    Againa, you or your ilk claimed that binaries would be smaller to
    explain why the Laptop only has 8GB or 16GB.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 14, 2020 09:41:15
    From Newsgroup: comp.sys.mac.system

    In message <131120202006308802%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
    In article <slrnrquabb.1fdt.g.kreme@ProMini.lan>, Lewis <g.kreme@kreme.dont-email.me> wrote:

    In message <VzDrH.541236$HY4.328729@fx37.iad> JF Mezei
    <jfmezei.spamnot@vaxination.ca> wrote:
    The VAX examnple is relevat

    Nope.

    Hint: as soon as you string the letters V A and X together, no one
    reads any further.

    you're missing out on additional laughs.

    Seen the same drivel so many times it's no longer funny.

    --
    In other news, Gandalf died. -- Secret Diary of Boromir
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Leo@leoblaisdell@sbcglobal.net to comp.sys.mac.system on Sunday, November 15, 2020 17:00:04
    From Newsgroup: comp.sys.mac.system

    On 2020 Nov 13, , JF Mezei wrote
    (in article <VzDrH.541236$HY4.328729@fx37.iad>):

    The VAX examnple is relevat because VMS made the memory differences
    quite visible to the system manager because different areas of the OS
    were set as parameters in SYSGEN. On the OS-X, because the memory
    management is totally opaque to the user, you don't really see the difference. But the difference happens.

    <snip>

    So I maintain my argument that reducing memory by half on its laptops is
    not going to be good.

    Ya know JF, alt.folklore.computers is coming back to life. That´s in case you´re not already there under another name. Just saying. There is lots of
    VAX knowledge and discussion. They are pretty quiet regarding Macs.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Stephen Hoffman@seaohveh@hoffmanlabs.invalid to comp.sys.mac.system on Tuesday, November 17, 2020 17:18:37
    From Newsgroup: comp.sys.mac.system

    On 2020-11-14 09:25:33 +0000, JF Mezei said:

    On 2020-11-13 19:48, Lewis wrote:

    Hint: as soon as you string the letters V A and X together, no one
    reads any further.

    Since you don't actually read my posts and just find any spot where you
    can start insulting me, it doesn't matter. But admitting you don't read
    the post should send a message that your insults are not based on
    facts, just just automatically insult withourt reading, and whenever challenged to provide actual facts to show I was wrong, you refuse.

    There's also the discussion of whether investing the time and effort
    involved in reading and responding is viewed as worthwhile—of the many
    folks effectively using Brandolini's Law as an attack, too.

    I have experience going from one platform to another where memory requireements differences were very visible to the system manager. Yet,
    you instead choose to discredit and insult me.

    Main memory is not something that Apple even particularly discusses
    with iPad and iPhone devices.

    As for your comparisons, I'm somewhat familiar with the OpenVMS ports
    from VAX to Alpha, and from Alpha to Itanium. And from PDP-11 / RSX-11M
    to then-VAX/VMS, for that matter.

    (There's also an OpenVMS port underway to x86-64. Yes, any Apple M1 Arm discussions aside, a few folks have humorously posited that OpenVMS
    port as a harbinger of doom for x86.)

    Architectural transitions with any associated storage requirements
    changes can be a murky comparison within the same operating system, and
    can be specious across disparate operating systems.

    When the 8086 went from 32 to 64 bits, the transition was basically invisible because neither Windows nor OS-X exposes one to the intricate memory management now done by the OS automatically.

    If by "basically invisible" you mean "a whole lot of work, and very
    much a substantial effort for many developers", sure. From the
    Microsoft PDC in Denver some twenty years ago, where Microsoft was
    announcing their 64-bit transition (which eventually included XP 64-bit Edition for Itanium, etc), the Microsoft speakers were telling an
    interesting tale about recompile-and-go at that PDC, but in retrospect
    that transition involved a whole lot more work from them and for
    third-party providers, and a whole lot of time and effort to get from
    32-bit OS and apps to 64-bit. This having completed the transition from
    32-bit OpenVMS VAX to 64-bit OpenVMS Alpha port a few years prior to
    that PDC. It's taken macOS over a decade to transition to 64-bit, and
    all the old apps got rebuilt, and many—not the least of which were
    Microsoft Office, per Microsoft reps—required substantial effort. Or
    the apps failed at Catalina. Sure, apps using OO frameworks have been
    largely protected from a whole lot of the pointer "fun", but that's far
    from all apps.

    And more importantly, compatibility means that existing 32bit binaries
    ran unchanged using 32 bit addresses and opcodes. The change was
    gradual as more and more applicatiosn were compiled in 64 bit mode.

    If by "gradual" you mean that older and newer APIs had coexisted for a
    while, um, sure. macOS did that fairly well. Windows had 32- and 64-bit editions, too. OpenVMS tried mostly-having-it-all with a hybrid
    preserving both 32- and 64-bit APIs, and ended up with one of the more
    complex implementations. It's now ~possible to write fully 64-bit
    OpenVMS apps with code in P2 space now, if you're on Itanium and happen
    to know a few cryptic build commands. A gradual transition from old to
    new APIs is the only way you can transition without clobbering your
    installed base, if the deprecation and removal of the older and 32-bit
    APIs is necessary.

    In the acse of Apple, the progressive move to 64 biuts was compensated
    by progressive removal of 32 bit frameworks and eventually removal of
    all 32 bit frameworks which meant only one copy loaded onto memory.

    If by "progressive removal" you mean "32-bit support ended at macOS
    Catalina", sure.

    Apple has had a long history of replacing problematic frameworks, and
    it wouldn't usually make sense to replace a 32-bit framework with
    another 32-bit framework, discussions of OpenVMS API compatibility
    aside, during a longer-term transition to 64-bit.

    But with this all done before move to ARM, the move to ARM does expose
    the binary size to how many ARM opcodes are necessary to replace 8086
    ones.

    I fail to see the connection from your earlier statements within this
    posting to your discussion of differing instruction sets and
    instruction densities.

    There's also the complicating factor of the Universal and more recently
    now Universal 2 multi-architecture binaries, and of ignoring and/or of removing executable code for architectures other than that of the
    current platform.

    Multi-architecture binaries being a detail which does not exist on OpenVMS.

    Againa, you or your ilk claimed that binaries would be smaller to
    explain why the Laptop only has 8GB or 16GB.

    I expect the main memory capacities were chosen due to the differences
    in paging I/O speeds, due to intentionally constraining initial product
    design and support and testing, and with the expectation that numbers
    of I/O connections and such factors will be part of the eventual
    product differentiation.

    Upcoming Macs will undoubtedly feature more and faster I/O connections
    and more memory and more storage too, as well as faster Arm processors.

    Strictly for app performance, larger main memory masks slower
    persistent storage performance; caching main storage data and code in
    main memory. Faster persistent storage can mask smaller main memory.
    Less caching is necessary, and paging is faster.

    Similar performance trade-offs arise with processor caches and main
    memory designs. The Alpha EV7 processor had smaller caches than had the earlier EV6 processor design, but EV7 was faster in aggregate due to
    the faster EV7 processor I/O speeds. Trade-offs are inherent.

    These trade-offs vary due to the technologies available. The advent of hypothetical fast byte-addressable persistent storage with speeds
    approaching that of volatile main memory conceivably allows the
    read-only portion of apps to be accessed and executed directly from
    storage, with only the read-write data loaded into and stored in
    volatile main memory, for instance.

    Related reading on some details and the evolving trade-offs of code
    density and processor design: http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf



    --
    Pure Personal Opinion | HoffmanLabs LLC

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Wednesday, November 18, 2020 02:09:13
    From Newsgroup: comp.sys.mac.system

    On 2020-11-17 17:18, Stephen Hoffman wrote:

    If by "basically invisible" you mean "a whole lot of work, and very
    much a substantial effort for many developers", sure.

    From the user point of view, the Mac transitions did not expose the user
    to system memoriry management changes.


    This is in the context of the RAM limitations of the new Macs. Someone
    argues that moving from x86 to ARM would require less memory, a premise
    I disagree with. (they said an 8GB M1 Mac would be just as capable as a
    16GB Intel one).

    I tried to explain than going 64 bits and going RISC end up with larger binaries and provided the exmaple of VMS where were were exposed in
    SYSGEN to those changes, needing far greater allocation of space for
    shareable images, larger working sets etc.

    This is all opaque to Mac users, but it doesn't mean that moving from
    X86 to ARM will end up requiring less RAM.

    The transition to 64 but on x86 was more gradual and as each 32 but
    framework was widthdrawn over the years, in increased size of new 64 but
    apps was comendated by reduced footprint with elimination of 32 bit APIs.

    But with the move to ARM, Apple has already copmpleted the pruning of 32
    bit APIs so there is no saving in RAM from removing old APIs, so it is
    just a matter of whether the ARM binary is larger than the x86 binary fo
    same app (needing more memory to load). The data alloactions would be
    the same.

    (with regards to the Universal, the file containing the binary may be
    larger, but one assumes that the image loader only loads the appropriate portion of the universal into memory).



    I fail to see the connection from your earlier statements within this posting to your discussion of differing instruction sets and
    instruction densities.

    This was in relation to someone arguing the binaries for an ARM platform
    would e smaller than those for X86, thus iot was OK for the new laptops
    to have less RAM in them.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Krzysztof Mitko@invalid@kmitko.at.list.dot.pl to comp.sys.mac.system on Wednesday, November 18, 2020 08:51:43
    From Newsgroup: comp.sys.mac.system

    JF Mezei wrote:

    On 2020-11-17 17:18, Stephen Hoffman wrote:

    If by "basically invisible" you mean "a whole lot of work, and very
    much a substantial effort for many developers", sure.

    From the user point of view, the Mac transitions did not expose the user
    to system memoriry management changes.


    This is in the context of the RAM limitations of the new Macs. Someone
    argues that moving from x86 to ARM would require less memory, a premise
    I disagree with. (they said an 8GB M1 Mac would be just as capable as a
    16GB Intel one).

    I tried to explain than going 64 bits and going RISC end up with larger binaries and provided the exmaple of VMS where were were exposed in
    SYSGEN to those changes, needing far greater allocation of space for shareable images, larger working sets etc.

    You know that instead of drawing analogies you can actually measure it,
    right?

    Open a project in XCode 12.2, go to Build settings -> Architectures, set the architecture you need (x86_64 for Intel, arm64 for M1), archive, check size. I tested two random small Cocoa apps I written in ObjC and sometimes the ARM binary is bigger…

    file VC840*
    VC840-ARM: Mach-O 64-bit executable arm64
    VC840-Intel: Mach-O 64-bit executable x86_64
    ls -l VC840*
    -rwxr-xr-x 1 kmitko staff 90384 Nov 18 09:31 VC840-ARM
    -rwxr-xr-x 1 kmitko staff 74032 Nov 18 09:28 VC840-Intel

    …and other times is not (same codebase and no optimization, mind you).

    file Data*
    Data Thief-ARM: Mach-O 64-bit executable arm64
    Data Thief-Intel: Mach-O 64-bit executable x86_64
    ls -l Data*
    -rwxr-xr-x 1 kmitko staff 125568 Nov 18 09:35 Data Thief-ARM
    -rwxr-xr-x 1 kmitko staff 125712 Nov 18 09:36 Data Thief-Intel

    Grab some big open source project and try for yourself and you'll have better proof than theories about VAX.


    This is all opaque to Mac users, but it doesn't mean that moving from
    X86 to ARM will end up requiring less RAM.

    The transition to 64 but on x86 was more gradual and as each 32 but
    framework was widthdrawn over the years, in increased size of new 64 but
    apps was comendated by reduced footprint with elimination of 32 bit APIs.

    But with the move to ARM, Apple has already copmpleted the pruning of 32
    bit APIs so there is no saving in RAM from removing old APIs, so it is
    just a matter of whether the ARM binary is larger than the x86 binary fo
    same app (needing more memory to load). The data alloactions would be
    the same.

    (with regards to the Universal, the file containing the binary may be
    larger, but one assumes that the image loader only loads the appropriate portion of the universal into memory).



    I fail to see the connection from your earlier statements within this
    posting to your discussion of differing instruction sets and
    instruction densities.

    This was in relation to someone arguing the binaries for an ARM platform would e smaller than those for X86, thus iot was OK for the new laptops
    to have less RAM in them.


    --
    The generation of random numbers is too important to be left to chance.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Wednesday, November 18, 2020 15:09:23
    From Newsgroup: comp.sys.mac.system

    In message <tM3tH.2635$gR8.2277@fx45.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-17 17:18, Stephen Hoffman wrote:

    If by "basically invisible" you mean "a whole lot of work, and very
    much a substantial effort for many developers", sure.

    From the user point of view, the Mac transitions did not expose the user
    to system memoriry management changes.


    This is in the context of the RAM limitations of the new Macs. Someone
    argues that moving from x86 to ARM would require less memory, a premise
    I disagree with. (they said an 8GB M1 Mac would be just as capable as a
    16GB Intel one).

    They were, as it turns out, wrong. The 8GB M1 is MORE capable than the
    16GB Intel. No one predicted that.


    --
    You can find any pattern you want to any level of precision you want
    If you ignore enough data.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Stephen Hoffman@seaohveh@hoffmanlabs.invalid to comp.sys.mac.system on Wednesday, November 18, 2020 12:54:08
    From Newsgroup: comp.sys.mac.system

    On 2020-11-18 07:09:13 +0000, JF Mezei said:

    On 2020-11-17 17:18, Stephen Hoffman wrote:

    If by "basically invisible" you mean "a whole lot of work, and very
    much a substantial effort for many developers", sure.

    From the user point of view, the Mac transitions did not expose the
    user to system memoriry management changes.

    The developers were certainly exposed. I had C code that needed
    changes, both due to framework deprecations and due to pointer changes.
    Apps using entirely OO had rather less work required, outside of
    frameworks deprecations.

    This is in the context of the RAM limitations of the new Macs. Someone argues that moving from x86 to ARM would require less memory, a premise
    I disagree with. (they said an 8GB M1 Mac would be just as capable as
    a 16GB Intel one).

    I don't know what the ratio would be, pending tests. Whether less
    memory or more memory is necessary. Again, computers are systems, and different designs have different trade-offs. Having fast main storage
    can make less main memory feasible.

    I tried to explain than going 64 bits and going RISC end up with larger binaries and provided the exmaple of VMS where were were exposed in
    SYSGEN to those changes, needing far greater allocation of space for shareable images, larger working sets etc.

    Being somewhat familiar with what you were using as an example, I was confused. I'm still confused.

    This is all opaque to Mac users, but it doesn't mean that moving from
    X86 to ARM will end up requiring less RAM.

    When main storage I/O access is fast, and when an instruction set is
    dense, small main memory is entirely workable.

    Related: https://daringfireball.net/2020/11/the_m1_macs

    The transition to 64 but on x86 was more gradual and as each 32 but framework was widthdrawn over the years, in increased size of new 64
    but apps was comendated by reduced footprint with elimination of 32 bit APIs.

    A particular app tends to be larger going from 32-bit to 64-bit, but by
    how much varies by app. macOS processes are (were) either 32-bit or
    64-bit, not both. Eliminating the older APIs was a more general
    reduction in APIs and storage.

    But with the move to ARM, Apple has already copmpleted the pruning of
    32 bit APIs so there is no saving in RAM from removing old APIs, so it
    is just a matter of whether the ARM binary is larger than the x86
    binary fo same app (needing more memory to load). The data alloactions would be the same.

    Architectural integer size is one factor in selecting the memory sizing
    when designing and when configuring a system, but not the only one.

    I fail to see the connection from your earlier statements within this
    posting to your discussion of differing instruction sets and
    instruction densities.

    This was in relation to someone arguing the binaries for an ARM
    platform would e smaller than those for X86, thus iot was OK for the
    new laptops to have less RAM in them.

    I'd expect a substantial effect from faster I/O buses and faster main
    storage than from architectural integer sizes—you're seemingly assuming
    old paging performance characteristics within your memory sizing
    calculations here, and you'll want to verify those assumptions still
    hold. If I can page faster, I don't need as much memory for the app
    executable code and data, or for the main storage caches that can mask
    slower main storage. This trade-off ties back to Alpha EV7 having
    smaller processor caches than Alpha EV6, but being faster overall, and
    that was due to the faster buses in EV7 over those of EV6. This also
    ties back to (currently somewhere between hypothetical and very
    expensive) fast byte-addressable main storage, the advent of which
    would undoubtedly substantially alter system design assumptions.



    --
    Pure Personal Opinion | HoffmanLabs LLC

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Thursday, November 19, 2020 11:08:20
    From Newsgroup: comp.sys.mac.system

    On 2020-11-18 03:51, Krzysztof Mitko wrote:

    You know that instead of drawing analogies you can actually measure it, right?

    Have you seen cases where the ARM binary is half the size of the Intel
    one which would make an 8 GB M1 Mac function with same amount of
    page/swap files as a 16GB Intel?

    This disccusion is happening because of of the nospam/lewis/whatever
    argued the M1 chip didn't need as much memory to function as the Intel
    and that the 8GM Mac in 2020 was perfectly suitable.



    …and other times is not (same codebase and no optimization, mind you)


    Optimizations happen in the compiler and then by the LLVM layer.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Thursday, November 19, 2020 11:43:15
    From Newsgroup: comp.sys.mac.system

    In article <ULwtH.6996$J92.3733@fx48.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    Have you seen cases where the ARM binary is half the size of the Intel
    one which would make an 8 GB M1 Mac function with same amount of
    page/swap files as a 16GB Intel?

    utterly bogus assumption.

    This disccusion is happening because of of the nospam/lewis/whatever
    argued the M1 chip didn't need as much memory to function as the Intel

    it doesn't

    and that the 8GM Mac in 2020 was perfectly suitable.

    it is.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Friday, November 20, 2020 13:00:58
    From Newsgroup: comp.sys.mac.system

    In message <ULwtH.6996$J92.3733@fx48.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-18 03:51, Krzysztof Mitko wrote:

    You know that instead of drawing analogies you can actually measure it,
    right?

    Have you seen cases where the ARM binary is half the size of the Intel
    one which would make an 8 GB M1 Mac function with same amount of
    page/swap files as a 16GB Intel?

    You keep repeating the same dumbass mistakes.

    This disccusion is happening because of of the nospam/lewis/whatever
    argued the M1 chip didn't need as much memory to function as the Intel
    and that the 8GM Mac in 2020 was perfectly suitable.

    That is what technical people WITH THE MACHINES are saying, dumbass. Go
    read Anandtech. Stop assuming that you are right and everyone else is
    wrong about something you have never seen or used and THEY HAVE.

    <https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested/2>
    "In this first-time view of the popular Cinema4D based benchmark, we see
    the Apple M1 toe-to-toe with the best-performing x86 CPUs on the
    market,"

    You fucking idiot child. You don't know what the fuck you are talking
    about,

    Optimizations happen in the compiler and then by the LLVM layer.

    You haven't a clue.

    --
    "Are you pondering what I'm pondering?"
    "I think so, Brain, but if we give peas a chance, won't the lima
    beans feel left out?"
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 20, 2020 12:31:01
    From Newsgroup: comp.sys.mac.system

    On 2020-11-18 12:54, Stephen Hoffman wrote:

    The developers were certainly exposed. I had C code that needed
    changes, both due to framework deprecations and due to pointer changes.
    Apps using entirely OO had rather less work required, outside of
    frameworks deprecations.

    What I rememher is that moving from 32 to 64 (VAX to Alpha) requires a
    lot of changes. Migrating the UAF didn't work because WSLIMIT and
    related paramenters were grossly insufficient because processes now
    needed a lot more memory. (and same with corresponding SYSGEN parameters)

    The curret migration is from 64 bits OS-X on Intel 8086 to 64 bits OS0X
    on ARM. So the big change is not on pointer size, but rather on how
    many instructions are needed to perform the same task (and size of instructions).

    I don't know what the ratio would be, pending tests.


    Would you agree that someone claiming the migration from 64 bits OS-X on
    x86 to 64 bits OS-X on ARM would NOT result in half of RAM requirement
    as some here have argued?

    Having fast main storage
    can make less main memory feasible.


    Is there data that shows that an SSD can be as fast as DDR4 memory, when
    you consider that all accesses go through the Secure Enclave which encrypts/decrypts data?



    Being somewhat familiar with what you were using as an example, I was confused. I'm still confused.

    I is simple. Someone stated that reducing base model from 16 to 8GB was
    nornal because M1 chip required much less memory than a x86 running the
    same OS that has already been pruned of 32bit legacy APIs (so truly
    comparing apples to apples)pardon the pun).

    I was trying to argue that if anything, memory footp]rint of gong from
    CISC to RISC inxreases RAM requirement.


    I'd expect a substantial effect from faster I/O buses and faster main storage than from architectural integer sizes—you're seemingly assuming old paging performance characteristics within your memory sizing calculations here,

    Are you saying that increased reliance on paging to disk is compensated
    by having faster disk and faster IO ?

    With that logic, wouldn't it be fair to state that having more RAM would icrease performance even further because it would be faster than paging
    to disk?


    Running the Adobe suite to do videos, I recently uipgraded from 24 to 64
    GB, 4 to 10 cores. And I am finding it already insufficient RAM. So I am
    quite susprised Apple finds 8GB sufficient to do any video work.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Friday, November 20, 2020 13:35:49
    From Newsgroup: comp.sys.mac.system

    On 2020-11-18 12:54, Stephen Hoffman wrote:


    Being somewhat familiar with what you were using as an example, I was confused. I'm still confused.

    Don't worry. It's not you.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Friday, November 20, 2020 13:39:29
    From Newsgroup: comp.sys.mac.system

    On 2020-11-20 12:31, JF Mezei wrote:

    What I rememher is that moving from 32 to 64 (VAX to Alpha) requires a
    lot of changes.


    The issue here is going from 64bit to... 64 bit.

    From a machine with 16 general purpose registers to one with 29
    (available to apps).

    On an architecture, that by design, brings the system memory closer to
    the major high speed I/O 'devices'.

    Your VAX examples are less than meaningless.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Friday, November 20, 2020 13:45:07
    From Newsgroup: comp.sys.mac.system

    On 2020-11-19 11:08, JF Mezei wrote:
    On 2020-11-18 03:51, Krzysztof Mitko wrote:

    You know that instead of drawing analogies you can actually measure it,
    right?

    Have you seen cases where the ARM binary is half the size of the Intel
    one which would make an 8 GB M1 Mac function with same amount of
    page/swap files as a 16GB Intel?

    Nobody said that. Your "confusion" is that a universal binary is twice
    the size as an individual binary.

    But the OS only loads the binary appropriate to the running CPU. The
    rest is left behind. (Indeed it would be possible to install, from a universal binary installer, only that part of the binary needed
    according to the host CPU).

    Your other confusion is that the integrated devices (graphics, I/O)
    share the main memory. And while that is so, it is no different than
    the lower spec'd Macs that share memory with intel based graphics.

    Adding on other devices (USB 3 / Thunderbolt, etc) uses relatively
    little of this memory.

    Most importantly, with this shared memory comes huge gains in speed.

    But, go on with your fantasy point of view which is not held up by
    anything in the real world. And please do not mention VAX again.


    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 20, 2020 19:22:02
    From Newsgroup: comp.sys.mac.system

    On 2020-11-20 13:45, Alan Browne wrote:

    Nobody said that. Your "confusion" is that a universal binary is twice
    the size as an individual binary.

    I never said that. The image activator will only load the relevant
    binary from disk, so the fact that the .App directory structiure has a
    file containing an intel binary next to the one containing the ARM
    binary is irrelevant to RAM requirements since it won't be loaded ever.



    Your other confusion is that the integrated devices (graphics, I/O)
    share the main memory. And while that is so, it is no different than
    the lower spec'd Macs that share memory with intel based graphics.

    Intel Laptops come wth 16GB of RAM. Apple halved the default to 8GB for
    these laptops with both having the GPU share RAM with CPU.

    Adding on other devices (USB 3 / Thunderbolt, etc) uses relatively
    little of this memory.

    I broiught that up in the contect is upcoming chips, whether Apple will increase the IO subsystem and how. This is not memory related.

    Most importantly, with this shared memory comes huge gains in speed.

    This is Apple marketing. An application sends code to the external GPU
    once, and the GPU then uses its own memory controller accessing its own
    memory to do all its computations independantly.

    In the shared memory model, the GPU and CPU compete for access to memory
    since they use the same memory controller accessing the same memory, and
    this has the issues of memory allocation (hence the need for a
    hyopervisor I suspect).

    PCI Express 4 is very very fast. So the difference in performnce is not garanteed.

    Now, if you are viewing a movie where you are constantly transfering new
    frames and using the GPU to dis0lay instead of to compute, then the
    shared memory is good. But for such a task, the PCI Express 4 is more
    than enough anyways.


    anything in the real world. And please do not mention VAX again.

    VAX.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 21, 2020 00:51:24
    From Newsgroup: comp.sys.mac.system

    In message <K4ZtH.6931$gR8.3675@fx45.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    Intel Laptops come wth 16GB of RAM. Apple halved the default to 8GB for these laptops with both having the GPU share RAM with CPU.

    And you ignore the many reports from many sources that say the small RAM footprint is not noticeable at all. That encoding a 80GB 5K video on a
    MacBook Air with 8GB works just fine with no apparent memory issue. That
    when someone opens 500+ tabs on Chrome the system is still responsive
    and fast even though Chrome has completely shit itself.

    Most importantly, with this shared memory comes huge gains in speed.

    This is Apple marketing.

    No, you are wrong and there is tons of evidence proving you are wrong.

    VAX.

    Ignorant Asshole says Vax?


    --
    Hell is real, and it smells like Axe body spray.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 20, 2020 20:03:50
    From Newsgroup: comp.sys.mac.system

    On 2020-11-20 19:51, Lewis wrote:

    Most importantly, with this shared memory comes huge gains in speed.

    This is Apple marketing.

    No, you are wrong and there is tons of evidence proving you are wrong.



    So based on your logic, the Intel GPUs in the Intel Laptop chips should
    have outperformed the fancy external GPUs years ago because of shared
    memory. Yet, when Apple unleashed its $60,000 Cheese Grater Mac Pro, it
    used external GPUs, not the internal Intel ones.

    Where you are purposefully keeping you head in the sand are the
    scalability issues. The integrated GPU with shared memory ahs worked in laptops (and for M1 laptops , outperforming by far similar Intel
    laptops that also hsrae memory).

    However, as you scale up, you find compuyers all have external GPUs
    because they want more hosrsepower and when you grow GPU horsepower, you
    grow demand on memory access and this starts to conflict with CPU
    accessing memory while CPU is chugging along.

    So again, how Apple deals with its architecture to scale it remains to
    be seen. I am sure they have plans and prototypes inhouse. But we
    haven't seen how they plan to scale this to iMacs and Mac pro.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 21, 2020 03:26:45
    From Newsgroup: comp.sys.mac.system

    In message <WHZtH.1332$QL5.932@fx22.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-20 19:51, Lewis wrote:

    Most importantly, with this shared memory comes huge gains in speed.

    This is Apple marketing.

    No, you are wrong and there is tons of evidence proving you are wrong.

    So based on your logic, the Intel GPUs in the Intel Laptop chips should
    have outperformed the fancy external GPUs years ago because of shared
    memory. Yet, when Apple unleashed its $60,000 Cheese Grater Mac Pro, it
    used external GPUs, not the internal Intel ones.

    No, according to the MANY people who have the machines and are using
    them. You know, people who actually have a fucking clue what they are
    talking about instead of you who is making shit up based on zero
    knowledge.

    --
    Marriages made in heaven are not exported.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Savageduck@savageduck1@{REMOVESPAM}me.com to comp.sys.mac.system on Friday, November 20, 2020 20:22:34
    From Newsgroup: comp.sys.mac.system

    On Nov 20, 2020, Alan Browne wrote
    (in article <90UtH.1025$jL.287@fx13.iad>):

    On 2020-11-18 12:54, Stephen Hoffman wrote:

    Being somewhat familiar with what you were using as an example, I was confused. I'm still confused.

    Don't worry. It's not you.

    “Anyone who isn’t confused really doesn’t understand the situation†- Edward R. Murrow

    --
    Regards,
    Savageduck

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 21, 2020 11:05:04
    From Newsgroup: comp.sys.mac.system

    On 2020-11-20 19:22, JF Mezei wrote:
    On 2020-11-20 13:45, Alan Browne wrote:

    Nobody said that. Your "confusion" is that a universal binary is twice
    the size as an individual binary.

    I never said that. The image activator will only load the relevant
    binary from disk, so the fact that the .App directory structiure has a
    file containing an intel binary next to the one containing the ARM
    binary is irrelevant to RAM requirements since it won't be loaded ever.



    Your other confusion is that the integrated devices (graphics, I/O)
    share the main memory. And while that is so, it is no different than
    the lower spec'd Macs that share memory with intel based graphics.

    Intel Laptops come wth 16GB of RAM. Apple halved the default to 8GB for

    Google: "intel laptop 4GB" and plenty pop up. likewise 8 GB.

    The low end intel ones have shared memory with graphics and IIRC AMD
    have a similar scheme in some CPU's.

    Your balloon just popped. (Again!).

    these laptops with both having the GPU share RAM with CPU.

    Most MBA's and minis, recently, had 4 GB as the starting point and for
    most users of a MBA or Mac Mini that is ample - even with shared graphic memory. (Office apps, e-mail, browsing, etc.). Upping it to 16 GB
    would make it a "starter" work horse with higher end CPU's.

    My Mac Mini at work is "only" 8 GB and I do all of the above plus a
    Fusion VM of Win 10 and all works fine - and it's an i3. Not a heavy
    lifter by any stretch - but fine for administration of a small business
    (and I likely do much more than most). It's far better than the MBA it replaced, to be sure (and it too, 8 GB, did fine).

    My SO's MBA is 4 GB. Doing just fine for her needs 5 - 6 years later.


    Adding on other devices (USB 3 / Thunderbolt, etc) uses relatively
    little of this memory.

    I broiught that up in the contect is upcoming chips, whether Apple will increase the IO subsystem and how. This is not memory related.

    It's most definitely memory related - the unified memory is all about
    speed through proximity and tight integration.

    Most importantly, with this shared memory comes huge gains in speed.

    This is Apple marketing. An application sends code to the external GPU
    once, and the GPU then uses its own memory controller accessing its own memory to do all its computations independantly.

    In the shared memory model, the GPU and CPU compete for access to memory since they use the same memory controller accessing the same memory, and
    this has the issues of memory allocation (hence the need for a
    hyopervisor I suspect).

    Hypervisor? You're fabulating (again). Further the memory controller function is implicit in the ARM h/w - I don't believe there is a
    separate device/function for such in Apple devices though obviously
    Apple could re-do this as they see fit.

    In short, the memory required by a device is allocated by the OS and
    thus unavailable to the OS or apps for other purposes. The memory configuration needs only be set by the OS as part of startup.

    Metal will take care of converting OS/app level operations to GPU memory
    - and that is blazing fast. The rest is 0 time as far as the CPU is concerned.

    Others (nospam, JR, Lewis) have posted many links to factual information
    about M1 Macs beating many higher end intel Macs in performance (speed, energy). That's really all you need to know.

    And, as nospam points out: this is just the beginning.


    PCI Express 4 is very very fast. So the difference in performnce is not garanteed.

    Now, if you are viewing a movie where you are constantly transfering new frames and using the GPU to dis0lay instead of to compute, then the
    shared memory is good. But for such a task, the PCI Express 4 is more
    than enough anyways.

    All that output from graphics, ethernet i/o, WiFi, etc. does need to get
    to the actual hardware and PCI E is fine for that - though I've seen
    nothing to data showing the factuals - iFixIt will shed more on that in
    due course. You just don't need it to move app graphics data to a GPU.
    Higher end (pro) Macs may yet use 3rd party GPU's and will need data transported to them. Or Apple may simply up their game on the GPU side
    by another leap and the era of 3rd party GPUs ends for Macs...

    You really have to get over the fact that the M1 is beyond "major
    change" and the way things are done is different and highly optimized
    top down in both h/w and s/w.

    In effect when running Mac OS on Mx architectures it's not the same Mac
    OS at the system level. And that really is the point: moving what used
    to be complex OS ops out of the OS and into the chip allowing the CPU to
    do higher level things much faster and by default the lower level things blaze.

    Apple have tremendous resources of all kinds with the sales to support bleeding edge RD&E. Can you imagine if Apple got in their bonnet to do
    the world's most powerful supercomputer based on the emergent Mx
    architecture? I'd surmise that there are organizations already putting
    out feelers to Apple on this. And the reply would most likely be:
    "sorry, not interested." But I'd love to be surprised.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 21, 2020 16:47:50
    From Newsgroup: comp.sys.mac.system

    In message <RUauH.12386$ZbR7.10525@fx01.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-20 19:22, JF Mezei wrote:
    On 2020-11-20 13:45, Alan Browne wrote:

    Nobody said that. Your "confusion" is that a universal binary is twice
    the size as an individual binary.

    I never said that. The image activator will only load the relevant
    binary from disk, so the fact that the .App directory structiure has a
    file containing an intel binary next to the one containing the ARM
    binary is irrelevant to RAM requirements since it won't be loaded ever.



    Your other confusion is that the integrated devices (graphics, I/O)
    share the main memory. And while that is so, it is no different than
    the lower spec'd Macs that share memory with intel based graphics.

    Intel Laptops come wth 16GB of RAM. Apple halved the default to 8GB for

    Google: "intel laptop 4GB" and plenty pop up. likewise 8 GB.

    The low end intel ones have shared memory with graphics and IIRC AMD
    have a similar scheme in some CPU's.

    Your balloon just popped. (Again!).

    Oh, it's way worse that that for JF, because he really has no idea how
    these machines work and has decided that everyone using them is a liar
    part of a cast plot.

    Jason Snell, writing for MacWorld <https://www.macworld.com/article/3597569/with-m1-macs-memory-isnt-what-it-used-to-be.html>
    "But Apple isn’t integrating memory into its systems-on-a-chip out of
    spite. It’s doing it because it’s an approach that can lead to some dramatic speed benefits.

    "The M1 processor’s memory is a single pool that’s accessible by any portion of the processor. If the system needs more memory for graphics,
    it can allocate that. If it needs more memory for the Neural Engine,
    likewise. Even better, because all the aspects of the processor can
    access all of the system memory, there’s no performance hit when the
    graphics cores need to access something that was previously being
    accessed by a processor core. On other systems, the data has to be
    copied from one portion of memory to another—but on the M1, it’s just instantly accessible."

    and

    "But if you combine the efficiency of the unified memory architecture
    with the speed of SSD storage, and consider most everyday use cases, I’m pretty sure that most regular users could get by with 8GB of unified memory—or, if you want to be absolutely sure, upgrade that to 16GB. (I
    did.)"

    My Mac Mini at work is "only" 8 GB and I do all of the above plus a
    Fusion VM of Win 10 and all works fine - and it's an i3. Not a heavy
    lifter by any stretch - but fine for administration of a small business
    (and I likely do much more than most). It's far better than the MBA it replaced, to be sure (and it too, 8 GB, did fine).

    I have a six core Mac mini with 16GB. I figured I would upgrade the
    memory myself to 32 when I needed it.

    I have not needed it. Even when dealing with large video files that drag
    my machine to its knees, the memory is not the issue.

    I broiught that up in the contect is upcoming chips, whether Apple will
    increase the IO subsystem and how. This is not memory related.

    It's most definitely memory related - the unified memory is all about
    speed through proximity and tight integration.

    And speed through having a very wide path. It's the difference between
    having a 2" waterline into your house and a 1/2" water line into the
    house.

    Metal will take care of converting OS/app level operations to GPU memory
    - and that is blazing fast. The rest is 0 time as far as the CPU is concerned.

    Yep.

    Others (nospam, JR, Lewis) have posted many links to factual information about M1 Macs beating many higher end intel Macs in performance (speed, energy). That's really all you need to know.

    But he would need to 1) read 2) reread 3) reread 4) understand.

    And what are the odds of that?

    In effect when running Mac OS on Mx architectures it's not the same Mac
    OS at the system level. And that really is the point: moving what used
    to be complex OS ops out of the OS and into the chip allowing the CPU to
    do higher level things much faster and by default the lower level things blaze.

    The key thing that is most impressive about the M1 is that it can run translated Intel x64 code faster than Intel CPUs can.

    --
    The hippo of recollection stirred in the muddy waters of the mind.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 21, 2020 11:50:12
    From Newsgroup: comp.sys.mac.system

    On 2020-11-20 20:03, JF Mezei wrote:
    On 2020-11-20 19:51, Lewis wrote:

    Most importantly, with this shared memory comes huge gains in speed.

    This is Apple marketing.

    No, you are wrong and there is tons of evidence proving you are wrong.



    So based on your logic, the Intel GPUs in the Intel Laptop chips should
    have outperformed the fancy external GPUs years ago because of shared
    memory. Yet, when Apple unleashed its $60,000 Cheese Grater Mac Pro, it
    used external GPUs, not the internal Intel ones.

    Again with the obtuse comparison. Sheesh.

    I guess that $400 waste of upgrade on your Mac Pro is really eating your
    guts out.

    Where you are purposefully keeping you head in the sand

    The only one here with his head in the sand is you. In spades.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 21, 2020 11:52:48
    From Newsgroup: comp.sys.mac.system

    On 2020-11-20 23:22, Savageduck wrote:
    On Nov 20, 2020, Alan Browne wrote
    (in article <90UtH.1025$jL.287@fx13.iad>):

    On 2020-11-18 12:54, Stephen Hoffman wrote:

    Being somewhat familiar with what you were using as an example, I was
    confused. I'm still confused.

    Don't worry. It's not you.

    “Anyone who isn’t confused really doesn’t understand the situation†- Edward R. Murrow

    I think he believes who he's replying to has a clue. And that would
    indeed be confusing until reality sets in.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 21, 2020 12:02:46
    From Newsgroup: comp.sys.mac.system

    On 2020-11-21 11:47, Lewis wrote:
    In message <RUauH.12386$ZbR7.10525@fx01.iad> Alan Browne <bitbucket@blackhole.com> wrote:

    Others (nospam, JR, Lewis) have posted many links to factual information
    about M1 Macs beating many higher end intel Macs in performance (speed,
    energy). That's really all you need to know.

    But he would need to 1) read 2) reread 3) reread 4) understand.

    And what are the odds of that?

    Best? 3 out of 4. Obviously.


    In effect when running Mac OS on Mx architectures it's not the same Mac
    OS at the system level. And that really is the point: moving what used
    to be complex OS ops out of the OS and into the chip allowing the CPU to
    do higher level things much faster and by default the lower level things
    blaze.

    The key thing that is most impressive about the M1 is that it can run translated Intel x64 code faster than Intel CPUs can.

    That's a blackbox view so far. We don't know the cycle speed(s) so it's
    hard to know what is actually what. I look forward to someone
    disassembling Rosetta converted code v. the original. That could have
    some great insights (my other long post this am refers).

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 21, 2020 17:54:43
    From Newsgroup: comp.sys.mac.system

    In message <XKbuH.41697$gR8.5257@fx45.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-21 11:47, Lewis wrote:
    In message <RUauH.12386$ZbR7.10525@fx01.iad> Alan Browne <bitbucket@blackhole.com> wrote:

    Others (nospam, JR, Lewis) have posted many links to factual information >>> about M1 Macs beating many higher end intel Macs in performance (speed,
    energy). That's really all you need to know.

    But he would need to 1) read 2) reread 3) reread 4) understand.

    And what are the odds of that?

    Best? 3 out of 4. Obviously.


    In effect when running Mac OS on Mx architectures it's not the same Mac
    OS at the system level. And that really is the point: moving what used
    to be complex OS ops out of the OS and into the chip allowing the CPU to >>> do higher level things much faster and by default the lower level things >>> blaze.

    The key thing that is most impressive about the M1 is that it can run
    translated Intel x64 code faster than Intel CPUs can.

    That's a blackbox view so far. We don't know the cycle speed(s) so it's
    hard to know what is actually what.

    We do know that Intel x64 apps are running faster on the M1 than on the remaining 13" Mac Book Pro. We also know that some of the APIs execute
    twice as fast in translation than on the Intel chips. I forget the exact
    call that Apple mentioned, but it was something like NSRelease which
    takes 30ns on intel, 8 on the M1, and 14ns on the M1 in Intel mode.

    Ah, yes, here it is:

    <https://daringfireball.net/2020/11/the_m1_macs>
    Fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on
    current gen Intel, and ~6.5 nanoseconds on an M1

    … and ~14 nanoseconds on an M1 emulating an Intel.

    This was David Smith, an Apple Engineer (not the be confused with the
    developer _DavidSmith).


    --
    The real American folksong is a rag -- a mental jag A rhythmic tone
    for the chronic blues
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 21, 2020 13:30:31
    From Newsgroup: comp.sys.mac.system

    On 2020-11-21 12:54, Lewis wrote:
    In message <XKbuH.41697$gR8.5257@fx45.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-21 11:47, Lewis wrote:
    In message <RUauH.12386$ZbR7.10525@fx01.iad> Alan Browne <bitbucket@blackhole.com> wrote:

    Others (nospam, JR, Lewis) have posted many links to factual information >>>> about M1 Macs beating many higher end intel Macs in performance (speed, >>>> energy). That's really all you need to know.

    But he would need to 1) read 2) reread 3) reread 4) understand.

    And what are the odds of that?

    Best? 3 out of 4. Obviously.


    In effect when running Mac OS on Mx architectures it's not the same Mac >>>> OS at the system level. And that really is the point: moving what used >>>> to be complex OS ops out of the OS and into the chip allowing the CPU to >>>> do higher level things much faster and by default the lower level things >>>> blaze.

    The key thing that is most impressive about the M1 is that it can run
    translated Intel x64 code faster than Intel CPUs can.

    That's a blackbox view so far. We don't know the cycle speed(s) so it's
    hard to know what is actually what.

    We do know that Intel x64 apps are running faster on the M1 than on the remaining 13" Mac Book Pro. We also know that some of the APIs execute
    twice as fast in translation than on the Intel chips. I forget the exact
    call that Apple mentioned, but it was something like NSRelease which
    takes 30ns on intel, 8 on the M1, and 14ns on the M1 in Intel mode.

    Ah, yes, here it is:

    <https://daringfireball.net/2020/11/the_m1_macs>
    Fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1

    … and ~14 nanoseconds on an M1 emulating an Intel.

    Good data points. Thx. Astounding. Did I ever tell you about
    migrating from VAX to Alpha? You see, ...

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Stephen Hoffman@seaohveh@hoffmanlabs.invalid to comp.sys.mac.system on Saturday, November 21, 2020 14:58:04
    From Newsgroup: comp.sys.mac.system

    On 2020-11-20 17:31:01 +0000, JF Mezei said:

    On 2020-11-18 12:54, Stephen Hoffman wrote:

    The developers were certainly exposed. I had C code that needed
    changes, both due to framework deprecations and due to pointer changes.
    Apps using entirely OO had rather less work required, outside of
    frameworks deprecations.

    What I rememher is that moving from 32 to 64 (VAX to Alpha) requires a
    lot of changes. Migrating the UAF didn't work because WSLIMIT and
    related paramenters were grossly insufficient because processes now
    needed a lot more memory. (and same with corresponding SYSGEN
    parameters)

    The curret migration is from 64 bits OS-X on Intel 8086 to 64 bits OS0X
    on ARM. So the big change is not on pointer size, but rather on how
    many instructions are needed to perform the same task (and size of instructions).

    You probably didn't have to do a 32- to 64-bit source code migration
    from OpenVMS VAX to OpenVMS Alpha. Many (most?) OpenVMS developers did
    not have to deal with that.

    Are there changes beyond the architectural pointer-size shifts? Sure.
    Alpha required a larger working set than does VAX, which are associated
    with your WSLIMIT changes, and with WSMAX and other settings. Which as
    you well know, ties back to memory capacity.

    Going from a processor architecture designed in an era when memory was
    tiny and comparatively hugely expensive (VAX, USD$36K for 8 MB MS780
    memory for the VAX-11/780) to an era where memory is far cheaper but
    speeds and feeds are an increasing factor... means different trade-offs.

    I don't know what the ratio would be, pending tests.

    Would you agree that someone claiming the migration from 64 bits OS-X
    on x86 to 64 bits OS-X on ARM would NOT result in half of RAM
    requirement as some here have argued?

    A source code build of all libretro cores required 6095.13 seconds on a
    32 GB 12-core Mac Pro 2019 Intel, and required 4570.09 seconds on a 13" MacBook Pro 2020 M1 with 16 GB of RAM.

    But again, I don't know what the memory usage ratio between macOS on
    Intel and macOS on M1 might be. And halving main memory, while also substantially increasing performance is still a performance improvement.

    Having fast main storage can make less main memory feasible.

    Is there data that shows that an SSD can be as fast as DDR4 memory,
    when you consider that all accesses go through the Secure Enclave which encrypts/decrypts data?

    As fast as? No. Fast enough? See the libretro numbers above.

    Being somewhat familiar with what you were using as an example, I was
    confused. I'm still confused.

    I is simple. Someone stated that reducing base model from 16 to 8GB was nornal because M1 chip required much less memory than a x86 running the
    same OS that has already been pruned of 32bit legacy APIs (so truly comparing apples to apples)pardon the pun).

    I was trying to argue that if anything, memory footp]rint of gong from
    CISC to RISC inxreases RAM requirement.

    Details here differ. Speeds and feeds differ. Trade-offs differ, too.

    Here's a little light reading: https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020-7b4d42c9a9de


    And Apple M1 uses a yet-different hardware design mix, not reflected in
    that article.

    I'd expect a substantial effect from faster I/O buses and faster main
    storage than from architectural integer sizes—you're seemingly
    assuming old paging performance characteristics within your memory
    sizing calculations here,

    Are you saying that increased reliance on paging to disk is compensated
    by having faster disk and faster IO ?

    With that logic, wouldn't it be fair to state that having more RAM
    would icrease performance even further because it would be faster than paging to disk?

    If more memory can be fit on the SoC without radically increasing the
    target costs, and if the app is constrained by memory, sure.

    Spent a fair amount of time with server design trade-offs around the
    physical distances spanned by the main storage and main memory and the processor(s), and on how fast the buses could then be reliably driven.
    Shorter (closer) connections can be driven faster. And responses arrive
    back faster. Longer (further) connections are necessarily driven more
    slowly. And connection distances also limit how much capacity can be configured within the necessary distances and packaging available.
    Compromises and trade-offs abound.

    Running the Adobe suite to do videos, I recently uipgraded from 24 to
    64 GB, 4 to 10 cores. And I am finding it already insufficient RAM. So
    I am quite susprised Apple finds 8GB sufficient to do any video work.

    Run some tests, and see. Maybe the faster main storage masks having
    less main memory available for caching your apps and data. Maybe not.
    Maybe your app mix doesn't fit within the target market for these early M1-based systems, and it'll be best to wait for a more capacious model;
    for a Mac system with more main memory available for caching apps and
    data. Processing source code is different from processing video data,
    after all.


    --
    Pure Personal Opinion | HoffmanLabs LLC

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Sunday, November 22, 2020 09:43:07
    From Newsgroup: comp.sys.mac.system

    On 2020-11-21 17:54:43 +0000, Lewis said:
    In message <XKbuH.41697$gR8.5257@fx45.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-21 11:47, Lewis wrote:
    In message <RUauH.12386$ZbR7.10525@fx01.iad> Alan Browne
    <bitbucket@blackhole.com> wrote:

    Others (nospam, JR, Lewis) have posted many links to factual information >>>> about M1 Macs beating many higher end intel Macs in performance (speed, >>>> energy). That's really all you need to know.

    But he would need to 1) read 2) reread 3) reread 4) understand.

    And what are the odds of that?

    Best? 3 out of 4. Obviously.


    In effect when running Mac OS on Mx architectures it's not the same Mac >>>> OS at the system level. And that really is the point: moving what used >>>> to be complex OS ops out of the OS and into the chip allowing the CPU to >>>> do higher level things much faster and by default the lower level things >>>> blaze.

    The key thing that is most impressive about the M1 is that it can run
    translated Intel x64 code faster than Intel CPUs can.

    That's a blackbox view so far. We don't know the cycle speed(s) so it's
    hard to know what is actually what.

    We do know that Intel x64 apps are running faster on the M1 than on the remaining 13" Mac Book Pro. We also know that some of the APIs execute
    twice as fast in translation than on the Intel chips. I forget the exact
    call that Apple mentioned, but it was something like NSRelease which
    takes 30ns on intel, 8 on the M1, and 14ns on the M1 in Intel mode.

    Ah, yes, here it is:

    <https://daringfireball.net/2020/11/the_m1_macs>
    Fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1

    ... and ~14 nanoseconds on an M1 emulating an Intel.

    This was David Smith, an Apple Engineer (not the be confused with the developer _DavidSmith).

    Plus, the "cycle speed" is completely irrelevant because they utterly different chip types. Every sane person knows that despite having the
    same clock speeds, a "3GHz 680x0" is different to a "3GHz PowerPC 605"
    and diffferent to a "3GHz Intel x86" and different to a "3GHz Apple
    M1". That clock speed measures the chips within the same family, it's
    not even remotely useful to compare different chips ... which is why
    the old "Intel vs PowerPC" MHz debate was always just a ridiculous
    stupidity.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 21, 2020 16:03:52
    From Newsgroup: comp.sys.mac.system

    On 2020-11-21 15:43, Your Name wrote:
    On 2020-11-21 17:54:43 +0000, Lewis said:

    Ah, yes, here it is:

    <https://daringfireball.net/2020/11/the_m1_macs>
    Fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on
    current gen Intel, and ~6.5 nanoseconds on an M1

    ... and ~14 nanoseconds on an M1 emulating an Intel.

    This was David Smith, an Apple Engineer (not the be confused with the
    developer _DavidSmith).

    Plus, the "cycle speed" is completely irrelevant because they utterly different chip types. Every sane person knows that despite having the
    same clock speeds, a "3GHz 680x0" is different to a "3GHz PowerPC 605"
    and diffferent to a "3GHz Intel x86" and different to a "3GHz Apple M1". That clock speed measures the chips within the same family, it's not
    even remotely useful to compare different chips ... which is why the old "Intel vs PowerPC" MHz debate was always just a ridiculous stupidity.

    Yes it was ridiculous. But that's not why I would like to know. First
    thing I would be comparing it to would be the ARM based processors in
    high end iPads (which already beat many PC's on some tasks). For
    example the A14 has 2 high speed cores at 3.1 GHz.

    So knowing the cycle speed of the M1 would indeed give a point of
    comparison (not to mention the core count).

    Further, in determining how one processor does a particular operation
    knowing the cycle speed is one element. The other is how many 'cycles' particular instructions or sequences of instructions take. This can be
    tricky to be sure w/o even considering cache hits, pre-fetch, branch prediction and so on. That can be compared more directly to other architectures if not 'easily'.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 21, 2020 21:06:11
    From Newsgroup: comp.sys.mac.system

    In message <b1duH.129310$xe4.41907@fx41.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-21 12:54, Lewis wrote:
    In message <XKbuH.41697$gR8.5257@fx45.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-21 11:47, Lewis wrote:
    In message <RUauH.12386$ZbR7.10525@fx01.iad> Alan Browne <bitbucket@blackhole.com> wrote:

    Others (nospam, JR, Lewis) have posted many links to factual information >>>>> about M1 Macs beating many higher end intel Macs in performance (speed, >>>>> energy). That's really all you need to know.

    But he would need to 1) read 2) reread 3) reread 4) understand.

    And what are the odds of that?

    Best? 3 out of 4. Obviously.


    In effect when running Mac OS on Mx architectures it's not the same Mac >>>>> OS at the system level. And that really is the point: moving what used >>>>> to be complex OS ops out of the OS and into the chip allowing the CPU to >>>>> do higher level things much faster and by default the lower level things >>>>> blaze.

    The key thing that is most impressive about the M1 is that it can run
    translated Intel x64 code faster than Intel CPUs can.

    That's a blackbox view so far. We don't know the cycle speed(s) so it's
    hard to know what is actually what.

    We do know that Intel x64 apps are running faster on the M1 than on the
    remaining 13" Mac Book Pro. We also know that some of the APIs execute
    twice as fast in translation than on the Intel chips. I forget the exact
    call that Apple mentioned, but it was something like NSRelease which
    takes 30ns on intel, 8 on the M1, and 14ns on the M1 in Intel mode.

    Ah, yes, here it is:

    <https://daringfireball.net/2020/11/the_m1_macs>
    Fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on
    current gen Intel, and ~6.5 nanoseconds on an M1

    … and ~14 nanoseconds on an M1 emulating an Intel.

    Good data points. Thx. Astounding. Did I ever tell you about
    migrating from VAX to Alpha? You see, ...

    Keep it up and imma unplugging your Internet!


    --
    THERE'S JUST ME, said Death. THE FINAL FRONTIER. --Moving Pictures
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 16:31:10
    From Newsgroup: comp.sys.mac.system

    On 2020-11-21 11:05, Alan Browne wrote:

    Google: "intel laptop 4GB" and plenty pop up. likewise 8 GB.

    Try doing video work with only 4FB of work.

    I have a 3 minute video on After Effects that cause the later to grow to
    ~30GB of RAM when working on it, and when rending takes up the full 64GB
    with the additional processes.



    Hypervisor? You're fabulating (again). Further the memory controller function is implicit in the ARM h/w -

    In a normal CPU with multiple cores, there must be a memory controller
    to synchronize cache coherence and memory access. Two cores can't access
    the same memory at same time for instance. But when these all run the
    same instance of the operating system, the oprerting system at least has control of mapping fo real vs virtual memory.

    When you have difference instrances, you need a hypervisor to manage
    resources such as disk access, access to RAM etc.

    In this case, you have a separate instance for th GPU which isn't the
    OS-X that you see on your screen. You have a separate instance for the
    neural engine. The secure enclave is more of an io device so likely
    mapped as an io device in terms of memory access.

    So when the GPU wants to access RAM, it can't just willy nilly access
    RAM, because the OS-X instance is using RAM and doesn't expect someone
    else to write/change RAM comtent that is allocatred to a process in OS-X.

    It might be possible for OS-X itself to manage the GPU's memory to
    ensure it uses memory OS- has authroized it to read/write or read only.
    But you still need a controller for cache coherence between all users
    (CPU cores, GPU cores, neural cores, etc) as well as ensuring two don't
    access same location at same time.



    In short, the memory required by a device is allocated by the OS and
    thus unavailable to the OS or apps for other purposes.


    The issue ios that the GPU is an independnat processor not controlled by
    OS-X. So it it decides it now needs 4GB of RAM instead of 2GB to render
    a complex scene, it can't just take that RAM from the 8GB the system
    has, There needs to be a mechanism for fair allocation to ensiure one
    doesn't step onto the other.


    You just don't need it to move app graphics data to a GPU.


    You are forgettng GPUs being used as co-processor to render scenes and
    sending the data back to the CPU. (video rendering of effects to make a
    movie on disk as opposed to just playing a movie or game with output
    doing to screen).



    Higher end (pro) Macs may yet use 3rd party GPU's and will need data transported to them. Or Apple may simply up their game on the GPU side
    by another leap and the era of 3rd party GPUs ends for Macs...

    Which is why looking at how Apple has done M1 is important because it
    likely shows how they intend to scale it to higher end machines.


    In effect when running Mac OS on Mx architectures it's not the same Mac
    OS at the system level. And that really is the point: moving what used
    to be complex OS ops out of the OS and into the chip allowing the CPU to
    do higher level things much faster and by default the lower level things blaze.

    Marketing gobbledeegook.

    the OS exists to manage workloads. It is the individual apps that are
    written to make use of neural engine, or GPU. It is the apps that have
    the Metal code they send to the GPU to be compiled and execurted, not
    the OS that decides to optimise a request and send it to neural enine or
    send it to GPU.

    You are confusing Apple's internal use of those co processors (such as
    neural engie for FaceID, Secure Enclave for Touch ID etc) with
    widespread use of them. These are explictely called, not something the
    OS decides to use on the fly for your process.


    Apple have tremendous resources of all kinds with the sales to support bleeding edge RD&E. Can you imagine if Apple got in their bonnet to do
    the world's most powerful supercomputer based on the emergent Mx architecture?

    So far, Apple has succesfully scaled up the iPhone to laptops. The
    performance is good enough to match/beat midrange, so beyond entry level laptops for raw CPU power, but useless for high workloads due to 16GB
    RAM limit.

    Lest wait and see if Apple develops a chip that comperes with IBM Power
    or or even XEON (by the time Apple gets there, Intel might have a modern
    XEON on market). HP has tried to sell ARM-based server farms, so this
    isn't new. But you need more than 16GB if you want to be taken seriously.

    And access to memory by many many cores is THE holy grail in high end computting.

    So it remains to be seen how Apple managed the memory controller in M1
    and whether that is a scalable architecture to say 24 cores and 256GB of
    RAM.

    Apple knows what it is doing and already knows what the real plans for
    the Mac pro are. But Apple isn't telling. Apple didn't even provide
    credible performance during its keynote, they are only now starting to
    come out from users (the first bacth of which are "paid" with sample
    units so revciews tend to be better.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 16:37:49
    From Newsgroup: comp.sys.mac.system

    On 2020-11-21 12:54, Lewis wrote:

    <https://daringfireball.net/2020/11/the_m1_macs>
    Fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1
    … and ~14 nanoseconds on an M1 emulating an Intel.



    Thsi is expected since that call from an Intel image simply has over
    head to gather Intel format argument list and call the native ARM
    NRObject routine that executes with all optjizations for ARM because it
    was compikled for ARM and then returns results to the jacket routine
    which then reformats return code in Intel format and returns to the
    calling program.

    Suspect you will see the same ~8 nanosecond overhead on all system
    routines when involecvd by translated image, a fairly fixed overhead for
    jacket routine to read Intel argument and , built ARM format one and
    then branch to ARM native routine.

    This also has the huge advantage that the jacket routines need no
    changes from version to version as long as argumenst for each routine
    they support don't change. (even if the routine itself changes in the
    ARM version).


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 16:45:01
    From Newsgroup: comp.sys.mac.system

    On 2020-11-21 14:58, Stephen Hoffman wrote:

    Maybe your app mix doesn't fit within the target market for these early M1-based systems,

    The problem is that Apple didn't market these laptops as great to ruin
    browsers or wordk processors, it specifically targetted video editing
    which has been oe of the highest consumer of RAM.

    I'd have no problem if Apple marketied the laptop to view movies, browse
    the web, write emails and compose text documents, manage your photos.

    But Apple explicitely and repeatedy mentioned video editing.

    Perhaps Final Cut pro got a magic update where it no longer requires RAM
    to process 4K movies.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 16:50:56
    From Newsgroup: comp.sys.mac.system

    On 2020-11-21 15:43, Your Name wrote:

    Plus, the "cycle speed" is completely irrelevant because they utterly different chip types.


    But extremely relevant if an M1 on an Air were clocked at lower speed
    than an M1 on MacBook pro or Mini.

    Apple did not divulge that information and it is only through benchmarks
    that once can see that they _appear_ to all have the smae clocks.

    When I upgraded my CPU, I had a number of choices. My 4 core XEON was at 3.7hhz. the 10 core one at 3.0 ghz, and 12 core at 2.7ghz.

    These are the same E5 generation, same socket, smame memory
    controller/speed. So yes, clock speed matters because you lose
    significant speecd on th 12 core one for single core tasks.

    The clock speed can't be used to compare anything/everything, but there
    are cases where it is a very important metric when coparing different
    variants of the same chip generation/architecture.


    (it isn't the only one since the internal caches also matter though
    perhaps this is diferrent in M1, but we really have no details on how
    Apple implemented its memory other than "unified memorry" which is
    meaningless markleting keynote gobbledeegook.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Sunday, November 22, 2020 17:21:12
    From Newsgroup: comp.sys.mac.system

    In article <yMAuH.16566$J92.10671@fx48.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    I have a 3 minute video on After Effects that cause the later to grow to ~30GB of RAM when working on it, and when rending takes up the full 64GB
    with the additional processes.

    <https://wccftech.com/m1-macbook-pro-faster-than-imac-pro-final-cut-pro- x-video-exporting-test/>
    M1 MacBook Pro Is Faster Than a 2019 iMac Pro With Vega 56 GPU,
    128GB RAM in Final Cut Pro X Video Exporting Tests

    M1 MacBook Pro
    € 10 minutes and 20 seconds
    2019 iMac Pro
    € 11 minutes and 30 seconds

    ...

    If that wasn¹t impressive, then you¹ll be shocked to know that the M1
    MacBook Pro also beats the 2019 iMac Pro when exporting an H.265
    Canon 10-bit clip recorded at 100FPS. The iMac Pro completed the
    video export in 80 seconds, but it only took the M1 MacBook Pro 45
    seconds to finish the same test. That¹s some horsepower Apple¹s 5nm
    M1 chip delivers.

    The 8-core GPU of the M1 silicon can also hold its own, despite being
    an integrated graphics solution than a dedicated one. It beats the
    GTX 1050 Ti and the RX 560 in a series of graphics-based tests in
    GFXBench 5.0. In previously leaked compute performance results, the
    M1 MacBook Air was faster than the 2019 iMac Pro in single-core
    tests and was only 8.5 percent slower in the multi-core run.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Sunday, November 22, 2020 17:21:14
    From Newsgroup: comp.sys.mac.system

    In article <yZAuH.138539$xe4.9909@fx41.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    The problem is that Apple didn't market these laptops as great to ruin browsers or wordk processors, it specifically targetted video editing
    which has been oe of the highest consumer of RAM.

    no they didn't.

    I'd have no problem if Apple marketied the laptop to view movies, browse
    the web, write emails and compose text documents, manage your photos.

    But Apple explicitely and repeatedy mentioned video editing.

    Perhaps Final Cut pro got a magic update where it no longer requires RAM
    to process 4K movies.

    there's a final cut pro benchmark where an m1 macbook pro finished
    rendering a video faster and with plenty of battery to spare, while the
    intel macbook drained the battery partway through and had to be plugged
    in for it to complete.

    here's another: <https://wccftech.com/m1-macbook-pro-faster-than-imac-pro-final-cut-pro- x-video-exporting-test/>
    M1 MacBook Pro Is Faster Than a 2019 iMac Pro With Vega 56 GPU, 128GB
    RAM in Final Cut Pro X Video Exporting Tests

    M1 MacBook Pro
    € 10 minutes and 20 seconds
    2019 iMac Pro
    € 11 minutes and 30 seconds

    ...

    If that wasn¹t impressive, then you¹ll be shocked to know that the M1
    MacBook Pro also beats the 2019 iMac Pro when exporting an H.265
    Canon 10-bit clip recorded at 100FPS. The iMac Pro completed the
    video export in 80 seconds, but it only took the M1 MacBook Pro 45
    seconds to finish the same test. That¹s some horsepower Apple¹s 5nm
    M1 chip delivers.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 22, 2020 22:35:20
    From Newsgroup: comp.sys.mac.system

    In message <NSAuH.16569$J92.7072@fx48.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-21 12:54, Lewis wrote:

    <https://daringfireball.net/2020/11/the_m1_macs>
    Fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on
    current gen Intel, and ~6.5 nanoseconds on an M1
    … and ~14 nanoseconds on an M1 emulating an Intel.

    Thsi is expected

    No, this is *not* expected.

    since that call from an Intel image simply has over
    head to gather Intel format argument list and call the native ARM
    NRObject routine that executes with all optjizations for ARM because it
    was compikled for ARM and then returns results to the jacket routine
    which then reformats return code in Intel format and returns to the
    calling program.

    You need to read better, you lumpoy moron. The M1 mac runs the Intel
    code FASTER in translation that the code runs on an Intel CPU.

    Suspect you will see the same ~8 nanosecond overhead on all system

    LEARN TO FUCKING READ.

    --
    We don't see things as they are, we see things as *we* are.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 22, 2020 22:37:33
    From Newsgroup: comp.sys.mac.system

    In message <yZAuH.138539$xe4.9909@fx41.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    But Apple explicitely and repeatedy mentioned video editing.

    Because it is MUCH faster on the M1 Macs. MUCH. FASTER.

    You know, people who actual have the machines and have used them. Unlike
    the FUDmeister troll who continues to talk out his ass with not a single
    shred of evidence. None. At all.

    --
    I listen to the wind, to the wind of my soul
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 14:41:01
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 1:50 p.m., JF Mezei wrote:
    On 2020-11-21 15:43, Your Name wrote:

    Plus, the "cycle speed" is completely irrelevant because they utterly
    different chip types.


    But extremely relevant if an M1 on an Air were clocked at lower speed
    than an M1 on MacBook pro or Mini.

    Wrong... ...again.

    Look at how they benchmark compared to each other and why would you care
    what the clock speeds are?


    Apple did not divulge that information and it is only through benchmarks
    that once can see that they _appear_ to all have the smae clocks.

    Again. Who cares?


    When I upgraded my CPU, I had a number of choices. My 4 core XEON was at 3.7hhz. the 10 core one at 3.0 ghz, and 12 core at 2.7ghz.

    And none of those numbers matter compared to the benchmark scores.


    These are the same E5 generation, same socket, smame memory
    controller/speed. So yes, clock speed matters because you lose
    significant speecd on th 12 core one for single core tasks.

    So look at the single core benchmarks for the answer.


    The clock speed can't be used to compare anything/everything, but there
    are cases where it is a very important metric when coparing different variants of the same chip generation/architecture.


    (it isn't the only one since the internal caches also matter though
    perhaps this is diferrent in M1, but we really have no details on how
    Apple implemented its memory other than "unified memorry" which is meaningless markleting keynote gobbledeegook.


    Again:

    Look...

    ...at...

    ...the...

    ...benchmarks.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 15:00:10
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 1:45 p.m., JF Mezei wrote:
    On 2020-11-21 14:58, Stephen Hoffman wrote:

    Maybe your app mix doesn't fit within the target market for these early
    M1-based systems,

    The problem is that Apple didn't market these laptops as great to ruin browsers or wordk processors, it specifically targetted video editing
    which has been oe of the highest consumer of RAM.

    And yet, reviewers have actually DONE video testing...

    ...and it works great.


    I'd have no problem if Apple marketied the laptop to view movies, browse
    the web, write emails and compose text documents, manage your photos.

    But Apple explicitely and repeatedy mentioned video editing.

    Perhaps Final Cut pro got a magic update where it no longer requires RAM
    to process 4K movies.

    Or maybe, you lack anything resembling a clue about how 4K movies are processed.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 18:18:10
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 17:21, nospam wrote:

    there's a final cut pro benchmark where an m1 macbook pro finished
    rendering a video faster and with plenty of battery to spare, while the
    intel macbook drained the battery partway through and had to be plugged
    in for it to complete.

    Comparing video rendedering against an Intel chip that was never pitched
    as high performance i suseless. Comparinfg it against an Core i7 or i9
    on iMac pro is relebant.

    So the fact that the M1 is up there with the iMacPro that has a XEON is relevant, the fact that it beats an old laptop with a laptop chip isn't.

    (this is purely in context of rendering videos, and how scalable the M1
    will be in the next few months)

    Howevere, I am very perplexed by the low ram requirements to render a
    large movie. I have to wonder if this is just adding a few simple titles
    and cut/fades, or whether this editing includes a lot fo special effects.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 18:20:50
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 17:35, Lewis wrote:

    You need to read better, you lumpoy moron. The M1 mac runs the Intel
    code FASTER in translation that the code runs on an Intel CPU.

    I did not deny this. I explained that the reason a translated image
    calling a system service sees little difference with a native image
    calling same system service is that both execute the same code for the
    system service, except the translated image first goes to a jacket
    routine that builds the argument list in ARM format to call the native
    system routine and that this overhead is small and would be likely fixed
    for all system service calls.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 18:24:28
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 17:41, Alan Baker wrote:

    But extremely relevant if an M1 on an Air were clocked at lower speed
    than an M1 on MacBook pro or Mini.

    Wrong... ...again.

    I did not claim it was clocked lower. But the fact that Apple did not
    publish this means that we have to wait for independant benchmarks to
    see what the M1 in the Air looks like compared to the M1 in Pro and Mini.

    They are coming out now, and we are starting to see that all three
    computers appears to have same baseline clock speeds. But no number on
    whether they have speed boost or not. We do know that the Air does
    throttle back a bit for long workloads, but not that much.



    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 18:29:10
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 18:00, Alan Baker wrote:

    And yet, reviewers have actually DONE video testing...

    ...and it works great.

    be careful about early reviews because they are "sponsored" by Apple who provides the reviewer with free machines.

    But the fact they the M1 is performing very well with cinebench shows it
    does have much power in it.

    Had apple provided actual numbers during keynote, it would have
    impressed instead of leading people to wonder why APple was so
    purposefully opaque with useless graphs with no scale etc.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Sunday, November 22, 2020 18:37:41
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 16:31, JF Mezei wrote:
    On 2020-11-21 11:05, Alan Browne wrote:

    Google: "intel laptop 4GB" and plenty pop up. likewise 8 GB.

    Try doing video work with only 4FB of work.

    I never said one should. You made this claim (and snipped it out in the
    reply above):

    Intel Laptops come wth 16GB of RAM. Apple halved the default to 8GB for these laptops with both having the GPU share RAM with CPU.

    Stop snipping to change context and then make some useless point.


    Hypervisor? You're fabulating (again). Further the memory controller
    function is implicit in the ARM h/w -

    In a normal CPU with multiple cores, there must be a memory controller
    to synchronize cache coherence and memory access. Two cores can't access
    the same memory at same time for instance. But when these all run the
    same instance of the operating system, the oprerting system at least has control of mapping fo real vs virtual memory.

    That is not a hypervisor. A hypervisor is a system that lets a computer operate several OS' concurrently.


    When you have difference instrances, you need a hypervisor to manage resources such as disk access, access to RAM etc.

    In this case, you have a separate instance for th GPU which isn't the
    OS-X that you see on your screen. You have a separate instance for the
    neural engine. The secure enclave is more of an io device so likely
    mapped as an io device in terms of memory access.

    So when the GPU wants to access RAM, it can't just willy nilly access
    RAM, because the OS-X instance is using RAM and doesn't expect someone
    else to write/change RAM comtent that is allocatred to a process in OS-X.

    These things are implicit in the OS' management and allocation of
    resources and dispatching via threads.


    It might be possible for OS-X itself to manage the GPU's memory to
    ensure it uses memory OS- has authroized it to read/write or read only.
    But you still need a controller for cache coherence between all users
    (CPU cores, GPU cores, neural cores, etc) as well as ensuring two don't access same location at same time.

    Above.




    In short, the memory required by a device is allocated by the OS and
    thus unavailable to the OS or apps for other purposes.


    The issue ios that the GPU is an independnat processor not controlled by OS-X. So it it decides it now needs 4GB of RAM instead of 2GB to render
    a complex scene, it can't just take that RAM from the 8GB the system
    has, There needs to be a mechanism for fair allocation to ensiure one
    doesn't step onto the other.

    To the extent that the memory for the GPU is required by the GPU it is generally a fixed amount and the OS protects it via memory controller settings.



    You just don't need it to move app graphics data to a GPU.


    You are forgettng GPUs being used as co-processor to render scenes and sending the data back to the CPU. (video rendering of effects to make a movie on disk as opposed to just playing a movie or game with output
    doing to screen).

    That memory is allocated and fixed. The CPU (naturally) can at OS
    privilege levels read the o/p of whatever subcontracted operations there
    are.
    Higher end (pro) Macs may yet use 3rd party GPU's and will need data
    transported to them. Or Apple may simply up their game on the GPU side
    by another leap and the era of 3rd party GPUs ends for Macs...

    Which is why looking at how Apple has done M1 is important because it
    likely shows how they intend to scale it to higher end machines.

    They aren't telling yet.



    In effect when running Mac OS on Mx architectures it's not the same Mac
    OS at the system level. And that really is the point: moving what used
    to be complex OS ops out of the OS and into the chip allowing the CPU to
    do higher level things much faster and by default the lower level things
    blaze.

    Marketing gobbledeegook.

    Not at all. Various functions that required the OS (or an app) to move
    data in/out of a device is now must faster as it's reduced to indexing (pointing) to a range of data and sending instructions / reading status.

    Marketing? Really? A key reason these Macs are so blazing fast is in
    good part due to the unified memory. The only marketing slight of hand
    (which they did not conceal at all) was that the memory on the M1 is in
    fact separate chip carriers on the M1 SOC. But that is mapped for the
    whole M1 to see and write - including GPU and lots of high speed I/O -
    and governed by the memory controller - in turn controlled by the OS.


    the OS exists to manage workloads. It is the individual apps that are
    written to make use of neural engine, or GPU. It is the apps that have
    the Metal code they send to the GPU to be compiled and execurted, not
    the OS that decides to optimise a request and send it to neural enine or
    send it to GPU.

    The lines are little blurrier than that when hybrid kernels are used.


    You are confusing Apple's internal use of those co processors (such as
    neural engie for FaceID, Secure Enclave for Touch ID etc) with
    widespread use of them. These are explictely called, not something the
    OS decides to use on the fly for your process.

    I am not confused. Go find a mirror. The person you see is confused.

    The OS, controls the configuration and access to the devices via the SDK's/API's etc. Some of the code used between the app layer and the
    h/w may be "compiled in" to the app; and some may pass through the OS.

    Because: hybrid kernel. And that has big implications as to what code,
    where, when is accessing the device or memory allocated to a device.



    Apple have tremendous resources of all kinds with the sales to support
    bleeding edge RD&E. Can you imagine if Apple got in their bonnet to do
    the world's most powerful supercomputer based on the emergent Mx
    architecture?

    So far, Apple has succesfully scaled up the iPhone to laptops. The performance is good enough to match/beat midrange, so beyond entry level laptops for raw CPU power, but useless for high workloads due to 16GB
    RAM limit.

    Lest wait and see if Apple develops a chip that comperes with IBM Power
    or or even XEON (by the time Apple gets there, Intel might have a modern
    XEON on market). HP has tried to sell ARM-based server farms, so this
    isn't new. But you need more than 16GB if you want to be taken seriously.

    Apple's Mx design will very quickly eclipse XEON IMO. Apple are just
    getting started.

    As to hp. Are you serious? Really?

    There is nothing about the ARM design that limits the memory to 16GB.
    The basic ARM 64 bit architecture has up to at least 40 bits of
    addressable memory and it was being upped to about 48 bits back around
    2012. I don't think Apple threw that out.

    2^40 = 1 TB.

    2^48 = 256 TB.

    So the Apple version likely can address something in between those 2
    numbers.
    And access to memory by many many cores is THE holy grail in high end computting.

    I don't think this is such a big challenge for Apple. You do know they
    dwarf intel right? Hint: intel is 10X bigger than hp and Apple is ___X
    bigger than intel.


    So it remains to be seen how Apple managed the memory controller in M1
    and whether that is a scalable architecture to say 24 cores and 256GB of
    RAM.

    The M1 is a kickoff point. There is nothing I can find limiting the
    number of cores or memory size to such a low number. I wouldn't be
    surprised if the limit exceeds 256 cores and many, many TB of RAM.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Sunday, November 22, 2020 18:39:15
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 16:37, JF Mezei wrote:
    On 2020-11-21 12:54, Lewis wrote:

    <https://daringfireball.net/2020/11/the_m1_macs>
    Fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on
    current gen Intel, and ~6.5 nanoseconds on an M1
    … and ~14 nanoseconds on an M1 emulating an Intel.



    Thsi is expected since that call from an Intel image simply has over
    head to gather Intel format argument list and call the native ARM
    NRObject routine that executes with all optjizations for ARM because it
    was compikled for ARM and then returns results to the jacket routine
    which then reformats return code in Intel format and returns to the
    calling program.

    You do not know that. Your assumptions about how Rosetta works are
    absolutely simple. Apple did not invest "simple" where Rosetta is
    concerned.


    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Sunday, November 22, 2020 18:41:44
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 18:20, JF Mezei wrote:
    On 2020-11-22 17:35, Lewis wrote:

    You need to read better, you lumpoy moron. The M1 mac runs the Intel
    code FASTER in translation that the code runs on an Intel CPU.

    I did not deny this. I explained that the reason a translated image
    calling a system service sees little difference with a native image
    calling same system service is that both execute the same code for the
    system service, except the translated image first goes to a jacket
    routine that builds the argument list in ARM format to call the native
    system routine and that this overhead is small and would be likely fixed
    for all system service calls.

    Complete and utter nonsense. Rosetta will not be doing your simplistic
    view of the world. It will be doing replacement of code so that it is
    very, very efficient.

    There are no "jacket" routines required.

    Hint: the M1 Macs could not do "intel" code as fast as they are if they
    had to go through the hoops you suggest.

    Get off it. Translation of code can be very, very clever. And this is
    Apple.


    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Sunday, November 22, 2020 18:42:45
    From Newsgroup: comp.sys.mac.system

    In article <TkCuH.30290$kM7.27069@fx43.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    there's a final cut pro benchmark where an m1 macbook pro finished rendering a video faster and with plenty of battery to spare, while the intel macbook drained the battery partway through and had to be plugged
    in for it to complete.

    Comparing video rendedering against an Intel chip that was never pitched
    as high performance i suseless. Comparinfg it against an Core i7 or i9
    on iMac pro is relebant.

    you snipped the link where an m1 mac beat a mac pro in final cut.

    here's more: <https://techcrunch.com/wp-content/uploads/2020/11/webkit-compile-time.j

    <https://techcrunch.com/wp-content/uploads/2020/11/webkit-compile-batter y1.jpg> <https://techcrunch.com/wp-content/uploads/2020/11/Final-Cut-Pro-4k60-Do lby-Vision-HDR.png> <https://techcrunch.com/wp-content/uploads/2020/11/Final-Cut-Pro-5-minut e-8K-Timeline-Export-Battery-Remaining.png>

    € 2020 13² M1 MacBook Pro 8-core 16GB
    € 2019 16² Macbook Pro 8-core 2.4GHz 32GB w/5500M
    € 2019 13² MacBook Pro 4-core 2.8GHz 16GB
    € 2019 Mac Pro 12-Core 3.3GHz 48GB w/AMD Radeon Pro Vega II 32GB

    So the fact that the M1 is up there with the iMacPro that has a XEON is relevant, the fact that it beats an old laptop with a laptop chip isn't.

    it's relevant since there are shitloads more people rendering video on
    a macbook pro than on a mac pro or imac pro.

    (this is purely in context of rendering videos, and how scalable the M1
    will be in the next few months)

    Howevere, I am very perplexed by the low ram requirements to render a
    large movie. I have to wonder if this is just adding a few simple titles
    and cut/fades, or whether this editing includes a lot fo special effects.

    keep wondering, while everyone else realizes just how much of a jump it
    is and how utterly confused you are.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Sunday, November 22, 2020 18:42:47
    From Newsgroup: comp.sys.mac.system

    In article <avCuH.30638$sW6.19176@fx47.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    be careful about early reviews because they are "sponsored" by Apple who provides the reviewer with free machines.

    rubbish, but even if that were true (which it isn't), there are
    shitloads of reviews and youtube videos from average ordinary users in
    various forums.

    But the fact they the M1 is performing very well with cinebench shows it
    does have much power in it.

    shitloads.

    Had apple provided actual numbers during keynote, it would have
    impressed instead of leading people to wonder why APple was so
    purposefully opaque with useless graphs with no scale etc.

    they were not purposefully opaque.

    in fact, they were very clear that m1 is faster and more power
    efficient.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Sunday, November 22, 2020 18:42:48
    From Newsgroup: comp.sys.mac.system

    In article <9DCuH.75970$ql4.3414@fx39.iad>, Alan Browne <bitbucket@blackhole.com> wrote:

    So it remains to be seen how Apple managed the memory controller in M1
    and whether that is a scalable architecture to say 24 cores and 256GB of RAM.

    The M1 is a kickoff point. There is nothing I can find limiting the
    number of cores or memory size to such a low number. I wouldn't be surprised if the limit exceeds 256 cores and many, many TB of RAM.

    there currently exists 80 and 128 core arm chips.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 15:57:48
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 3:18 p.m., JF Mezei wrote:
    On 2020-11-22 17:21, nospam wrote:

    there's a final cut pro benchmark where an m1 macbook pro finished
    rendering a video faster and with plenty of battery to spare, while the
    intel macbook drained the battery partway through and had to be plugged
    in for it to complete.

    Comparing video rendedering against an Intel chip that was never pitched
    as high performance i suseless. Comparinfg it against an Core i7 or i9
    on iMac pro is relebant.

    Which is why you snipped this:

    'If that wasn¹t impressive, then you¹ll be shocked to know that the M1
    MacBook Pro also beats the 2019 iMac Pro when exporting an H.265
    Canon 10-bit clip recorded at 100FPS. The iMac Pro completed the
    video export in 80 seconds, but it only took the M1 MacBook Pro 45
    seconds to finish the same test. That¹s some horsepower Apple¹s 5nm
    M1 chip delivers.'


    So the fact that the M1 is up there with the iMacPro that has a XEON is relevant, the fact that it beats an old laptop with a laptop chip isn't.

    It isn't just "up there" with an iMac Pro, liar: it demolished an iMac Pro.


    (this is purely in context of rendering videos, and how scalable the M1
    will be in the next few months)

    Howevere, I am very perplexed by the low ram requirements to render a
    large movie. I have to wonder if this is just adding a few simple titles
    and cut/fades, or whether this editing includes a lot fo special effects.

    Hmmmm...

    I know!

    Maybe you lack any kind of clue about the necessities for rendering video.

    Hint: you work on one to perhaps a few frames at a time, depending on
    whether or not the codec is using not using or using inter-frame
    compression respectively).

    Uncompressed 4K video is on the order of 31MB per frame. So even if
    you're compositing 10 different sources of that size AND each requires
    (say) 3 frames to be loaded at any one time, you've only got 930MB
    loaded in RAM at any one time.

    So where do imagine that this huge RAM requirement comes from?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 15:58:53
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 3:29 p.m., JF Mezei wrote:
    On 2020-11-22 18:00, Alan Baker wrote:

    And yet, reviewers have actually DONE video testing...

    ...and it works great.

    be careful about early reviews because they are "sponsored" by Apple who provides the reviewer with free machines.

    Ummmmm... ...no.

    They are NOT all sponsored.


    But the fact they the M1 is performing very well with cinebench shows it
    does have much power in it.

    Had apple provided actual numbers during keynote, it would have
    impressed instead of leading people to wonder why APple was so
    purposefully opaque with useless graphs with no scale etc.

    No one besides you is having trouble with what Apple presented...

    ...and the reviews have been universally positive.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Savageduck@savageduck1@{REMOVESPAM}me.com to comp.sys.mac.system on Sunday, November 22, 2020 16:28:23
    From Newsgroup: comp.sys.mac.system

    On Nov 22, 2020, JF Mezei wrote
    (in article <yZAuH.138539$xe4.9909@fx41.iad>):

    On 2020-11-21 14:58, Stephen Hoffman wrote:

    Maybe your app mix doesn't fit within the target market for these early M1-based systems,

    The problem is that Apple didn't market these laptops as great to ruin browsers or wordk processors, it specifically targetted video editing
    which has been oe of the highest consumer of RAM.

    I'd have no problem if Apple marketied the laptop to view movies, browse
    the web, write emails and compose text documents, manage your photos.

    But Apple explicitely and repeatedy mentioned video editing.

    Perhaps Final Cut pro got a magic update where it no longer requires RAM
    to process 4K movies.

    You can run iOS apps on the M1 Macs, so try LumaFusion on your new M1, rather than FC.
    <https://luma-touch.com>

    --
    Regards,
    Savageduck

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 16:43:02
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 3:24 p.m., JF Mezei wrote:
    On 2020-11-22 17:41, Alan Baker wrote:

    But extremely relevant if an M1 on an Air were clocked at lower speed
    than an M1 on MacBook pro or Mini.

    Wrong... ...again.

    I did not claim it was clocked lower. But the fact that Apple did not publish this means that we have to wait for independant benchmarks to
    see what the M1 in the Air looks like compared to the M1 in Pro and Mini.

    You claimed it was "extremely relevant"...

    ...and that is complete bullshit.

    Clock speed isn't relevant.

    How fast things ACTUALLY GET DONE is relevant.


    They are coming out now, and we are starting to see that all three
    computers appears to have same baseline clock speeds. But no number on whether they have speed boost or not. We do know that the Air does
    throttle back a bit for long workloads, but not that much.

    And again: speed boost or not is irrelevant...

    ...when you can get ACTUAL BENCHMARK RESULTS
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 20:10:54
    From Newsgroup: comp.sys.mac.system

    I am watching a video where actual rendering, not just playing of a
    video and the MacBook Pro with 8GB RAM beat the pants off a MacPro 2019 *Cheese grater) with 192 GB.

    The tested did fins that wiuth 8K video, there were problems playing
    back. (on the other hand, displaying on a atiny screen isn't actual an
    8K display, it is a scaled down image whereeas on the Mac pro, the guy
    had a real display).

    He noted plenty of swap file used.

    So if performance is this good with swappping, I have to wonder what it
    will be like of/when Apple releases models with up to 256GB of memory.



    The video I watched:
    https://youtu.be/GMzT3bajoPs


    Note the software he is using is very GPU intensive, not CPU intensive.


    On a test fo Prem,iere Pro, he noticed this was CPU intensive, not GPU intensive, and saw dropped frames playing back.

    The real horsepower is wgen you export though, not playing back.

    I am susprised disl ip would be so far for swappinG/paging sicne it all
    gores through secure enclave for encryption. So that part must be super
    fast too.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 20:32:05
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 18:37, Alan Browne wrote:

    That is not a hypervisor. A hypervisor is a system that lets a computer operate several OS' concurrently.

    What do you think an 8 core GPU does?
    What do you think the neural network does? Neither runs OS-X. Yet they
    share hardware such as RAM.


    These things are implicit in the OS' management and allocation of
    resources and dispatching via threads.

    A GPU is not a thread running under control of OS-X. It is a different independant computer with its own CPU cores, it own operating system
    instance.

    And consider how Windows runs on laptops with Intel's integrated memory
    sharing GPUs. Windows is unaware of these GPUs sharinfg memory because
    some form of hypervisor manages this, just as it mamages resources when
    you have different OS instances running on same machine.



    That memory is allocated and fixed. The CPU (naturally) can at OS
    privilege levels read the o/p of whatever subcontracted operations there are.

    Where did you find the ifnormation on how GPU and CPU share memory and
    who controsl what ?

    Marketing? Really? A key reason these Macs are so blazing fast is in
    good part due to the unified memory.

    How do you know that? Unified memory is marketing gobbledeegook. The Intellaptop CPUs also had shared memory with GPUs, yet, achieved newhere
    near the performance that Apple appears to be achieving with the M1.
    There is a lot more to the soup than just the opaque memory susbsystem
    Apple has developped.


    fact separate chip carriers on the M1 SOC. But that is mapped for the
    whole M1 to see and write - including GPU and lots of high speed I/O -
    and governed by the memory controller - in turn controlled by the OS.

    Are you aware this is standard fiunction of RAM with a memory controller serving multiple cores and oon larger systems multiple physical CPUs ?

    Mac Pro 2009 amd Xserve 2009 could come would multple physical CPUs and
    memory controller architecture to deal with that. (see, I didn't bring
    up VAX).



    The OS, controls the configuration and access to the devices via the SDK's/API's etc.

    GPUs are far more than devices, they are computers on their own.
    Normalll have their own compiler, own RAM, and many cores. Here, they
    shjare memory with the CPU's cores, but would still have its own OS
    instance , its own compiler to take Metal code, compile and run it.

    What has changed is that the application urnning on CPU sends the source
    code via memory DMA isntead of via the PCI-E bus. But the GPU remans a
    separate entity.


    There is nothing about the ARM design that limits the memory to 16GB.

    Correct. But Putting 256GB of RAM on an SoC may not be physically
    possible in near term, so how Apple manages growing from glorified
    iPhone SoC to a full computer CPU with peripheral (expandable RAM, more thunderbolt buses etc) remains to be seen. Or will they insist that
    going forwrds, paging performance is such that people won't need more
    than 16GB of RAM ?

    Had Apple had external RAM, then then path would be clear. But with
    internal in-chip RAM, it remains to be seen whether Apple will insist on keeping all RAM inside or if it will evolved to external RAM (with
    whatecver performance issues this might bring).



    I don't think this is such a big challenge for Apple. You do know they dwarf intel right? Hint: intel is 10X bigger than hp and Apple is ___X bigger than intel.

    HP self destructed. Intel is still a very large gorilla in the room,
    and while they are currently comatose, they could come back. AMD has
    uppped the game quite a bit in the x86 arena and NVIDIA upped it big
    time in GPU one.

    From a volume point of view, Apple is still small potatoes in the CPU
    market. And since it is doubtful Apple will start selling their CPUs to competitors, it will remain a small but veruy focused operation to make
    purpose chips for Apple.

    What remains to be seen is whether M1 contains a lot of non-ARM magic
    inside for that type of performance, or whether it really was just a
    question of getting down to 5nm process and getting that performance.

    When HPE did ARM servers, the peformance was oh-hum. Didn't attract news headlines.

    Now, Apple is beating expectations big time with its performance.

    So the question becomes whether other ARM licencees will be able to
    match Apple once they get to 5nm etc, or whether Apple truly has special
    sauce inside that will prevent the others from coming close. Only time
    will tell.


    Glad I sold my Intel stock last year because if Qualcomm, Samsung and
    others are able to get ARM based chips that rivale Apple's, then
    multiple source for ARM chips will likely kill the multiple source for x86.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 22, 2020 20:32:59
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 18:39, Alan Browne wrote:

    You do not know that. Your assumptions about how Rosetta works are absolutely simple. Apple did not invest "simple" where Rosetta is concerned.

    I had reasd documents about Rosetta 2 when they were released and they explained the translation of argument lists via a jacked Intel routine
    that then called the ARM native system routine.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 18:20:26
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 5:10 p.m., JF Mezei wrote:
    I am watching a video where actual rendering, not just playing of a
    video and the MacBook Pro with 8GB RAM beat the pants off a MacPro 2019 *Cheese grater) with 192 GB.

    Bully for you!

    Did you learn anything from the experience. I doubt it very much.

    :-)


    The tested did fins that wiuth 8K video, there were problems playing
    back. (on the other hand, displaying on a atiny screen isn't actual an
    8K display, it is a scaled down image whereeas on the Mac pro, the guy
    had a real display).

    He noted plenty of swap file used.

    So if performance is this good with swappping, I have to wonder what it
    will be like of/when Apple releases models with up to 256GB of memory.

    You realize that with most processing tasks, there is a point where
    increasing something like RAM doesn't make any more difference, right?

    No.. ...you probably haven't a clue.




    The video I watched:
    https://youtu.be/GMzT3bajoPs


    Note the software he is using is very GPU intensive, not CPU intensive.


    On a test fo Prem,iere Pro, he noticed this was CPU intensive, not GPU intensive, and saw dropped frames playing back.

    The real horsepower is wgen you export though, not playing back.

    I am susprised disl ip would be so far for swappinG/paging sicne it all
    gores through secure enclave for encryption. So that part must be super
    fast too.

    So you imagine that Apple isn't bright enough to create a swap partition
    that doesn't get encrypted? Or perhaps that they're clever enough so
    that encryption isn't a bottleneck?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 18:22:35
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 5:32 p.m., JF Mezei wrote:
    On 2020-11-22 18:37, Alan Browne wrote:

    That is not a hypervisor. A hypervisor is a system that lets a computer
    operate several OS' concurrently.

    What do you think an 8 core GPU does?

    Not run several OSes concurrently... ...at least not on a Mac.

    What do you think the neural network does? Neither runs OS-X. Yet they
    share hardware such as RAM.

    Not run several OSes concurrently... ...at least not on a Mac.



    These things are implicit in the OS' management and allocation of
    resources and dispatching via threads.

    A GPU is not a thread running under control of OS-X. It is a different independant computer with its own CPU cores, it own operating system instance.

    Really? Show proof of this.


    And consider how Windows runs on laptops with Intel's integrated memory sharing GPUs. Windows is unaware of these GPUs sharinfg memory because
    some form of hypervisor manages this, just as it mamages resources when
    you have different OS instances running on same machine.

    Proof.




    That memory is allocated and fixed. The CPU (naturally) can at OS
    privilege levels read the o/p of whatever subcontracted operations there
    are.

    Where did you find the ifnormation on how GPU and CPU share memory and
    who controsl what ?

    Where did you get yours?


    Marketing? Really? A key reason these Macs are so blazing fast is in
    good part due to the unified memory.

    How do you know that? Unified memory is marketing gobbledeegook. The Intellaptop CPUs also had shared memory with GPUs, yet, achieved newhere
    near the performance that Apple appears to be achieving with the M1.
    There is a lot more to the soup than just the opaque memory susbsystem
    Apple has developped.

    Perhaps Apple is just a lot smarter than Intel and Microsoft.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 18:23:02
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 5:32 p.m., JF Mezei wrote:
    On 2020-11-22 18:39, Alan Browne wrote:

    You do not know that. Your assumptions about how Rosetta works are
    absolutely simple. Apple did not invest "simple" where Rosetta is
    concerned.

    I had reasd documents about Rosetta 2 when they were released and they explained the translation of argument lists via a jacked Intel routine
    that then called the ARM native system routine.


    What documents? Let's see the links.

    Put up or (please!) shut up.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 18:37:24
    From Newsgroup: comp.sys.mac.system

    On 2020-11-20 5:03 p.m., JF Mezei wrote:
    On 2020-11-20 19:51, Lewis wrote:

    Most importantly, with this shared memory comes huge gains in speed.

    This is Apple marketing.

    No, you are wrong and there is tons of evidence proving you are wrong.



    So based on your logic, the Intel GPUs in the Intel Laptop chips should
    have outperformed the fancy external GPUs years ago because of shared
    memory. Yet, when Apple unleashed its $60,000 Cheese Grater Mac Pro, it
    used external GPUs, not the internal Intel ones.

    Imagine: technology changes and improves over time!

    Who would have thought of it???


    Where you are purposefully keeping you head in the sand are the
    scalability issues. The integrated GPU with shared memory ahs worked in laptops (and for M1 laptops , outperforming by far similar Intel
    laptops that also hsrae memory).

    However, as you scale up, you find compuyers all have external GPUs
    because they want more hosrsepower and when you grow GPU horsepower, you
    grow demand on memory access and this starts to conflict with CPU
    accessing memory while CPU is chugging along.

    So again, how Apple deals with its architecture to scale it remains to
    be seen. I am sure they have plans and prototypes inhouse. But we
    haven't seen how they plan to scale this to iMacs and Mac pro.

    So according to you, there have been no improvements in computer
    technology...

    ...ever.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Monday, November 23, 2020 04:58:24
    From Newsgroup: comp.sys.mac.system

    In message <mnCuH.30291$kM7.20340@fx43.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-22 17:35, Lewis wrote:

    You need to read better, you lumpoy moron. The M1 mac runs the Intel
    code FASTER in translation that the code runs on an Intel CPU.

    I did not deny this. I explained that the reason a translated image
    calling a system service sees little difference with a native image

    Which is NOT what happens. The difference is literally the Intel chip is
    100% slower than the M1 in translation.

    routine that builds the argument list in ARM format to call the native
    system routine and that this overhead is small and would be likely fixed
    for all system service calls.

    This is nonsense. Once again, in small words.

    Intel is slower than new Apple chip when running native Intel Code.

    The M1 runs native Intel code FASTER than Intel chips.

    Which of these words is confusing you?


    --
    'There's a limit to the power of a spring, no matter how tightly one
    winds it.' 'Oh, yes. Yes. And you hope that if you wind a spring
    one way, all its energies will unwind the other way. And
    sometimes you have to wind the spring as tight as it will go,'
    said Vetinari,' and pray it doesn't break.' --Men at Arms
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Monday, November 23, 2020 05:00:00
    From Newsgroup: comp.sys.mac.system

    In message <fjEuH.16829$J92.8518@fx48.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-22 18:39, Alan Browne wrote:

    You do not know that. Your assumptions about how Rosetta works are
    absolutely simple. Apple did not invest "simple" where Rosetta is
    concerned.

    I had reasd documents about Rosetta 2 when they were released and they explained the translation of argument lists via a jacked Intel routine
    that then called the ARM native system routine.

    Provide the apple.com link or admit you are a liar.

    --
    "Are you pondering what I'm pondering?"
    "Are you pondering cheesesticks?"
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 22, 2020 21:04:58
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 8:58 p.m., Lewis wrote:
    In message <mnCuH.30291$kM7.20340@fx43.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-22 17:35, Lewis wrote:

    You need to read better, you lumpoy moron. The M1 mac runs the Intel
    code FASTER in translation that the code runs on an Intel CPU.

    I did not deny this. I explained that the reason a translated image
    calling a system service sees little difference with a native image

    Which is NOT what happens. The difference is literally the Intel chip is
    100% slower than the M1 in translation.

    routine that builds the argument list in ARM format to call the native
    system routine and that this overhead is small and would be likely fixed
    for all system service calls.

    This is nonsense. Once again, in small words.

    Intel is slower than new Apple chip when running native Intel Code.

    The M1 runs native Intel code FASTER than Intel chips.

    Which of these words is confusing you?



    To be more accurate:

    "Intel Macs running native Intel code are slower than Macs running the
    new Apple chip when running Rosetta-translated Intel code."
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Monday, November 23, 2020 16:52:58
    From Newsgroup: comp.sys.mac.system

    In message <avCuH.30638$sW6.19176@fx47.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-22 18:00, Alan Baker wrote:

    And yet, reviewers have actually DONE video testing...

    ...and it works great.

    be careful about early reviews because they are "sponsored" by Apple who provides the reviewer with free machines.

    You are a fucking lying piece of shit.

    --
    "Are you pondering what I'm pondering?"
    "I think so, Brain, but wouldn't his movies be more suitable for
    children if he was named Jean-Claude van Darn?"
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Monday, November 23, 2020 16:54:54
    From Newsgroup: comp.sys.mac.system

    In message <rpfftq$ffk$1@dont-email.me> Alan Baker <notonyourlife@no.no.no.no> wrote:
    On 2020-11-22 8:58 p.m., Lewis wrote:
    In message <mnCuH.30291$kM7.20340@fx43.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-22 17:35, Lewis wrote:

    You need to read better, you lumpoy moron. The M1 mac runs the Intel
    code FASTER in translation that the code runs on an Intel CPU.

    I did not deny this. I explained that the reason a translated image
    calling a system service sees little difference with a native image

    Which is NOT what happens. The difference is literally the Intel chip is
    100% slower than the M1 in translation.

    routine that builds the argument list in ARM format to call the native
    system routine and that this overhead is small and would be likely fixed >>> for all system service calls.

    This is nonsense. Once again, in small words.

    Intel is slower than new Apple chip when running native Intel Code.

    The M1 runs native Intel code FASTER than Intel chips.

    Which of these words is confusing you?



    To be more accurate:

    "Intel Macs running native Intel code are slower than Macs running the
    new Apple chip when running Rosetta-translated Intel code."

    That's way to complex for the pinhead.

    --
    You think you can catch Keyser Soze?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Monday, November 23, 2020 09:25:59
    From Newsgroup: comp.sys.mac.system

    On 2020-11-23 8:54 a.m., Lewis wrote:
    In message <rpfftq$ffk$1@dont-email.me> Alan Baker <notonyourlife@no.no.no.no> wrote:
    On 2020-11-22 8:58 p.m., Lewis wrote:
    In message <mnCuH.30291$kM7.20340@fx43.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-22 17:35, Lewis wrote:

    You need to read better, you lumpoy moron. The M1 mac runs the Intel >>>>> code FASTER in translation that the code runs on an Intel CPU.

    I did not deny this. I explained that the reason a translated image
    calling a system service sees little difference with a native image

    Which is NOT what happens. The difference is literally the Intel chip is >>> 100% slower than the M1 in translation.

    routine that builds the argument list in ARM format to call the native >>>> system routine and that this overhead is small and would be likely fixed >>>> for all system service calls.

    This is nonsense. Once again, in small words.

    Intel is slower than new Apple chip when running native Intel Code.

    The M1 runs native Intel code FASTER than Intel chips.

    Which of these words is confusing you?



    To be more accurate:

    "Intel Macs running native Intel code are slower than Macs running the
    new Apple chip when running Rosetta-translated Intel code."

    That's way to complex for the pinhead.


    Perhaps... ...but others read what you write, so try to be accurate even
    with pinheads.

    :-)
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Jolly Roger@jollyroger@pobox.com to comp.sys.mac.system on Monday, November 23, 2020 18:21:05
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-22 18:00, Alan Baker wrote:

    And yet, reviewers have actually DONE video testing...

    ...and it works great.

    be careful about early reviews

    Ever the FUDster. You just can't help your sad self, can you?

    What a fucking joke.

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Monday, November 23, 2020 14:53:45
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 23:58, Lewis wrote:

    Which is NOT what happens. The difference is literally the Intel chip is
    100% slower than the M1 in translation.

    The context was a comparison in calling a specific system service from a translated image vs the natively compiled image with a very small
    difference.

    So mu response was in line. The small difference v=between the two is
    because the translated image ends up calling the native ARM system
    service after going through a jacket routine which translates the Intel
    format argument list into ARM format argument list.

    This has nothing to do with code actually running on Intel. It was a
    comparison of translated image vs natively compiled.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Monday, November 23, 2020 14:58:17
    From Newsgroup: comp.sys.mac.system

    On 2020-11-23 11:52, Lewis wrote:

    be careful about early reviews because they are "sponsored" by Apple who
    provides the reviewer with free machines.

    You are a fucking lying piece of shit.

    Apple has seeded well known reviewers with the the 2 new computers so
    they can run benchmarks and report.

    More recent reviews will start to include people who actually purchased
    units for their own use.

    Here is a difference: early ones didn't report on paging when rendering
    videos and didn't report on "export" function performance (where the
    real horsepower happens), but more recent ones do.

    They still show the M1 with performance that is very very good (despite paging). But the more recent ones provide more colour on performance.
    And the more recent ones are also the ones who provided comparison with
    a $60,000 cheese grater Mac pro (since early reviews from seeded units
    were standalone without many comparisons).



    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Monday, November 23, 2020 20:10:41
    From Newsgroup: comp.sys.mac.system

    In message <drUuH.138614$xe4.44704@fx41.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-22 23:58, Lewis wrote:

    Which is NOT what happens. The difference is literally the Intel chip is
    100% slower than the M1 in translation.

    The context was a comparison in calling a specific system service from a translated image vs the natively compiled image with a very small
    difference.

    No, that was not the context at all. learn to read.

    14ms on M1 translated. 30ms on Intel chip.

    So mu response was in line. The small difference v=between the two is
    because the translated image ends up calling the native ARM system
    service after going through a jacket routine which translates the Intel format argument list into ARM format argument list.

    You need to learn to fucking read what youve deleted.

    This has nothing to do with code actually running on Intel. It was a comparison of translated image vs natively compiled.

    Yes it does, you clueless ignorant fuckhead.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Monday, November 23, 2020 20:13:52
    From Newsgroup: comp.sys.mac.system

    In message <tvUuH.21559$1t6.1798@fx40.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-23 11:52, Lewis wrote:

    be careful about early reviews because they are "sponsored" by Apple who >>> provides the reviewer with free machines.

    You are a fucking lying piece of shit.

    Apple has seeded well known reviewers with the the 2 new computers so
    they can run benchmarks and report.

    Which is a reveiw unit, not "free machines" you liar FUD asshole.

    More recent reviews will start to include people who actually purchased
    units for their own use.

    Did from day one since the embargo on the reviews lifted AFTER people had received their M1 Macs.

    They still show the M1 with performance that is very very good (despite

    Much better than the non Pro level machines.

    paging). But the more recent ones provide more colour on performance.
    And the more recent ones are also the ones who provided comparison with
    a $60,000 cheese grater Mac pro (since early reviews from seeded units
    were standalone without many comparisons).

    Only someone as dense as you would consider comparing a $700 machine and
    a $60,000 machine as being a valid metric. The stupid, it burns.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Monday, November 23, 2020 16:12:39
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 20:10, JF Mezei wrote:
    I am watching a video where actual rendering, not just playing of a
    video and the MacBook Pro with 8GB RAM beat the pants off a MacPro 2019 *Cheese grater) with 192 GB.

    The tested did fins that wiuth 8K video, there were problems playing
    back. (on the other hand, displaying on a atiny screen isn't actual an
    8K display, it is a scaled down image whereeas on the Mac pro, the guy
    had a real display).

    He noted plenty of swap file used.

    So if performance is this good with swappping, I have to wonder what it
    will be like of/when Apple releases models with up to 256GB of memory.



    The video I watched:
    https://youtu.be/GMzT3bajoPs


    Note the software he is using is very GPU intensive, not CPU intensive.


    On a test fo Prem,iere Pro, he noticed this was CPU intensive, not GPU intensive, and saw dropped frames playing back.

    The real horsepower is wgen you export though, not playing back.

    I am susprised disl ip would be so far for swappinG/paging sicne it all
    gores through secure enclave for encryption. So that part must be super
    fast too.

    Type slower. Read before you post.

    The S.E. can convert much, much, much faster than the storage can read
    or write so it's all but a non issue.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Monday, November 23, 2020 13:18:31
    From Newsgroup: comp.sys.mac.system

    On 2020-11-23 11:58 a.m., JF Mezei wrote:
    On 2020-11-23 11:52, Lewis wrote:

    be careful about early reviews because they are "sponsored" by Apple who >>> provides the reviewer with free machines.

    You are a fucking lying piece of shit.

    Apple has seeded well known reviewers with the the 2 new computers so
    they can run benchmarks and report.

    Wrong.


    More recent reviews will start to include people who actually purchased
    units for their own use.

    There are already lots of those.




    Here is a difference: early ones didn't report on paging when rendering videos and didn't report on "export" function performance (where the
    real horsepower happens), but more recent ones do.

    And yet you give no examples...


    They still show the M1 with performance that is very very good (despite paging). But the more recent ones provide more colour on performance.
    And the more recent ones are also the ones who provided comparison with
    a $60,000 cheese grater Mac pro (since early reviews from seeded units
    were standalone without many comparisons).

    What is "colour on performance" supposed to mean?

    And present any evidence that:

    1. Early reviews were with "seeded units"

    2. That it makes any difference to what they observed.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Monday, November 23, 2020 16:50:09
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 20:32, JF Mezei wrote:
    On 2020-11-22 18:37, Alan Browne wrote:

    That is not a hypervisor. A hypervisor is a system that lets a computer
    operate several OS' concurrently.

    What do you think an 8 core GPU does?
    What do you think the neural network does? Neither runs OS-X. Yet they
    share hardware such as RAM.

    I didn't say nothing was there. I said it's not a hypervisor. The only hypervisor I can find related to Macs is in support of VM's.



    These things are implicit in the OS' management and allocation of
    resources and dispatching via threads.

    A GPU is not a thread running under control of OS-X. It is a different independant computer with its own CPU cores, it own operating system instance.

    Mac OS in fact can dispatch threads to GPU's. These are different than
    the Mac OS threads in terms of "what" the job is. But each has a
    reference on the OS side. (handle if you will).

    And consider how Windows runs on laptops with Intel's integrated memory sharing GPUs. Windows is unaware of these GPUs sharinfg memory because
    some form of hypervisor manages this, just as it mamages resources when
    you have different OS instances running on same machine.

    That's not a hypervisor in the usual sense. Yes, there is management of everything - and under Mac OS that would be Metal for up to date processors.

    That memory is allocated and fixed. The CPU (naturally) can at OS
    privilege levels read the o/p of whatever subcontracted operations there
    are.

    Where did you find the ifnormation on how GPU and CPU share memory and
    who controsl what ?

    It's implicit in the memory management as controlled by the CPU. It's
    not "new stuff". We were doing this in the 80's with dual port RAMs -
    quite primitive by today's standards. And many architectures have had
    memory mapped I/O at small and large scales for many decades. Said
    memory regions were implied off limits (the "CPU" side had to know
    where). Devices had no idea where memory began and ended on the CPU
    side. A device would have its own memory map (ie: it's "0" could be at address 0x10000). (DMA controllers would have to know (at least an
    offset) in order to control addressing on the bus of course... too much detail).


    Marketing? Really? A key reason these Macs are so blazing fast is in
    good part due to the unified memory.

    How do you know that? Unified memory is marketing gobbledeegook. The

    Listened to the presentation and I've been reading a lot about it. As
    stated elsewhere and below.

    Intellaptop CPUs also had shared memory with GPUs, yet, achieved newhere
    near the performance that Apple appears to be achieving with the M1.
    There is a lot more to the soup than just the opaque memory susbsystem
    Apple has developped.

    Yes - I informed you of that days ago...

    Again (since you don't seem to actually get it), there are huge
    advantages to disparate I/O devices all having access to one memory.

    Reduces actions by the OS and/or apps to simply pointing and commanding
    and reducing bulk transfers. Sort of DMA on steroids.

    fact separate chip carriers on the M1 SOC. But that is mapped for the
    whole M1 to see and write - including GPU and lots of high speed I/O -
    and governed by the memory controller - in turn controlled by the OS.

    Are you aware this is standard fiunction of RAM with a memory controller serving multiple cores and oon larger systems multiple physical CPUs ?

    Mac Pro 2009 amd Xserve 2009 could come would multple physical CPUs and memory controller architecture to deal with that.

    Not all bound at the chip carrier level where everything (except the
    physical memory itself) is on a single chip for many I/O parts. And
    then memory is physically very close allowing for very narrow timing tolerance. Speculation, but I'd bet Apple are clocking that memory much faster than same would do if layed out on the MB.

    The OS, controls the configuration and access to the devices via the
    SDK's/API's etc.

    GPUs are far more than devices, they are computers on their own.
    Normalll have their own compiler, own RAM, and many cores. Here, they
    shjare memory with the CPU's cores, but would still have its own OS
    instance , its own compiler to take Metal code, compile and run it.

    GPU's don't work like that. They are massive in number, tiny in
    complexity and just fast.


    What has changed is that the application urnning on CPU sends the source
    code via memory DMA isntead of via the PCI-E bus. But the GPU remans a separate entity.

    Doesn't matter. Sharing memory means far less transporting of data
    between functional entities.



    There is nothing about the ARM design that limits the memory to 16GB.

    Correct. But Putting 256GB of RAM on an SoC may not be physically
    possible in near term, so how Apple manages growing from glorified
    iPhone SoC to a full computer CPU with peripheral (expandable RAM, more thunderbolt buses etc) remains to be seen. Or will they insist that
    going forwrds, paging performance is such that people won't need more
    than 16GB of RAM ?

    Nobody said larger memory models would be SOC. Apple can elect to put
    some on the SOC and expand that to off SOC (possibly slower at that -
    but would reduce or eliminate swaps).


    Had Apple had external RAM, then then path would be clear. But with
    internal in-chip RAM, it remains to be seen whether Apple will insist on keeping all RAM inside or if it will evolved to external RAM (with
    whatecver performance issues this might bring).

    If it isn't clear to you, go look again: the memory on the M1 SOC is in
    its own chip carrier (two actually). Apple can put that memory
    wherever. And as I say above I wouldn't be very surprised if we end up
    with 'slower' RAM off SOC and 'fastest' RAM on SOC. The latter could go
    up in size as well .. guesstimate of at least 64 GB and probably much
    more with a larger SOC (essentially surround the CPU with memory.





    I don't think this is such a big challenge for Apple. You do know they
    dwarf intel right? Hint: intel is 10X bigger than hp and Apple is ___X
    bigger than intel.

    HP self destructed. Intel is still a very large gorilla in the room,
    and while they are currently comatose, they could come back. AMD has
    uppped the game quite a bit in the x86 arena and NVIDIA upped it big
    time in GPU one.

    I'm sure Apple are beyond caring what AMD, intel and NVIDIA are doing.

    From a volume point of view, Apple is still small potatoes in the CPU market. And since it is doubtful Apple will start selling their CPUs to

    You're looking at it with maximum obtuseness.

    competitors, it will remain a small but veruy focused operation to make purpose chips for Apple.

    20M+ CPU's per year under their own control (cost savings) while making
    those computers much higher performing than what intel can put out Watt
    for Watt, dollar for dollar.

    Apple don't care about how many CPU's they make. They care about how
    many computers they sell.

    And this will gain a lot of converts.



    What remains to be seen is whether M1 contains a lot of non-ARM magic
    inside for that type of performance, or whether it really was just a
    question of getting down to 5nm process and getting that performance.

    Nothing remains to be seen. That history was written years ago.

    Apple's silicon team have been expanding the ARM core for about 10
    years. Indeed the unified memory is part of that expansion as is the
    addition of the ML and their cusomized graphics cores.

    Yep, Apple aren't looking at all in the rearview mirror to base ARM configurations.


    When HPE did ARM servers, the peformance was oh-hum. Didn't attract news headlines.

    Now, Apple is beating expectations big time with its performance.

    So the question becomes whether other ARM licencees will be able to
    match Apple once they get to 5nm etc, or whether Apple truly has special sauce inside that will prevent the others from coming close. Only time
    will tell.

    The others do not have anywhere near Apple's engineering. More
    importantly, they are not integrating from the battery to the keyboard
    to the screen and everything in between (including the OS) as Apple is.

    They simply cannot do because they are not the same at all.

    So, they will come out with machines and tout x cores and y memory and z
    GPU's ... yet fail to come close in terms of the whole.

    Apple has always been about the 'whole' not the 'sum' and that has
    culminated most recently in the M1.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Monday, November 23, 2020 16:51:18
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 20:32, JF Mezei wrote:
    On 2020-11-22 18:39, Alan Browne wrote:

    You do not know that. Your assumptions about how Rosetta works are
    absolutely simple. Apple did not invest "simple" where Rosetta is
    concerned.

    I had reasd documents about Rosetta 2 when they were released and they explained the translation of argument lists via a jacked Intel routine
    that then called the ARM native system routine.

    Cite with link.



    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Tuesday, November 24, 2020 00:30:36
    From Newsgroup: comp.sys.mac.system

    On 2020-11-23 15:10, Lewis wrote:

    No, that was not the context at all. learn to read.

    14ms on M1 translated. 30ms on Intel chip.

    I was responding to the other number, something like 8ms for native
    compiled Arm vs 14ms for Intel translated.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Tuesday, November 24, 2020 00:57:28
    From Newsgroup: comp.sys.mac.system

    On 2020-11-23 16:50, Alan Browne wrote:

    Nobody said larger memory models would be SOC. Apple can elect to put
    some on the SOC and expand that to off SOC (possibly slower at that -
    but would reduce or eliminate swaps).

    It depends on whether Apple's strategy requires embeded memory for this performance, or whether having external memory won't have much impact.

    Had Apple had external RAM for this batch of new machines, then it would
    be clear that higher end models would just have more memory slots to
    support more RAM. But as it stands, it isn't clear whether Apple will
    go, or can go with external memory and how difference the memory
    architecture would be if so. (memory controller, pinouts on chip etc).



    If it isn't clear to you, go look again: the memory on the M1 SOC is in
    its own chip carrier (two actually).

    The only question is how they joined the 2 wafers (what sort virtual
    ribbon cable) bvut functionally, it is as if it had been on the same
    wafer as the rest of the CPU/GPU/etc.

    Wouldn.'t surprise me to find that all M1s are 16GB with the lower end
    modelsl having 8GB disbaled.



    wherever. And as I say above I wouldn't be very surprised if we end up
    with 'slower' RAM off SOC and 'fastest' RAM on SOC.

    Possible but comlicates the memory controller.


    I'm sure Apple are beyond caring what AMD, intel and NVIDIA are doing.

    Oh, am pretty sure they closely monitor. Because in the end, the bet of
    moving its PCs to ARM was that it could beat performance/"price/power of
    the x86 marketplace.

    If a 10watt chip can replace a 100 watt CPU and 300 watt GPU, then this
    is BIG.



    20M+ CPU's per year under their own control (cost savings) while making those computers much higher performing than what intel can put out Watt
    for Watt, dollar for dollar.

    the per watt performance matters for laptops, not really for desktops.
    (though you get into cooling challenges with current higher end wintel
    rigs).




    Apple don't care about how many CPU's they make. They care about how
    many computers they sell.

    And this will gain a lot of converts.


    This remains to be seen. The currently released models aren't omputers,
    they are appliances. Can't change memory, can't change disk. Can't
    repair it. And OS-X has moved closed to IOS and becoming mreo and more
    closed to normal applications (walled garden via App Store).

    Whether this works to gain market share or not remains to be seen.


    The others do not have anywhere near Apple's engineering.

    Don't underestimate AMD and NVIDIA.


    More
    importantly, they are not integrating from the battery to the keyboard
    to the screen and everything in between (including the OS) as Apple is.

    Integration is not so beneficial for desktops and gaming rigs. Ability
    to choose, configure your sustem is a HUGE thing for that market. Apple
    will offer one solution with 1 GPU, 1 CPU and 1 or 2 RAM options.

    And gamers often upgrade components. You can' do that on that new breed
    of fixed config appliance. This works OK for latops, but not so much
    for desktops. (though a portion fo market doesn't care for
    maintainability and upgrade after puchase).


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@Blackhole@entropy.ultimateorg to comp.sys.mac.system on Tuesday, November 24, 2020 16:46:44
    From Newsgroup: comp.sys.mac.system

    On 2020-11-24 00:57, JF Mezei wrote:
    On 2020-11-23 16:50, Alan Browne wrote:

    <S - boring>


    If it isn't clear to you, go look again: the memory on the M1 SOC is in
    its own chip carrier (two actually).

    The only question

    ... sure.



    Wouldn.'t surprise me to find that all M1s are 16GB with the lower end modelsl having 8GB disbaled.

    At the volume Apple will be making, no need to play that card.
    Configuration control is not at all their weak point.





    wherever. And as I say above I wouldn't be very surprised if we end up
    with 'slower' RAM off SOC and 'fastest' RAM on SOC.

    Possible but comlicates the memory controller.

    Not enough to mention even if so.

    <s.

    20M+ CPU's per year under their own control (cost savings) while making
    those computers much higher performing than what intel can put out Watt
    for Watt, dollar for dollar.

    the per watt performance matters for laptops, not really for desktops. (though you get into cooling challenges with current higher end wintel
    rigs).

    It matters everywhere. Regrettably that may mean Apple push the "thin"
    factor of the iMac even further.






    Apple don't care about how many CPU's they make. They care about how
    many computers they sell.

    And this will gain a lot of converts.


    This remains to be seen. The currently released models aren't omputers,
    they are appliances. Can't change memory, can't change disk. Can't
    repair it. And OS-X has moved closed to IOS and becoming mreo and more closed to normal applications (walled garden via App Store).

    Whether this works to gain market share or not remains to be seen.

    The switch to intel drove their sales up.

    The switch to this value point will drive it more.




    The others do not have anywhere near Apple's engineering.

    Don't underestimate AMD and NVIDIA.

    I didn't. I do know Apple blows them both away in sum.


    More
    importantly, they are not integrating from the battery to the keyboard
    to the screen and everything in between (including the OS) as Apple is.

    Integration is not so beneficial for desktops and gaming rigs. Ability
    to choose, configure your sustem is a HUGE thing for that market. Apple
    will offer one solution with 1 GPU, 1 CPU and 1 or 2 RAM options.

    Gaming rigs is not Apple's main market. Desktops remain to be seen in
    terms of configuration.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From ant@ant@zimage.comANT (Ant) to comp.sys.mac.system on Tuesday, November 24, 2020 16:16:23
    From Newsgroup: comp.sys.mac.system

    Alan Browne <Blackhole@entropy.ultimateorg> wrote:
    ...
    Integration is not so beneficial for desktops and gaming rigs. Ability
    to choose, configure your sustem is a HUGE thing for that market. Apple will offer one solution with 1 GPU, 1 CPU and 1 or 2 RAM options.

    Gaming rigs is not Apple's main market. Desktops remain to be seen in
    terms of configuration.

    Speaking of gaming, why is it bad in Mac? I remember when Steve Jobs showing computer games back then like Quake. I was excited to see some hardcore Mac gaming. It's like Linux is doing better than Macs. :(

    --
    Life's so loco! ..!.. *isms, sins, hates, (d)evil, tiredness, z, my body, illnesses (e.g., COVID-19 & SARS-CoV-2), deaths (RIP), heat, interruptions, issues, conflicts, obstacles, stresses, fires, out(r)ages, dramas, unlucky #4, 2020, greeds, bugs (e.g., crashes & female mosquitoes), etc. D:
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Stephen Hoffman@seaohveh@hoffmanlabs.invalid to comp.sys.mac.system on Tuesday, November 24, 2020 19:12:15
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 21:45:01 +0000, JF Mezei said:

    On 2020-11-21 14:58, Stephen Hoffman wrote:

    Maybe your app mix doesn't fit within the target market for these early
    M1-based systems,

    The problem is that Apple didn't market these laptops as great to ruin browsers or wordk processors, it specifically targetted video editing
    which has been oe of the highest consumer of RAM.

    And until you try this, you don't know that.

    Some related reading: https://mjtsai.com/blog/2020/11/23/m1-memory-and-performance/

    I'd have no problem...

    That you always seem to have problems is part of your charm, JF. Always
    has been.

    ...if Apple marketied the laptop to view movies, browse the web, write emails and compose text documents, manage your photos.

    But Apple explicitely and repeatedy mentioned video editing.

    And maybe perhaps possibly the folks at Apple have run some tests and
    know about the performance?

    Perhaps Final Cut pro got a magic update where it no longer requires
    RAM to process 4K movies.

    And perhaps once you've tried your own tests, you'll know if M1 is
    faster or slower. And with faster SSDs and faster memory access, maybe
    less memory is still faster? Again, try it. Nothing else will convince
    you.


    --
    Pure Personal Opinion | HoffmanLabs LLC

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Tuesday, November 24, 2020 16:18:01
    From Newsgroup: comp.sys.mac.system

    On 2020-11-22 1:45 p.m., JF Mezei wrote:
    On 2020-11-21 14:58, Stephen Hoffman wrote:

    Maybe your app mix doesn't fit within the target market for these early
    M1-based systems,

    The problem is that Apple didn't market these laptops as great to ruin browsers or wordk processors, it specifically targetted video editing
    which has been oe of the highest consumer of RAM.

    I'd have no problem if Apple marketied the laptop to view movies, browse
    the web, write emails and compose text documents, manage your photos.

    But Apple explicitely and repeatedy mentioned video editing.

    Perhaps Final Cut pro got a magic update where it no longer requires RAM
    to process 4K movies.

    Ummmmmm... ...no.

    The used a heavy-duty task to ILLUSTRATE the capabilities of the new
    machines.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Wednesday, November 25, 2020 00:25:20
    From Newsgroup: comp.sys.mac.system

    In message <Nuedna1sJrmqGyDCnZ2dnUU7-SOdnZ2d@earthlink.com> Ant <ant@zimage.comANT> wrote:
    Alan Browne <Blackhole@entropy.ultimateorg> wrote:
    ...
    Integration is not so beneficial for desktops and gaming rigs. Ability
    to choose, configure your sustem is a HUGE thing for that market. Apple
    will offer one solution with 1 GPU, 1 CPU and 1 or 2 RAM options.

    Gaming rigs is not Apple's main market. Desktops remain to be seen in
    terms of configuration.

    Speaking of gaming, why is it bad in Mac? I remember when Steve Jobs showing computer games back then like Quake. I was excited to see some hardcore Mac gaming. It's like Linux is doing better than Macs. :(

    Because the gaming market is comprised of a lot of people who just want
    to play games and a few completely toxic shitheads who scream constantly
    and drive people out of the market, so much so that "Gamer" is seen as
    an insult from people who are not screaming shitheads.

    I wouldn't be a game developer for the same reason I would not try to
    teach a pig to sing opera.



    --
    <https://hey.science/dumpster-fire/>
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Wednesday, November 25, 2020 15:55:19
    From Newsgroup: comp.sys.mac.system

    On 2020-11-24 22:16:23 +0000, Ant said:
    Alan Browne <Blackhole@entropy.ultimateorg> wrote:
    ...
    Integration is not so beneficial for desktops and gaming rigs. Ability
    to choose, configure your sustem is a HUGE thing for that market. Apple
    will offer one solution with 1 GPU, 1 CPU and 1 or 2 RAM options.

    Gaming rigs is not Apple's main market. Desktops remain to be seen in
    terms of configuration.

    Speaking of gaming, why is it bad in Mac? I remember when Steve Jobs showing computer games back then like Quake. I was excited to see some hardcore Mac gaming. It's like Linux is doing better than Macs. :(

    There are quite a lot of Mac games. It's partly a visibility issue.

    Unlike Windoze, Mac games are not very often available in high street
    computer stores or games stores (although occassionally you will find a
    hybrid Windoze-Mac game, usually a Blizzard title, on the Windowze game shelves).

    There also isn't much advertising of Mac games, especially outside the
    Mac App Store ... but they do exist.

    The other problem is many people use the term "games" to cover only the
    latest big-name toy on the block with flashy graphics and requiring a
    state of the art high end computer. There are thousands of Mac games
    availble if you widen the terminology - places like Steam.com, GOG.com, IndieGala.com, etc. have many games, albeit mostly, but not all, older
    ones.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Wednesday, November 25, 2020 08:45:32
    From Newsgroup: comp.sys.mac.system

    On 2020-11-24 17:16, Ant wrote:
    Alan Browne <Blackhole@entropy.ultimateorg> wrote:
    ...
    Integration is not so beneficial for desktops and gaming rigs. Ability
    to choose, configure your sustem is a HUGE thing for that market. Apple
    will offer one solution with 1 GPU, 1 CPU and 1 or 2 RAM options.

    Gaming rigs is not Apple's main market. Desktops remain to be seen in
    terms of configuration.

    Speaking of gaming, why is it bad in Mac?

    It's not bad in Mac. But.

    The gaming world grew where the market was largest and that is Windows
    PC's by far back 20 years ago when Apple had a very slim slice of the PC market.

    Gamers could easily customize and upgrade their rigs every few months if
    they cared to as new processors, GPU's etc, came out. And relatively
    cheaply. The "PC" was just a skelton holding the latest configuration.

    Now as GPU's become more and more commoditized, that distinction will
    wane and game makers will be able to hop OS' more and more easily.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Wednesday, November 25, 2020 14:59:02
    From Newsgroup: comp.sys.mac.system

    In message <1etvH.49362$J92.45030@fx48.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-24 17:16, Ant wrote:
    Alan Browne <Blackhole@entropy.ultimateorg> wrote:
    ...
    Integration is not so beneficial for desktops and gaming rigs. Ability >>>> to choose, configure your sustem is a HUGE thing for that market. Apple >>>> will offer one solution with 1 GPU, 1 CPU and 1 or 2 RAM options.

    Gaming rigs is not Apple's main market. Desktops remain to be seen in
    terms of configuration.

    Speaking of gaming, why is it bad in Mac?

    It's not bad in Mac.

    It really is. The GPUs on the Mac are designed for real work and not
    designed for game FPS, which is all most gamers care about. "What do you
    mean I can't run this at 140fps on 4K? FUC YOU."

    But.

    The gaming world grew where the market was largest and that is Windows
    PC's by far back 20 years ago when Apple had a very slim slice of the PC market.

    Gamers could easily customize and upgrade their rigs every few months if they cared to as new processors, GPU's etc, came out. And relatively cheaply. The "PC" was just a skelton holding the latest configuration.

    Now as GPU's become more and more commoditized, that distinction will
    wane and game makers will be able to hop OS' more and more easily.

    There is also the fact that nvidia had such a lead in GPU performance
    and forced a custom CUDA API on game developers, making it even harder to migrate to other GPUs, and Microsoft was doing much the same thing with DirectX, both in an effort to control the gamin market.

    The GPU performance on the new low-end Macs is stellar, however. The one
    game I still play occasionally is World of Warcraft and on my 2018 mini
    I can get 30-40 FPS if I turn down the settings to around the "3" preset
    level. On the M1 Mac mini, it will get 40-50fps at graphics level 10
    (the maximum), and that was tested BEFORE Blizzard released the M1 native client.

    I will get much better FPS than that since I do not actually like the
    game at maximum settings, and some of the settings I turn off (Ground
    clutter is one) make a dramatic impact on performance.

    My Laptop has arrive in town, but FedEx is showing estimated delivery of Monday. grmbl.

    --
    The trouble with being a god is that you've got no one to pray to.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Wednesday, November 25, 2020 13:32:45
    From Newsgroup: comp.sys.mac.system

    On 2020-11-24 19:12, Stephen Hoffman wrote:

    But Apple explicitely and repeatedy mentioned video editing.

    And maybe perhaps possibly the folks at Apple have run some tests and
    know about the performance?

    The tests that are coming out now show HUGE performance for M1. (Though
    I did spot one with an Intel Mac Mini with external GPU that beat the
    M1, but that is a outlier).

    Apple would have known about performance prior to keynote, and chose
    instead to provide useless graphs that reduced the credibilitty of its
    claims.


    A while back, I was blasted here for stating these keynotes are large
    marketing events airmed at the public, told that no, they are aimed at
    the trade press. If they are aimed at the trade press, that Apple
    should have provided hard comparable performance numbers since they make
    the M1 look really good.


    And perhaps once you've tried your own tests, you'll know if M1 is
    faster or slower.


    The argument made by Apple apologists was that the M1 required less RAM,
    hence no problem with only 8GB to do video rendering.

    Some of the more serious tests I have seen pointed out the gigabytes of page/swap file used during rendering on the 8GB M1 and much less on the
    16GB. :cl pf RAM does impact performance negatively, but because M1 is
    so much faster, it stll outperforms those without paging.

    Someone did tests for read/write on the Mini SSD, and found read was
    slightly better, write not as good as on the Intel Mini (so roughly the
    same). So a machine hindered by paging but that still performs better
    than machines that don't page means the CPU is actually faster than it
    appears to be.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Wednesday, November 25, 2020 18:40:18
    From Newsgroup: comp.sys.mac.system

    In message <irxvH.49597$8v5.26585@fx33.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    Apple would have known about performance prior to keynote, and chose
    instead to provide useless graphs that reduced the credibilitty of its claims.

    No, they provided the information that the press needed to have "Faster
    with lower power".

    You continue to make this mistake, the Apple announcements are not for
    uber nerds or computer scientists, they are PRESS EVENTS.

    The only dumbass claiming that apple's announcement "reduced their
    credibility" is you.

    A while back, I was blasted here for stating these keynotes are large marketing events airmed at the public, told that no, they are aimed at
    the trade press. If they are aimed at the trade press, that Apple
    should have provided hard comparable performance numbers since they make
    the M1 look really good.

    No, they are aimed at THE PRESS. No one but you has said "trade press"
    which largely does not even exist.

    The argument made by Apple apologists was that the M1 required less RAM, hence no problem with only 8GB to do video rendering.

    It does require less RAM; that has been shown over and over and over
    again.

    --
    Artificial intelligence is no match for natural stupidity
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Jolly Roger@jollyroger@pobox.com to comp.sys.mac.system on Wednesday, November 25, 2020 19:03:16
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    Apple would have known about performance prior to keynote, and chose
    instead to provide useless graphs that reduced the credibilitty of its claims.

    Only in the eyes of complete idiots like you who don't understand what
    those graphs actually represent.

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Wednesday, November 25, 2020 14:27:40
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 14:03, Jolly Roger wrote:

    Only in the eyes of complete idiots like you who don't understand what
    those graphs actually represent.

    Graphs with ptreyy lines but no scale are meaningless.

    Claiming your machine is faster than 95% of laotops is meaningless
    (laptop sold in unitsl laptop sold in revenue, 95% of laptop models, 95%
    of laptops still in use today?

    95% of laptops seen during a short survey at a Delta gate at some airpoirt?

    Cosnidering the M1 is faster than many desktops, Apple should have
    provided hard numbers to really show it with a huge bang, instead of meaningless "Reality distortion field" marketing gobbledeegook.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@Blackhole@entropy.ultimateorg to comp.sys.mac.system on Wednesday, November 25, 2020 15:19:57
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 13:32, JF Mezei wrote:

    Some of the more serious tests I have seen pointed out the gigabytes of page/swap file used during rendering on the 8GB M1 and much less on the
    16GB.

    What? Really? How can this BE!!!!???? a computer with less RAM swapped
    more than one with more RAM. Oh the INHUMANITY!!!!
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Wednesday, November 25, 2020 20:47:11
    From Newsgroup: comp.sys.mac.system

    In message <NeyvH.14734$Wi7.7197@fx29.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-25 14:03, Jolly Roger wrote:

    Only in the eyes of complete idiots like you who don't understand what
    those graphs actually represent.

    Graphs with ptreyy lines but no scale are meaningless.

    You re a fool who is incapable of listening to anything, and so what the
    graphs represented (which was clear to everyone else) flew right by you
    without even grazing your brain.

    Claiming your machine is faster than 95% of laotops is meaningless

    It is not. It is a number that has meaning to most people.

    (laptop sold in unitsl laptop sold in revenue, 95% of laptop models, 95%
    of laptops still in use today?

    Another example of your inability to listen, as this was clear.

    Cosnidering the M1 is faster than many desktops, Apple should have
    provided hard numbers to really show it with a huge bang

    No, because nearly no one care about ()nor understands) numbers. And no
    one in the press.

    meaningless "Reality distortion field" marketing gobbledeegook.

    Your inability to process information does not make it "marketing
    googledeegook [sic]". It's a YOU problem.


    --
    'I don't like to ask them questions.'
    'Why not?'
    'They might give me answers. And then what would I do?'
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@Blackhole@entropy.ultimateorg to comp.sys.mac.system on Wednesday, November 25, 2020 15:57:27
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 14:27, JF Mezei wrote:
    On 2020-11-25 14:03, Jolly Roger wrote:

    Only in the eyes of complete idiots like you who don't understand what
    those graphs actually represent.

    Graphs with ptreyy lines but no scale are meaningless.

    They were proportional scales and the citing was "latest PC laptop chip"
    so take the best of chip pointed at laptops. I took this to mean latest
    i3 or i5 class chips that have integrated graphics.

    Claiming your machine is faster than 95% of laotops is meaningless
    (laptop sold in unitsl laptop sold in revenue, 95% of laptop models, 95%
    of laptops still in use today?

    IIRC they were referring to the past year's laptops.

    IAC, field testing is showing that, yep, the M1 Macs are fast. Imagine
    where the Mx's are going...
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Wednesday, November 25, 2020 13:27:28
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 10:32 a.m., JF Mezei wrote:
    On 2020-11-24 19:12, Stephen Hoffman wrote:

    But Apple explicitely and repeatedy mentioned video editing.

    And maybe perhaps possibly the folks at Apple have run some tests and
    know about the performance?

    The tests that are coming out now show HUGE performance for M1. (Though
    I did spot one with an Intel Mac Mini with external GPU that beat the
    M1, but that is a outlier).

    Apple would have known about performance prior to keynote, and chose
    instead to provide useless graphs that reduced the credibilitty of its claims.

    No. They chose to not bog a marketing presentation down with excess detail.

    Relative performance was what they needed to show and that's what they did.



    A while back, I was blasted here for stating these keynotes are large marketing events airmed at the public, told that no, they are aimed at
    the trade press. If they are aimed at the trade press, that Apple
    should have provided hard comparable performance numbers since they make
    the M1 look really good.

    Cite, please?

    And even if they ARE aimed at the trade press, Apple then knows that the
    trade press will be presenting greater depth as the review the systems.



    And perhaps once you've tried your own tests, you'll know if M1 is
    faster or slower.


    The argument made by Apple apologists was that the M1 required less RAM, hence no problem with only 8GB to do video rendering.

    My contention is that you should show why you believe huge amounts of
    RAM are required.



    Some of the more serious tests I have seen pointed out the gigabytes of page/swap file used during rendering on the 8GB M1 and much less on the
    16GB. :cl pf RAM does impact performance negatively, but because M1 is
    so much faster, it stll outperforms those without paging.

    And yet, you don't post a link to a single one...


    Someone did tests for read/write on the Mini SSD, and found read was
    slightly better, write not as good as on the Intel Mini (so roughly the same). So a machine hindered by paging but that still performs better
    than machines that don't page means the CPU is actually faster than it appears to be.


    "Someone"? Where's the link?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Wednesday, November 25, 2020 13:30:11
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 11:27 a.m., JF Mezei wrote:
    On 2020-11-25 14:03, Jolly Roger wrote:

    Only in the eyes of complete idiots like you who don't understand what
    those graphs actually represent.

    Graphs with ptreyy lines but no scale are meaningless.

    Nope. The show RELATIVE performance.

    I can show you a graph of my speed around Mission in comparison to any
    other car out there without a single number, and you'll still know which
    is faster and by about how much.


    Claiming your machine is faster than 95% of laotops is meaningless
    (laptop sold in unitsl laptop sold in revenue, 95% of laptop models, 95%
    of laptops still in use today?

    95% of laptops seen during a short survey at a Delta gate at some airpoirt?

    Cosnidering the M1 is faster than many desktops, Apple should have
    provided hard numbers to really show it with a huge bang, instead of meaningless "Reality distortion field" marketing gobbledeegook.

    Why?

    Done this way, they get the good buzz from the event, followed by even
    more buzz as the press does the benchmarks and raves about how fast the machines are.

    Seems pretty clever to me.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Siri Cruise@chine.bleu@yahoo.com to comp.sys.mac.system on Wednesday, November 25, 2020 19:46:16
    From Newsgroup: comp.sys.mac.system

    In article <rpmid3$5qa$2@dont-email.me>,
    Alan Baker <notonyourlife@no.no.no.no> wrote:

    Graphs with ptreyy lines but no scale are meaningless.

    Nope. The show RELATIVE performance.

    Performance is only part of why people buy computers. Based on
    the PPC emulator history I cannot trust Apple to maintain the X86
    emulator indefinitely. So the question becomes whether I am okay
    with being forced to replace useful software like I did with
    Illustrator and Photoshop. Some people like being able to boot
    the same hardware to Linux. Et cetera.

    Absolute performance has to be enough to justify other costs.

    --
    :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
    'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \
    I am an Andrea Doria sockpuppet. insults Islam. Mohammed
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Siri Cruise@chine.bleu@yahoo.com to comp.sys.mac.system on Wednesday, November 25, 2020 19:47:47
    From Newsgroup: comp.sys.mac.system

    In article <rpmi80$5qa$1@dont-email.me>,
    Alan Baker <notonyourlife@no.no.no.no> wrote:

    And even if they ARE aimed at the trade press, Apple then knows that the trade press will be presenting greater depth as the review the systems.

    And will you be so vehemently defending Apple in the trade press
    as you are on usenet?

    --
    :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
    'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \
    I am an Andrea Doria sockpuppet. insults Islam. Mohammed
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Wednesday, November 25, 2020 20:15:10
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 7:47 p.m., Siri Cruise wrote:
    In article <rpmi80$5qa$1@dont-email.me>,
    Alan Baker <notonyourlife@no.no.no.no> wrote:

    And even if they ARE aimed at the trade press, Apple then knows that the
    trade press will be presenting greater depth as the review the systems.

    And will you be so vehemently defending Apple in the trade press
    as you are on usenet?


    What defense do the need?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Wednesday, November 25, 2020 20:20:44
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 7:46 p.m., Siri Cruise wrote:
    In article <rpmid3$5qa$2@dont-email.me>,
    Alan Baker <notonyourlife@no.no.no.no> wrote:

    Graphs with ptreyy lines but no scale are meaningless.

    Nope. The show RELATIVE performance.

    Performance is only part of why people buy computers.

    Agreed.

    But I was addressing someone who said nothing could be learned from
    graphs without numbers, so...

    ...what?

    Based on
    the PPC emulator history I cannot trust Apple to maintain the X86
    emulator indefinitely.

    Of course they won't, but they did maintain the first Rosetta from Mac
    OS X Tiger 10.4.1 in June 2005 until the release of Mac OS X Lion on
    July 11, 2011, or more than 6 years, so...

    ..what?

    So the question becomes whether I am okay
    with being forced to replace useful software like I did with
    Illustrator and Photoshop.

    Going off previous form, being "forced" to replace it by 2026, you mean.

    Some people like being able to boot
    the same hardware to Linux. Et cetera.

    Great. Get the Linux developers off their asses and build it for the new architecture.


    Absolute performance has to be enough to justify other costs.

    Costs incurred over FIVE YEARS.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Thursday, November 26, 2020 17:42:06
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 03:46:16 +0000, Siri Cruise said:
    In article <rpmid3$5qa$2@dont-email.me>,
    Alan Baker <notonyourlife@no.no.no.no> wrote:

    Graphs with ptreyy lines but no scale are meaningless.

    Nope. The show RELATIVE performance.

    Performance is only part of why people buy computers. Based on
    the PPC emulator history I cannot trust Apple to maintain the X86
    emulator indefinitely. So the question becomes whether I am okay
    with being forced to replace useful software like I did with
    Illustrator and Photoshop. Some people like being able to boot
    the same hardware to Linux. Et cetera.

    Absolute performance has to be enough to justify other costs.

    You have almost always been able to run Windoze programs on Macs, even
    back in the old 680x0 and PowerPC days.

    The performance of the *current* M1 means running Windoze or Linux even
    under an emulator will be faster than running them on a real
    Intel-based computer. Parallels Desktop and VMWare Fusion have
    announced they are working on new M1-native versions of the software,
    but no release dates yet.

    Windoze is semi-around as an ARM version, but Apple have said it's up
    to Microsloth whether or not it is ever made available for use on Macs.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@Blackhole@entropy.ultimateorg to comp.sys.mac.system on Thursday, November 26, 2020 11:04:11
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 22:46, Siri Cruise wrote:
    In article <rpmid3$5qa$2@dont-email.me>,
    Alan Baker <notonyourlife@no.no.no.no> wrote:

    Graphs with ptreyy lines but no scale are meaningless.

    Nope. The show RELATIVE performance.

    Performance is only part of why people buy computers. Based on
    the PPC emulator history I cannot trust Apple to maintain the X86
    emulator indefinitely. So the question becomes whether I am okay
    with being forced to replace useful software like I did with
    Illustrator and Photoshop. Some people like being able to boot
    the same hardware to Linux. Et cetera.

    I run Linux under Fusion which is more than adequate to my low needs for Linux. (I think I ran Linux once or twice on my Mac in 2020 - an all
    time low. I did install it temporarily on a PC last spring).

    Absolute performance has to be enough to justify other costs.

    Personally I have no use for the first round M1 Macs - unless a
    particular project goes ahead and I'll need a laptop for which I'd get
    the M1/MBA. Heck, I might even get a used intel MBA or MBP for that
    when others succumb to the upgrade urge.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Thursday, November 26, 2020 14:35:10
    From Newsgroup: comp.sys.mac.system

    On 2020-11-25 23:42, Your Name wrote:

    Windoze is semi-around as an ARM version, but Apple have said it's up
    to Microsloth whether or not it is ever made available for use on Macs.

    Not "natively" on the sense that to boot from the SSD, you are required
    to have a signed OS-X version which also works with secure enclave which
    acts as disk controller (doing encryptioo/Ndecryption).

    So you would have to boot OS-X to disable boot code signatire
    verification and enable boot from external drive and then you could boot
    from alternate OS.

    Howeer, Apple proprietary Secure Boot console would require either an
    EFI emulator or that Windows be allowed to support that Secure Boot thing.

    The move away form industry standard architcture (EFI, x86,
    OPCI-express) and to a closed appliance with whatever tech inside Apple
    finds works best may provide grest OS-X/IOS experience, but makes it an applicance instead of a "computer".



    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Thursday, November 26, 2020 11:53:05
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 11:35 a.m., JF Mezei wrote:
    On 2020-11-25 23:42, Your Name wrote:

    Windoze is semi-around as an ARM version, but Apple have said it's up
    to Microsloth whether or not it is ever made available for use on Macs.

    Not "natively" on the sense that to boot from the SSD, you are required
    to have a signed OS-X version which also works with secure enclave which
    acts as disk controller (doing encryptioo/Ndecryption).

    Cite.


    So you would have to boot OS-X to disable boot code signatire
    verification and enable boot from external drive and then you could boot
    from alternate OS.

    Cite.


    Howeer, Apple proprietary Secure Boot console would require either an
    EFI emulator or that Windows be allowed to support that Secure Boot thing.

    Cite.


    The move away form industry standard architcture (EFI, x86,
    OPCI-express) and to a closed appliance with whatever tech inside Apple
    finds works best may provide grest OS-X/IOS experience, but makes it an applicance instead of a "computer".

    Cite.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Thursday, November 26, 2020 21:05:26
    From Newsgroup: comp.sys.mac.system

    In message <OrTvH.65736$J92.5382@fx48.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-25 23:42, Your Name wrote:

    Windoze is semi-around as an ARM version, but Apple have said it's up
    to Microsloth whether or not it is ever made available for use on Macs.

    Not "natively" on the sense that to boot from the SSD, you are required
    to have a signed OS-X version which also works with secure enclave which
    acts as disk controller (doing encryptioo/Ndecryption).

    You are, of course, wrong. I know this will come as a shock to you.

    Howeer, Apple proprietary Secure Boot console would require either an
    EFI emulator or that Windows be allowed to support that Secure Boot thing.

    No, you're making up idiotic shit again.

    The move away form industry standard architcture (EFI, x86,
    OPCI-express) and to a closed appliance with whatever tech inside Apple
    finds works best may provide grest OS-X/IOS experience, but makes it an applicance instead of a "computer".

    We will celebrate when you leave these groups to go infect whatever you
    think a real computer's groups instead of spreading your idiocy here.


    --
    Hello Diane, I'm Bucky Goldstein
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Siri Cruise@chine.bleu@yahoo.com to comp.sys.mac.system on Thursday, November 26, 2020 13:15:35
    From Newsgroup: comp.sys.mac.system

    In article <OrTvH.65736$J92.5382@fx48.iad>,
    JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    The move away form industry standard architcture (EFI, x86,
    OPCI-express) and to a closed appliance with whatever tech inside Apple
    finds works best may provide grest OS-X/IOS experience, but makes it an applicance instead of a "computer".

    I've dealt with CDC 6600, IBM 360, Cyber 170, MC 6800, IBM PPC,
    and a few others. A Cyber 170 could act as a heater, but that was
    not its usual function. I have different view on what is a
    computer and operating system.

    --
    :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
    'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \
    I am an Andrea Doria sockpuppet. insults Islam. Mohammed
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@Blackhole@entropy.ultimateorg to comp.sys.mac.system on Thursday, November 26, 2020 18:58:00
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 14:35, JF Mezei wrote:

    The move away form industry standard architcture (EFI, x86,
    OPCI-express) and to a closed appliance with whatever tech inside Apple
    finds works best may provide grest OS-X/IOS experience, but makes it an applicance instead of a "computer".

    Rubbish.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Thursday, November 26, 2020 20:10:54
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 14:53, Alan Baker wrote:

    Not "natively" on the sense that to boot from the SSD, you are required
    to have a signed OS-X version which also works with secure enclave which
    acts as disk controller (doing encryptioo/Ndecryption).

    Cite.

    Do you deny that Apple stated that Secure Boot on Macs will
    requiresigned OS to boot (unless disabled)?

    If you deny the obvious, the onus is on you to provide cite.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Thursday, November 26, 2020 20:14:37
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 18:58, Alan Browne wrote:

    Rubbish.


    So you still call it a destop if you can't change/upgrade RAM, can't change/upgrade disk?

    do you call your iPhoen and iPads computers? Apple's desktops are
    becoming functionally equivalent fixed-config appliances.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Friday, November 27, 2020 14:18:22
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 23:58:00 +0000, Alan Browne said:
    On 2020-11-26 14:35, JF Mezei wrote:

    The move away form industry standard architcture (EFI, x86,
    OPCI-express) and to a closed appliance with whatever tech inside Apple
    finds works best may provide grest OS-X/IOS experience, but makes it an
    applicance instead of a "computer".

    Rubbish.

    When the original Mac was released, "expert" fools whinged that it and
    it's graphical interface was just a toy and passing fad ... now the
    majority either has a Mac or wants one (to escape Windoze Hell) and
    every computer comes with a graphical interface.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Thursday, November 26, 2020 17:20:07
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 5:10 p.m., JF Mezei wrote:
    On 2020-11-26 14:53, Alan Baker wrote:

    Not "natively" on the sense that to boot from the SSD, you are required
    to have a signed OS-X version which also works with secure enclave which >>> acts as disk controller (doing encryptioo/Ndecryption).

    Cite.

    Do you deny that Apple stated that Secure Boot on Macs will
    requiresigned OS to boot (unless disabled)?

    I demand that you provide a cite in support of YOUR claim.


    If you deny the obvious, the onus is on you to provide cite.

    Nope.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Thursday, November 26, 2020 20:21:43
    From Newsgroup: comp.sys.mac.system

    In article <1qYvH.33104$Uz.9966@fx46.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    So you still call it a destop if you can't change/upgrade RAM, can't change/upgrade disk?

    that's not what defines a desktop or laptop or mobile device.

    do you call your iPhoen and iPads computers?

    both are computers that fit in a pocket and more powerful than the
    desktops that used to sit on people's desks not that long ago (and in
    some cases, today).

    Apple's desktops are
    becoming functionally equivalent fixed-config appliances.

    some are and some aren't.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Thursday, November 26, 2020 17:23:11
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 5:14 p.m., JF Mezei wrote:
    On 2020-11-26 18:58, Alan Browne wrote:

    Rubbish.


    So you still call it a destop if you can't change/upgrade RAM, can't change/upgrade disk?


    I still call it a computer.

    do you call your iPhoen and iPads computers?

    Nope, but only because terms have come into common parlance for each.

    "Smartphone" and "tablet"



    Apple's desktops are
    becoming functionally equivalent fixed-config appliances.

    None of them are "fixed-config". Not being able to change HARDWARE
    doesn't make them "fixed-config".
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Thursday, November 26, 2020 17:25:38
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 5:14 p.m., JF Mezei wrote:
    On 2020-11-26 18:58, Alan Browne wrote:

    Rubbish.


    So you still call it a destop if you can't change/upgrade RAM, can't change/upgrade disk?

    More tell is what you clipped of what YOU have already said:

    'but makes it an applicance instead of a "computer".'

    Are you seriously contending that a computer is NOT a computer unless
    you can upgrade a hardware component?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Siri Cruise@chine.bleu@yahoo.com to comp.sys.mac.system on Thursday, November 26, 2020 17:41:47
    From Newsgroup: comp.sys.mac.system

    In article <rppk4r$12bf$1@gioia.aioe.org>,
    Your Name <YourName@YourISP.com> wrote:

    On 2020-11-26 23:58:00 +0000, Alan Browne said:
    On 2020-11-26 14:35, JF Mezei wrote:

    The move away form industry standard architcture (EFI, x86,
    OPCI-express) and to a closed appliance with whatever tech inside Apple
    finds works best may provide grest OS-X/IOS experience, but makes it an
    applicance instead of a "computer".

    Rubbish.

    When the original Mac was released, "expert" fools whinged that it and
    it's graphical interface was just a toy and passing fad ... now the
    majority either has a Mac or wants one (to escape Windoze Hell) and
    every computer comes with a graphical interface.

    Gimme back my DSD, DIS, and O26! http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/

    3300. Now that was a real computer. Algol 60 and everything.

    --
    :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
    'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \
    I am an Andrea Doria sockpuppet. insults Islam. Mohammed
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Friday, November 27, 2020 04:05:00
    From Newsgroup: comp.sys.mac.system

    In message <ymYvH.221577$gR8.74250@fx45.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-26 14:53, Alan Baker wrote:

    Not "natively" on the sense that to boot from the SSD, you are required
    to have a signed OS-X version which also works with secure enclave which >>> acts as disk controller (doing encryptioo/Ndecryption).

    Cite.

    Do you deny that Apple stated that Secure Boot on Macs will
    requiresigned OS to boot (unless disabled)?

    That is not what you said though, is it? No, it is not.


    --
    Kid 1: What are the four horsemen of the apocalypse?
    Dad: War, death, famine and pestilence.
    Kid 2: You forgot flatulence!
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 27, 2020 00:51:30
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 23:05, Lewis wrote:

    Do you deny that Apple stated that Secure Boot on Macs will
    requiresigned OS to boot (unless disabled)?

    That is not what you said though, is it? No, it is not.



    I stated you require OS-X on the machine because of Secure Boot signing
    the boot process. (until disabled and you enable booting from external
    disk).

    Was told this was false. Asked to confirm, and now you move goalposts
    instead of admitting you were wrong in saying I was wrong.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Friday, November 27, 2020 06:41:18
    From Newsgroup: comp.sys.mac.system

    In message <Ct0wH.36359$sW6.771@fx47.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-26 23:05, Lewis wrote:

    Do you deny that Apple stated that Secure Boot on Macs will
    requiresigned OS to boot (unless disabled)?

    That is not what you said though, is it? No, it is not.

    I stated you require OS-X on the machine because of Secure Boot signing
    the boot process. (until disabled and you enable booting from external
    disk).

    Which is as incorrect now as the first time you said it.

    Was told this was false. Asked to confirm, and now you move goalposts
    instead of admitting you were wrong in saying I was wrong.

    You were wrong. You are still wrong.

    LEARN TO FUCKING READ.

    ALL THE WORDS.


    --
    Say, give it up, give it up, television's taking its toll That's
    enough, that's enough, gimme the remote control I've been nice,
    I've been good, please don't do this to me Turn it off, turn it
    off, I don't want to have to see
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Friday, November 27, 2020 19:42:38
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 01:25:38 +0000, Alan Baker said:
    On 2020-11-26 5:14 p.m., JF Mezei wrote:
    On 2020-11-26 18:58, Alan Browne wrote:

    Rubbish.

    So you still call it a destop if you can't change/upgrade RAM, can't
    change/upgrade disk?

    More tell is what you clipped of what YOU have already said:

    'but makes it an applicance instead of a "computer".'

    Are you seriously contending that a computer is NOT a computer unless
    you can upgrade a hardware component?

    It hasn't been possible to upgrade the internals of most Macs for quite
    some time ... that trend started well before the Apple Silicon
    computers were even a twinkle of a dream.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Thursday, November 26, 2020 23:28:26
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 9:51 p.m., JF Mezei wrote:
    On 2020-11-26 23:05, Lewis wrote:

    Do you deny that Apple stated that Secure Boot on Macs will
    requiresigned OS to boot (unless disabled)?

    That is not what you said though, is it? No, it is not.



    I stated you require OS-X on the machine because of Secure Boot signing
    the boot process. (until disabled and you enable booting from external
    disk).

    You stating it means (if anything) it is LESS likely to be true.


    Was told this was false. Asked to confirm, and now you move goalposts
    instead of admitting you were wrong in saying I was wrong.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Thursday, November 26, 2020 23:29:51
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 10:42 p.m., Your Name wrote:
    On 2020-11-27 01:25:38 +0000, Alan Baker said:
    On 2020-11-26 5:14 p.m., JF Mezei wrote:
    On 2020-11-26 18:58, Alan Browne wrote:

    Rubbish.

    So you still call it a destop if you can't change/upgrade RAM, can't
    change/upgrade disk?

    More tell is what you clipped of what YOU have already said:

    'but makes it an applicance instead of a "computer".'

    Are you seriously contending that a computer is NOT a computer unless
    you can upgrade a hardware component?

    It hasn't been possible to upgrade the internals of most Macs for quite
    some time ... that trend started well before the Apple Silicon computers were even a twinkle of a dream.


    /I/ never said anything to the contrary.

    It is obvious to anyone of even very modest intelligence that whether or
    not a personal computer IS a personal computer is not in any way
    dependent upon whether or not you can change a single piece of hardware
    in it.

    That's all I was saying.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 27, 2020 02:40:38
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 01:42, Your Name wrote:

    It hasn't been possible to upgrade the internals of most Macs for quite
    some time ... that trend started well before the Apple Silicon
    computers were even a twinkle of a dream.


    But you could still install any operating system on it. The introduction
    of T2 and now Secure Enclave makes that much harder and makes built-in
    drive unusable for such endeavour.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Thursday, November 26, 2020 23:58:17
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 11:40 p.m., JF Mezei wrote:
    On 2020-11-27 01:42, Your Name wrote:

    It hasn't been possible to upgrade the internals of most Macs for quite
    some time ... that trend started well before the Apple Silicon
    computers were even a twinkle of a dream.


    But you could still install any operating system on it. The introduction
    of T2 and now Secure Enclave makes that much harder and makes built-in
    drive unusable for such endeavour.

    Claims for which you provide NO support... ...again.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Friday, November 27, 2020 05:36:26
    From Newsgroup: comp.sys.mac.system

    In article <W32wH.9736$sB6.7356@fx34.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    But you could still install any operating system on it. The introduction
    of T2 and now Secure Enclave makes that much harder

    only slightly

    and makes built-in
    drive unusable for such endeavour.

    false
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Friday, November 27, 2020 10:23:40
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 20:14, JF Mezei wrote:
    On 2020-11-26 18:58, Alan Browne wrote:

    Rubbish.


    So you still call it a destop if you can't change/upgrade RAM, can't change/upgrade disk?

    do you call your iPhoen and iPads computers? Apple's desktops are

    Yes, iPhones and iPads are definitely, without contest, computers. I
    can load whatever s/w I like on them and I can write my own s/w for them
    if need be (no need at present).

    becoming functionally equivalent fixed-config appliances.

    Not at all. Just because the configuration is pretty much fixed from
    the start, that has been the trend for 3 decades: functions that used to require an expansion card slot became part of the motherboard. Now
    these functions are becoming part of the SOC.

    It remains to be seen how the next round of Macs will go. We may see iMacs/Pros that have user memory expansion for example. Possibly even
    GPU's - though I suspect Apple are not going there...

    And of course this doesn't prevent anyone from adding peripherals via
    the USB (Thunderbold) ports.

    You're making stuff up because the rest of your statements are falling
    to pieces. Or because you're very unsatisfied with your recent CPU
    upgrade to your Mac Pro.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Friday, November 27, 2020 10:34:36
    From Newsgroup: comp.sys.mac.system

    On 2020-11-26 20:18, Your Name wrote:
    On 2020-11-26 23:58:00 +0000, Alan Browne said:
    On 2020-11-26 14:35, JF Mezei wrote:

    The move away form industry standard architcture (EFI, x86,
    OPCI-express) and to a closed appliance with whatever tech inside Apple
    finds works best may provide grest OS-X/IOS experience, but makes it an
    applicance instead of a "computer".

    Rubbish.

    When the original Mac was released, "expert" fools whinged that it and
    it's graphical interface was just a toy and passing fad ... now the
    majority either has a Mac or wants one (to escape Windoze Hell) and
    every computer comes with a graphical interface.

    Not that many people are escaping Windows. It is the most used OS in
    the world by far. Your denigration of it aside. Indeed many of Apple's
    own client facing servers were run under Windows Azure in the past (as
    well as other OS' from IBM/AIX to various nix'). Not sure currently.

    Apple has a pretty good slice of the US PC market however, but still
    deep in the minority for desk/laptop.

    Per recent web stats, Mac OS' were up to about 17% which is quite high v
    the last 20 years - a lot of that growth is US uptake - where Mac OS is
    near 30%.

    Linux has fallen into the less than 2% range in the meantime.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Friday, November 27, 2020 18:07:42
    From Newsgroup: comp.sys.mac.system

    In message <W32wH.9736$sB6.7356@fx34.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-27 01:42, Your Name wrote:

    It hasn't been possible to upgrade the internals of most Macs for quite
    some time ... that trend started well before the Apple Silicon
    computers were even a twinkle of a dream.


    But you could still install any operating system on it. The introduction
    of T2 and now Secure Enclave makes that much harder

    Very slightly and minorly harder. It takes a minute, at most.

    and makes built-in drive unusable for such endeavour.

    Bullshit.



    --
    Hey, how come Andrew gets to get up? If he gets up, we'll all get up!
    It'll be anarchy!
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Saturday, November 28, 2020 10:18:37
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 07:29:51 +0000, Alan Baker said:
    On 2020-11-26 10:42 p.m., Your Name wrote:
    On 2020-11-27 01:25:38 +0000, Alan Baker said:
    On 2020-11-26 5:14 p.m., JF Mezei wrote:
    On 2020-11-26 18:58, Alan Browne wrote:

    Rubbish.

    So you still call it a destop if you can't change/upgrade RAM, can't
    change/upgrade disk?

    More tell is what you clipped of what YOU have already said:

    'but makes it an applicance instead of a "computer".'

    Are you seriously contending that a computer is NOT a computer unless
    you can upgrade a hardware component?

    It hasn't been possible to upgrade the internals of most Macs for quite
    some time ... that trend started well before the Apple Silicon
    computers were even a twinkle of a dream.

    /I/ never said anything to the contrary.

    It is obvious to anyone of even very modest intelligence that whether
    or not a personal computer IS a personal computer is not in any way dependent upon whether or not you can change a single piece of hardware
    in it.

    That's all I was saying.

    I was agreeing with you. I just forgot to put "Yep" at the start. :-)


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Saturday, November 28, 2020 10:24:52
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 07:58:17 +0000, Alan Baker said:
    On 2020-11-26 11:40 p.m., JF Mezei wrote:
    On 2020-11-27 01:42, Your Name wrote:

    It hasn't been possible to upgrade the internals of most Macs for quite
    some time ... that trend started well before the Apple Silicon
    computers were even a twinkle of a dream.

    But you could still install any operating system on it. The introduction
    of T2 and now Secure Enclave makes that much harder and makes built-in
    drive unusable for such endeavour.

    Claims for which you provide NO support... ...again.

    *YEP*, ;-)
    Claims about devices that have only just been released and nobody has
    had a good time to play with yet.

    The reality is that there aren't many other ARM-based OSes that are
    worth using, so if you want Windows, Linux, etc. you're likely going to
    be using emulation anyway. ARM-Windoze, for example as it's most widely
    used, is mostly reported as being horrible, so you'll be better off
    with Parallels / VMWare and normal Windoze 10 ... given the power /
    speed increase of the M1 it's likely such emulation will be around the
    same speed, if not faster, than running those OSes natively in the
    first place.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Friday, November 27, 2020 13:49:13
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 1:18 p.m., Your Name wrote:
    On 2020-11-27 07:29:51 +0000, Alan Baker said:
    On 2020-11-26 10:42 p.m., Your Name wrote:
    On 2020-11-27 01:25:38 +0000, Alan Baker said:
    On 2020-11-26 5:14 p.m., JF Mezei wrote:
    On 2020-11-26 18:58, Alan Browne wrote:

    Rubbish.

    So you still call it a destop if you can't change/upgrade RAM, can't >>>>> change/upgrade disk?

    More tell is what you clipped of what YOU have already said:

    'but makes it an applicance instead of a "computer".'

    Are you seriously contending that a computer is NOT a computer
    unless you can upgrade a hardware component?

    It hasn't been possible to upgrade the internals of most Macs for
    quite some time ... that trend started well before the Apple Silicon
    computers were even a twinkle of a dream.

    /I/ never said anything to the contrary.

    It is obvious to anyone of even very modest intelligence that whether
    or not a personal computer IS a personal computer is not in any way
    dependent upon whether or not you can change a single piece of
    hardware in it.

    That's all I was saying.

    I was agreeing with you. I just forgot to put "Yep" at the start.  :-)



    No worries. ;-)
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 27, 2020 19:30:08
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 02:58, Alan Baker wrote:

    Claims for which you provide NO support... ...again.

    I'll ask again.
    Do you deny that Apple uses its Secure Boot console on M1 based Maxs?

    Do you deny that Secure Boot does code signature to boot only an OS that
    is signed by Apple (unless disabled after booting into OS-X).

    Do you deny that the Secure Enclave in M1 acts as controller for all
    access to the 1 drive inside the machine and that it coperates wurg S to authorize access and perform encryotioN/decryption of data like it does
    with IOS ?

    All these were stated during keynote.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 27, 2020 19:37:49
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 10:23, Alan Browne wrote:

    Yes, iPhones and iPads are definitely, without contest, computers. I
    can load whatever s/w I like on them and I can write my own s/w for them
    if need be (no need at present).

    Whatever software you like? Only possible if you jailbreak the iPhone
    and side-load via Cydia. Otherwise, you only have access to app curated
    by Apple on the App store.


    And of course this doesn't prevent anyone from adding peripherals via
    the USB (Thunderbold) ports.

    Assuming OS-X supports such peripherals. Note: M1 version of OS-X does
    not support external GPUs.

    You need to go through hoops to allow booting from external drive which
    is disable by default.


    You're making stuff up because the rest of your statements are falling
    to pieces. Or because you're very unsatisfied with your recent CPU
    upgrade to your Mac Pro.


    Your logic is astounding. Why would I be unsatisfied going from 4 to 10
    cores, 10MB to 25MB cache? Render times when either Premiere or After
    Effects makes full use of cores are hugely shorter.



    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Friday, November 27, 2020 20:10:45
    From Newsgroup: comp.sys.mac.system

    In article <kSgwH.15868$nc.2114@fx19.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    I'll ask again.

    don't.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Friday, November 27, 2020 20:10:47
    From Newsgroup: comp.sys.mac.system

    In article <xZgwH.11709$Zh7.236@fx04.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    Yes, iPhones and iPads are definitely, without contest, computers. I
    can load whatever s/w I like on them and I can write my own s/w for them if need be (no need at present).

    Whatever software you like? Only possible if you jailbreak the iPhone
    and side-load via Cydia. Otherwise, you only have access to app curated
    by Apple on the App store.

    false.

    And of course this doesn't prevent anyone from adding peripherals via
    the USB (Thunderbold) ports.

    Assuming OS-X supports such peripherals. Note: M1 version of OS-X does
    not support external GPUs.

    for now.

    you do realize that these are the *first* apple silicon macs and in no
    way defines what future macs will or will not support, right?

    You need to go through hoops to allow booting from external drive which
    is disable by default.

    a very, very small hoop.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Friday, November 27, 2020 17:21:27
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 4:30 p.m., JF Mezei wrote:
    On 2020-11-27 02:58, Alan Baker wrote:

    Claims for which you provide NO support... ...again.

    I'll ask again.

    And I will say again.

    Do you deny that Apple uses its Secure Boot console on M1 based Maxs?

    It is YOUR JOB to support YOUR CLAIMS.


    Do you deny that Secure Boot does code signature to boot only an OS that
    is signed by Apple (unless disabled after booting into OS-X).

    Do you deny that the Secure Enclave in M1 acts as controller for all
    access to the 1 drive inside the machine and that it coperates wurg S to authorize access and perform encryotioN/decryption of data like it does
    with IOS ?

    All these were stated during keynote.

    Time codes, please.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Friday, November 27, 2020 17:27:36
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 4:37 p.m., JF Mezei wrote:
    On 2020-11-27 10:23, Alan Browne wrote:

    Yes, iPhones and iPads are definitely, without contest, computers. I
    can load whatever s/w I like on them and I can write my own s/w for them
    if need be (no need at present).

    Whatever software you like? Only possible if you jailbreak the iPhone
    and side-load via Cydia. Otherwise, you only have access to app curated
    by Apple on the App store.

    That changes literally nothing.



    And of course this doesn't prevent anyone from adding peripherals via
    the USB (Thunderbold) ports.

    Assuming OS-X supports such peripherals. Note: M1 version of OS-X does
    not support external GPUs.


    Are you claiming that macOS doesn't support Thunderbolt peripherals
    (aside from eGPUs)?

    You need to go through hoops to allow booting from external drive which
    is disable by default.

    Cite, please.



    You're making stuff up because the rest of your statements are falling
    to pieces. Or because you're very unsatisfied with your recent CPU
    upgrade to your Mac Pro.


    Your logic is astounding. Why would I be unsatisfied going from 4 to 10 cores, 10MB to 25MB cache? Render times when either Premiere or After Effects makes full use of cores are hugely shorter.

    Cite, please.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 27, 2020 22:34:53
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 20:10, nospam wrote:

    you do realize that these are the *first* apple silicon macs and in no
    way defines what future macs will or will not support, right?

    Yes I realize. But I am responding to your ilk's statements that 8GB is
    plenty because M1 doesn't need as much memory, and that closed systems
    that can't get any upgrade are fine, that built-in GPUs are fine and
    you'll never need more power etc etc etc.

    The issue is is that **IF** the M1 chip is the shape of things to come
    in terms of having truly everything in one chip, this poses some
    challenges that ask questions on how Apple will scale it to span all the
    way up to Mac Pro.

    If Apple will break out of the chip for higher end models, then we'll
    see what happens.

    You need to go through hoops to allow booting from external drive which
    is disable by default.

    a very, very small hoop.

    It still makes the built-in SSD useless because accessed via Secure
    Enclare, can't be replaced except bu apple (and they'll likely refuse
    because soldered in etc).



    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 28, 2020 03:40:08
    From Newsgroup: comp.sys.mac.system

    In message <xZgwH.11709$Zh7.236@fx04.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-27 10:23, Alan Browne wrote:

    Yes, iPhones and iPads are definitely, without contest, computers. I
    can load whatever s/w I like on them and I can write my own s/w for them
    if need be (no need at present).

    Whatever software you like? Only possible if you jailbreak the iPhone

    No.

    and side-load via Cydia. Otherwise, you only have access to app curated
    by Apple on the App store.

    No, that is horseshit. The VAST majority of software for iOS is not
    created by Apple, how stupid are you?

    You need to go through hoops to allow booting from external drive which
    is disable by default.

    Oh noes! You have to TOGGLE A PREFERENCE! It is SOOOO COMPLICATED.

    You're making stuff up because the rest of your statements are falling
    to pieces. Or because you're very unsatisfied with your recent CPU
    upgrade to your Mac Pro.


    Your logic is astounding. Why would I be unsatisfied going from 4 to 10 cores, 10MB to 25MB cache?

    Because a $700 machine kicks your current machine's ass?

    --
    Boy, it sure would be nice if we had some grenades, don'tcha think?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Friday, November 27, 2020 22:41:39
    From Newsgroup: comp.sys.mac.system


    Cite, please.



    https://support.apple.com/en-gb/HT208198

    https://support.apple.com/en-ca/guide/macbook-pro/apdcf567823b/mac
    Secure boot and Startup Security Utility: Support for secure boot is
    turned on automatically. It’s designed to verify that the operating
    system software loaded on your computer at startup is authorized by
    Apple. See the Apple Support article About Secure Boot.



    Note the "authorized by Apple".
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Friday, November 27, 2020 20:00:34
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 7:34 p.m., JF Mezei wrote:
    On 2020-11-27 20:10, nospam wrote:

    you do realize that these are the *first* apple silicon macs and in no
    way defines what future macs will or will not support, right?

    Yes I realize. But I am responding to your ilk's statements that 8GB is plenty because M1 doesn't need as much memory, and that closed systems
    that can't get any upgrade are fine, that built-in GPUs are fine and
    you'll never need more power etc etc etc.

    And to this point, you have yet to produce any countering references...


    The issue is is that **IF** the M1 chip is the shape of things to come
    in terms of having truly everything in one chip, this poses some
    challenges that ask questions on how Apple will scale it to span all the
    way up to Mac Pro.

    No. It really doesn't.


    If Apple will break out of the chip for higher end models, then we'll
    see what happens.

    You need to go through hoops to allow booting from external drive which
    is disable by default.

    a very, very small hoop.

    It still makes the built-in SSD useless because accessed via Secure
    Enclare, can't be replaced except bu apple (and they'll likely refuse
    because soldered in etc).

    Cite.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Friday, November 27, 2020 20:24:06
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 7:41 p.m., JF Mezei wrote:

    Cite, please.



    https://support.apple.com/en-gb/HT208198

    https://support.apple.com/en-ca/guide/macbook-pro/apdcf567823b/mac
    Secure boot and Startup Security Utility: Support for secure boot is
    turned on automatically. It’s designed to verify that the operating
    system software loaded on your computer at startup is authorized by
    Apple. See the Apple Support article About Secure Boot.



    Note the "authorized by Apple".


    "See the Apple Support article About Secure Boot."

    OK. Let's do that!

    <https://support.apple.com/en-us/HT208198>


    'No Security
    No Security doesn't enforce any of the above security requirements for
    your startup disk.'

    You lose.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 28, 2020 05:34:20
    From Newsgroup: comp.sys.mac.system

    In message <TFjwH.14267$vhX.1265@fx17.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    Cite, please.



    https://support.apple.com/en-gb/HT208198

    https://support.apple.com/en-ca/guide/macbook-pro/apdcf567823b/mac
    Secure boot and Startup Security Utility: Support for secure boot is
    turned on automatically. It’s designed to verify that the operating
    system software loaded on your computer at startup is authorized by
    Apple. See the Apple Support article About Secure Boot.

    And disabling it is literally a single check box, as is shown in that
    same exact HT.

    --
    "If this was a dictatorship it would be a lot easier; as long as I
    was the dictator." -- George W Bush
    "Hold my beer" -- Donald Trump
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Saturday, November 28, 2020 00:47:58
    From Newsgroup: comp.sys.mac.system

    In article <yzjwH.30512$se1.852@fx27.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    you do realize that these are the *first* apple silicon macs and in no
    way defines what future macs will or will not support, right?

    Yes I realize. But I am responding to your ilk's statements that 8GB is plenty because M1 doesn't need as much memory,

    they do not. that is a well established fact.

    and that closed systems
    that can't get any upgrade are fine,

    apple and many other companies have been shipping systems that can't be upgraded because users rarely upgrade, plus the advantages of unified
    memory on the chip blow away any benefit of being able to upgrade it.

    that built-in GPUs are fine

    the built in gpu is outperforming many discrete gpus with a *lot* less
    power. keep in mind these are low end systems.

    and
    you'll never need more power etc etc etc.

    nobody said that.

    The issue is is that **IF** the M1 chip is the shape of things to come
    in terms of having truly everything in one chip, this poses some
    challenges that ask questions on how Apple will scale it to span all the
    way up to Mac Pro.

    it's the shape of things in the very first models.

    what future models may bring is unknown, however, it's not that hard to
    figure out based on industry trends.

    If Apple will break out of the chip for higher end models, then we'll
    see what happens.

    we will see what they do in the future, but you'll get it all wrong and
    argue.

    You need to go through hoops to allow booting from external drive which
    is disable by default.

    a very, very small hoop.

    It still makes the built-in SSD useless because accessed via Secure
    Enclare, can't be replaced except bu apple (and they'll likely refuse
    because soldered in etc).

    more nonsense. where did you get the idea the built in ssd is useless
    when booting from an external drive?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 28, 2020 05:49:19
    From Newsgroup: comp.sys.mac.system

    In message <rpsi12$7v3$3@dont-email.me> Alan Baker <notonyourlife@no.no.no.no> wrote:
    On 2020-11-27 7:34 p.m., FUDMiester wrote:
    The issue is is that **IF** the M1 chip is the shape of things to come
    in terms of having truly everything in one chip, this poses some
    challenges that ask questions on how Apple will scale it to span all the
    way up to Mac Pro.

    No. It really doesn't.

    You have to understand that not only is JF a champion FUD spreader who
    frames everything he says so as to project the worst possibilities in all things, he is also so stupid that he thinks everyone else, and
    especially Apple, is even stupider.

    So he honestly believes that Apple has switched their platform to a new
    chip and has NO IDEA how they will release machines over the next 2
    years that will be any faster or better than the $700 Mac mini they just released.

    He has referred to Apple and to hundreds of people who have received the
    M1 machines as either liars or stupidly misguided or paid off
    accomplices in a conspiracy to make the M1 Mac appear better than they
    are.

    He has insisted that he knows more about chip design and how chips work
    that the best team of chip designers in the world.

    He continues to deny that the M1 machines can process 4K video better
    than his 7 year old machine, despite many people showing the performance
    is equal or nearly equal to current top-end iMac Pros.

    Jason Snell recently discussed running a de-noiser tool on his M1 mac.
    This tool is the reason he purchased a 10 core iMac Pro, and the tool
    maxes out the iMac. The iMac is faster, but only a bit. And the
    de-noiser is running in Rosetta.

    JF has done this sort of shit before, and he will do it again. On any
    topic JF will e sure to have a dogmatic opinion based on ignorance, misunderstanding, or simply outdated information. He will ignore all
    evidence that counter his fervently held dogma, and will go to the
    extent of lying repeatedly or willfully ignoring explicit proof he is
    wrong (like his posting the link to the HT that proved his claim it was "difficult" to bypass secure boot was literally a single check).

    The stupid runs deep.

    --
    What beep from yonder speaker sounds?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Saturday, November 28, 2020 19:15:42
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 03:40:08 +0000, Lewis said:
    In message <xZgwH.11709$Zh7.236@fx04.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-27 10:23, Alan Browne wrote:
    Yes, iPhones and iPads are definitely, without contest, computers. I
    can load whatever s/w I like on them and I can write my own s/w for them >>> if need be (no need at present).

    Whatever software you like? Only possible if you jailbreak the iPhone

    No.

    and side-load via Cydia. Otherwise, you only have access to app curated
    by Apple on the App store.

    No, that is horseshit. The VAST majority of software for iOS is not
    created by Apple, how stupid are you?

    It says "curated" not "created". :-)

    Apple does veto apps on the App Store under they own set of rules ...
    and when you look at the awful mess on the Google Play store (let alone elsewhere for Android apps), you thank your God / lucky stars / whoever
    that they do!

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Saturday, November 28, 2020 01:51:12
    From Newsgroup: comp.sys.mac.system

    In article <rpspue$eqr$1@gioia.aioe.org>, Your Name
    <YourName@YourISP.com> wrote:

    Apple does veto apps on the App Store under they own set of rules ...
    and when you look at the awful mess on the Google Play store (let alone elsewhere for Android apps), you thank your God / lucky stars / whoever
    that they do!

    google curates the play store.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 28, 2020 08:18:22
    From Newsgroup: comp.sys.mac.system

    In message <281120200151121081%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
    In article <rpspue$eqr$1@gioia.aioe.org>, Your Name
    <YourName@YourISP.com> wrote:

    Apple does veto apps on the App Store under they own set of rules ...
    and when you look at the awful mess on the Google Play store (let alone
    elsewhere for Android apps), you thank your God / lucky stars / whoever
    that they do!

    google curates the play store.

    Every store in existence "curates" their offerings.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 28, 2020 09:10:23
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 19:37, JF Mezei wrote:
    On 2020-11-27 10:23, Alan Browne wrote:

    Yes, iPhones and iPads are definitely, without contest, computers. I
    can load whatever s/w I like on them and I can write my own s/w for them
    if need be (no need at present).

    Whatever software you like? Only possible if you jailbreak the iPhone
    and side-load via Cydia. Otherwise, you only have access to app curated
    by Apple on the App store.

    That it's a walled garden of sorts does not take away from the plain,
    solid, uncontestable fact that they are computers.

    That is fine with me. My iPhone and iPad are "appliances" in the sense
    that I don't spend a lot of effort protecting them (backups) except for
    any music I purchase via them or photos I take. Everything else about
    them is backed up intrinsically.

    Very low maintenance computers.

    And of course this doesn't prevent anyone from adding peripherals via
    the USB (Thunderbold) ports.

    Assuming OS-X supports such peripherals. Note: M1 version of OS-X does
    not support external GPUs.

    I don't do that now and that's not likely to change. Further, as stated
    many times, we have no idea where the higher end Macs will end up and
    the whole notion of external GPU's may become a curiosity for computer museums.

    You need to go through hoops to allow booting from external drive which
    is disable by default.

    Eh? A one time setting to allow it (from recovery mode) then the usual.

    You're making stuff up because the rest of your statements are falling
    to pieces. Or because you're very unsatisfied with your recent CPU
    upgrade to your Mac Pro.


    Your logic is astounding. Why would I be unsatisfied going from 4 to 10 cores, 10MB to 25MB cache? Render times when either Premiere or After Effects makes full use of cores are hugely shorter.

    Well then I'm wrong. But something has to explain your obsession with
    finding something wrong (and doing badly at it) with these Mx based Macs.

    "hugely shorter"? Did you actually write that? Yep. There it is.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 28, 2020 09:17:41
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 22:34, JF Mezei wrote:
    On 2020-11-27 20:10, nospam wrote:

    you do realize that these are the *first* apple silicon macs and in no
    way defines what future macs will or will not support, right?

    Yes I realize. But I am responding to your ilk's statements that 8GB is plenty because M1 doesn't need as much memory, and that closed systems
    that can't get any upgrade are fine, that built-in GPUs are fine and
    you'll never need more power etc etc etc.

    For the vast majority of MBA users 8 GB is ample and they have 0 need
    for external GPU's. For anyone with a doubt about the 8GB being ample
    they can easily double it at selection. This is not rocket science and
    it's definitely not the end where Macs are concerned.

    The issue is is that **IF** the M1 chip is the shape of things to come
    in terms of having truly everything in one chip, this poses some
    challenges that ask questions on how Apple will scale it to span all the
    way up to Mac Pro.

    So stop flapping your arms trying to get lift on a notion that nobody
    knows about. If it isn't clear to you yet, Apple are not aiming low.

    Current Mac Pros go to 1.5 TB of RAM and I doubt Apple will disappoint
    that end of the professional market.

    If Apple will break out of the chip for higher end models, then we'll
    see what happens.

    Stunning conclusion to what everyone's been saying since the M1 roll out
    day. Glad you caught up to that.

    You need to go through hoops to allow booting from external drive which
    is disable by default.

    a very, very small hoop.

    It still makes the built-in SSD useless because accessed via Secure
    Enclare, can't be replaced except bu apple (and they'll likely refuse
    because soldered in etc).

    "Fear is the mind killer."

    I always thought that a little trite, but now...

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Jolly Roger@jollyroger@pobox.com to comp.sys.mac.system on Saturday, November 28, 2020 16:52:20
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28, Lewis <g.kreme@kreme.dont-email.me> wrote:
    In message <rpsi12$7v3$3@dont-email.me> Alan Baker <notonyourlife@no.no.no.no> wrote:
    On 2020-11-27 7:34 p.m., FUDMiester wrote:
    The issue is is that **IF** the M1 chip is the shape of things to
    come in terms of having truly everything in one chip, this poses
    some challenges that ask questions on how Apple will scale it to
    span all the way up to Mac Pro.

    No. It really doesn't.

    You have to understand that not only is JF a champion FUD spreader who
    frames everything he says so as to project the worst possibilities in
    all things, he is also so stupid that he thinks everyone else, and
    especially Apple, is even stupider.

    So he honestly believes that Apple has switched their platform to a
    new chip and has NO IDEA how they will release machines over the next
    2 years that will be any faster or better than the $700 Mac mini they
    just released.

    He has referred to Apple and to hundreds of people who have received
    the M1 machines as either liars or stupidly misguided or paid off
    accomplices in a conspiracy to make the M1 Mac appear better than they
    are.

    He has insisted that he knows more about chip design and how chips
    work that the best team of chip designers in the world.

    He continues to deny that the M1 machines can process 4K video better
    than his 7 year old machine, despite many people showing the
    performance is equal or nearly equal to current top-end iMac Pros.

    Jason Snell recently discussed running a de-noiser tool on his M1 mac.
    This tool is the reason he purchased a 10 core iMac Pro, and the tool
    maxes out the iMac. The iMac is faster, but only a bit. And the
    de-noiser is running in Rosetta.

    JF has done this sort of shit before, and he will do it again. On any
    topic JF will e sure to have a dogmatic opinion based on ignorance, misunderstanding, or simply outdated information. He will ignore all
    evidence that counter his fervently held dogma, and will go to the
    extent of lying repeatedly or willfully ignoring explicit proof he is
    wrong (like his posting the link to the HT that proved his claim it
    was "difficult" to bypass secure boot was literally a single check).

    The stupid runs deep.

    JF and Arleen should definitely get married. They are perfect for each
    other.

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Jolly Roger@jollyroger@pobox.com to comp.sys.mac.system on Saturday, November 28, 2020 16:53:54
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28, Alan Baker <notonyourlife@no.no.no.no> wrote:
    On 2020-11-27 7:41 p.m., JF Mezei wrote:

    Cite, please.

    https://support.apple.com/en-gb/HT208198

    https://support.apple.com/en-ca/guide/macbook-pro/apdcf567823b/mac
    Secure boot and Startup Security Utility: Support for secure boot is
    turned on automatically. It’s designed to verify that the operating
    system software loaded on your computer at startup is authorized by
    Apple. See the Apple Support article About Secure Boot.

    Note the "authorized by Apple".

    "See the Apple Support article About Secure Boot."

    OK. Let's do that!

    <https://support.apple.com/en-us/HT208198>

    'No Security
    No Security doesn't enforce any of the above security requirements for
    your startup disk.'

    You lose.

    "...but I shouldn't have to disable anything!..."

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Jolly Roger@jollyroger@pobox.com to comp.sys.mac.system on Saturday, November 28, 2020 16:54:29
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28, Lewis <g.kreme@kreme.dont-email.me> wrote:
    In message <TFjwH.14267$vhX.1265@fx17.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    Cite, please.

    https://support.apple.com/en-gb/HT208198

    https://support.apple.com/en-ca/guide/macbook-pro/apdcf567823b/mac
    Secure boot and Startup Security Utility: Support for secure boot is
    turned on automatically. It’s designed to verify that the operating
    system software loaded on your computer at startup is authorized by
    Apple. See the Apple Support article About Secure Boot.

    And disabling it is literally a single check box, as is shown in that
    same exact HT.

    BULLSHIT. I was told there would be hoops!

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Sunday, November 29, 2020 10:05:32
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 08:18:22 +0000, Lewis said:
    In message <281120200151121081%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
    In article <rpspue$eqr$1@gioia.aioe.org>, Your Name
    <YourName@YourISP.com> wrote:

    Apple does veto apps on the App Store under they own set of rules ...
    and when you look at the awful mess on the Google Play store (let alone
    elsewhere for Android apps), you thank your God / lucky stars / whoever
    that they do!

    google curates the play store.

    Every store in existence "curates" their offerings.

    Many don't or don't have very good rules. Only recently due to all the "Political Correctness" have some of them even bothered to remove apps
    with thikngs like "hate speech" and "fake news".

    For device like Android and macOS you can download apps from pretty
    much anywhere, whereas for iOS / iPadOS you're limited to *only* the
    Apple App Store (unless you jailbreak the device or have a developer
    account for your own app creations).


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Saturday, November 28, 2020 21:18:42
    From Newsgroup: comp.sys.mac.system

    I ran a 6 hour YouTube stream recorded in 1080p through the beta
    handbrake M1 version.

    First, in hardware mode it ran at 177fos, not at all surprising.

    In software mode converting to 1080p "Fast" preset, the fps of the
    conversion dropped at times to as low as 68fps for a few seconds, but
    most of the time it was between 85-105fps with occasional peaks as high
    as 122fps.

    At the same time, I was using the system the entire time and noticed no
    lagging at all.

    --
    At 20:43 the dome of St. Elvis Cathedral shattered... and the Devil
    walked the earth again. He'd never really left.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 28, 2020 16:33:30
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 16:18, Lewis wrote:
    I ran a 6 hour YouTube stream recorded in 1080p through the beta
    handbrake M1 version.

    First, in hardware mode it ran at 177fos, not at all surprising.

    In software mode converting to 1080p "Fast" preset, the fps of the
    conversion dropped at times to as low as 68fps for a few seconds, but
    most of the time it was between 85-105fps with occasional peaks as high
    as 122fps.

    At the same time, I was using the system the entire time and noticed no lagging at all.

    MBA or MBP or Mini?

    If the later, did the fans kick?

    With a more pristine source video what fps for conversion to .265 from .264?

    Can you look at the memory config under "about" or "system information"?

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Saturday, November 28, 2020 20:14:23
    From Newsgroup: comp.sys.mac.system

    On 2020-11-27 23:24, Alan Baker wrote:

    'No Security
    No Security doesn't enforce any of the above security requirements for
    your startup disk.'

    You lose.


    In order to get to the menu to disable this, you need to have OS-X, in particular the recovery partition (which is now on an APFS GUID
    partition which contains the AFPS "partition" for recovery).


    On the M1 machines, it isn't clear if the built-in SSD even has a GUID partitioning scheme, it could be native APFS since there is no EFI which required GUID partition for the boot. Good luck installing windows on
    that SSD if it is partitioned APFS natively with no GUID. And you need
    to keep it in order to access that recovery boot menu to disable the
    security (in case some glitch causes it to return).

    Also, still not clear to me whether Linux, even if it supported APFS,
    could run from that SSD since it is controlled by the secure enclave.
    (so you have to boot from external drives).


    You are quick to insult, but nevet provide actual hard information, just marketing gobledeegook.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Saturday, November 28, 2020 20:16:50
    From Newsgroup: comp.sys.mac.system

    In article <PBCwH.42501$sW6.36723@fx47.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    Also, still not clear to me

    nothing ever is
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 01:20:35
    From Newsgroup: comp.sys.mac.system

    In message <KmzwH.23780$PP.20307@fx07.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-28 16:18, Lewis wrote:
    I ran a 6 hour YouTube stream recorded in 1080p through the beta
    handbrake M1 version.

    First, in hardware mode it ran at 177fos, not at all surprising.

    In software mode converting to 1080p "Fast" preset, the fps of the
    conversion dropped at times to as low as 68fps for a few seconds, but
    most of the time it was between 85-105fps with occasional peaks as high
    as 122fps.

    At the same time, I was using the system the entire time and noticed no
    lagging at all.

    MBA or MBP or Mini?

    MBA.

    With a more pristine source video what fps for conversion to .265 from .264?

    I don't have a more pristine video of any size worth testing.

    Can you look at the memory config under "about" or "system information"?

    the MBA has 16GB, though I doubt I needed it.

    Oh, the 6GB video file was remote, but the converted file was written
    locally. I doubt this affected the speed, but it might have cost s few
    FPS.

    Oh, the MBA also got a little warm. A LITTLE warm. Not to warm to set it
    on my bare legs with not even the slightest hint of discomfort, but
    enough to notice it was warm.

    --
    If you have any young friends who aspire to become writers, the
    second-greatest favor you can do them is to present them with
    copies of The Elements of Style. The first-greatest, of course,
    is to shoot them now, while they're happy. -Dorothy Parker
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Saturday, November 28, 2020 20:33:20
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 00:47, nospam wrote:

    Yes I realize. But I am responding to your ilk's statements that 8GB is
    plenty because M1 doesn't need as much memory,

    they do not. that is a well established fact.


    Yet to see any explanation for why applications require less RAM when
    running on ARM/M1 vs x86.

    The folks who got seeds from Apple and did the early benchmarks reported
    only on performance, didn,t report on paging. Later reports do mention
    the paging that happens on the 8GB. The fact that even with paging, the machine outperformas the older Apple laptop based on Intel is even more admirable, but it does not make an "establish fact" that M1 requires
    less memory.


    the built in gpu is outperforming many discrete gpus with a *lot* less
    power. keep in mind these are low end systems.

    The comparisons so far were with the Intel machines with built-in Intel
    GPUs. And yes, the M1 beats the Intel ones easily.


    Another thing to consider is that when you work with a native 4K
    resolution screen, the GPU moves a lot more data. When you work in an
    video editing app where the video is scaled to much smaller side to fit
    the panel in the app (not full screen), then you need to consider that
    the app itself can do previews in background so that when you need to
    dispaly video it is very fast.

    This is why the real tests is when someone exports videos. (which the
    newer benchmarks form people who didn't get seeds will publish). Those benchmarks still show the M1 ahead. But for such work, the performance
    is not as stellar as just showing the video on screen. And this is where
    the 16GB has better performance due in part to less paging and better
    cooling.


    it's the shape of things in the very first models.

    Correct. And we don't know what the next Mxx chips will be like. But
    based on how Apple presented it, the built-in GPU appears to be a fairly
    hard standard and it isn't clear how Apple will deal with the Mac Pro or
    iMac Pro.

    Same with whether any macs will have PCI-E bus for expansion. The
    architecture and OS integration become a lot simpler if you have fixed
    self contained configs and need not support peripherals you don't make.



    more nonsense. where did you get the idea the built in ssd is useless
    when booting from an external drive?

    I would have to re-read the IOS guide to Security section on the secure
    enclave access to the drive (with knowledge it is now used on computers,
    not just iDevices).

    Even Apple's public documehts tell people they must do a backup on
    esternal drive because data on an SSD controlled by Secute Enclave (or
    T2) is by design, non recoverable (to prevenrt 3 letter organisations
    from spying on you).

    You cannot format the drive externally and then install it. You need to
    keep APFS partition because you need to use Recovery boot to set
    security options to allow remote boot, disable code signing of boot code
    etc.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Saturday, November 28, 2020 20:36:35
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 20:20, Lewis wrote:
    In message <KmzwH.23780$PP.20307@fx07.iad> Alan Browne <bitbucket@blackhole.com> wrote:
    On 2020-11-28 16:18, Lewis wrote:
    I ran a 6 hour YouTube stream recorded in 1080p through the beta
    handbrake M1 version.

    First, in hardware mode it ran at 177fos, not at all surprising.

    In software mode converting to 1080p "Fast" preset, the fps of the
    conversion dropped at times to as low as 68fps for a few seconds, but
    most of the time it was between 85-105fps with occasional peaks as high
    as 122fps.

    At the same time, I was using the system the entire time and noticed no
    lagging at all.

    MBA or MBP or Mini?

    MBA.

    With a more pristine source video what fps for conversion to .265 from .264?

    I don't have a more pristine video of any size worth testing.

    Can you look at the memory config under "about" or "system information"?

    the MBA has 16GB, though I doubt I needed it.

    I meant the memory spec shown in "about" | "system information"
    ie: DDR4 or whatever...


    Oh, the 6GB video file was remote, but the converted file was written locally. I doubt this affected the speed, but it might have cost s few
    FPS.

    Oh, the MBA also got a little warm. A LITTLE warm. Not to warm to set it
    on my bare legs with not even the slightest hint of discomfort, but
    enough to notice it was warm.

    Well, heat for the house.


    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Saturday, November 28, 2020 20:36:54
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 00:49, Lewis wrote:

    So he honestly believes that Apple has switched their platform to a new
    chip and has NO IDEA how they will release machines over the next 2
    years that will be any faster or better than the $700 Mac mini they just released.

    He has referred to Apple and to hundreds of people who have received the
    M1 machines as either liars or stupidly misguided or paid off
    accomplices in a conspiracy to make the M1 Mac appear better than they
    are.

    You shoudld apply to Trump Organization, your ability to skew facts and
    lie would impress the orange one and he would hire you. (he may not pay
    you, and your job won't last long because of bankruptcy, but he'd like you).


    He continues to deny that the M1 machines can process 4K video better
    than his 7 year old machine,

    I never said that.


    Jason Snell recently discussed running a de-noiser tool on his M1 mac.
    This tool is the reason he purchased a 10 core iMac Pro, and the tool
    maxes out the iMac. The iMac is faster, but only a bit. And the
    de-noiser is running in Rosetta.

    oh, so you do admit now that some Intel Macs are still faster for some
    tasks.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Saturday, November 28, 2020 20:38:49
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 09:10, Alan Browne wrote:

    That it's a walled garden of sorts does not take away from the plain,
    solid, uncontestable fact that they are computers.

    That is fine with me. My iPhone and iPad are "appliances" in the sense
    that I don't spend a lot of effort protecting them (backups) except for
    any music I purchase via them or photos I take. Everything else about
    them is backed up intrinsically.


    Are modern fridges computers? They have an OS in them, sometimes there
    are sopftware upgrades for them, and many even have a large screen on
    door, Internet connectivity and a browser.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Saturday, November 28, 2020 21:02:58
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 09:17, Alan Browne wrote:

    Current Mac Pros go to 1.5 TB of RAM and I doubt Apple will disappoint
    that end of the professional market.

    Well your buddies Lewis, nospam and their ilk all stated 8GB is plenty
    because M1 requires much less memory than Intel.

    Of course, you won't challenge them because I am the designated target
    for any/all gratuitous insults without ever providing answers/facts.

    Apple will not create a low volume variant that is significantly
    different from the rest of the Axx/Mxx family in order to support
    external memory, external GPUs, PCI-express etc.

    So the question becomes how many Mac models would share the same chip
    with the Mac Pro.

    The Mac Pros and some of the Imac Pros used XEON chips, a high end
    server chip. Apple didn't have to design that chip since Intel did in
    order to serve the large server market and high end workstation market.

    But with Apple on its own, its piotential market is only the high end workstation market (which it narrowed significantly with the 2019
    $60,000 cheee grater). The lower the volume, the less justification
    there ios for Apple to create a high end "server class" chip for a Mac Pro.

    Apple could very well have something up its sleeve and have the volumes
    to justify producing a Xeon class chip that would beat the pants off the
    XEON and have 1/10th power consumption. (aka: either enter the server
    market, or make the high end chip for its Mac Pro, and license it to
    server manufacturers to be used only on servers (and thus not compete
    against Apple).

    When Apple moved from 68k to PowerPC, there was just the desktop Mac and
    then a model for laptop when PowerPC got a low power version.

    When Apple switched to Intel, it was because it already had the full
    array of variants from laptop to servers (remember Xserve) so there was
    no real question on how Apple would transition its full product lineup.

    But as it stands, the transition from Intel to Axx was announced with no information on how Apple woudl architect the chip and provide full range
    to cover from laptop to high end desktop.

    This month, we found out about M1, architecturally designed as a fixed
    config to build laptop apliances.

    The questions remain on what Apple will do for higher end IMacs and MacPro.

    Your ilk refuse honest debate and are convinced all questions are
    already answered, some of you even claim 8GB is plenty enough for any
    type of video editing.


    The fact is that Apple has not provided official hints on where it it
    going with its M1 architecture. On the one hand, M1 shows a fixed config
    fully embedded SoC which could scale to a certain extent, on the other
    hand, "certain extent" may not cover high end and require a very
    different implementation to create a more conventioanl computer with
    discrete components such as RAM, GPU etc.



    Just because one wonders where Apple will go does not mean that one
    thinks Apple will fail, which is what your ilk always tries to twist discussions into to pain the person as FUDster etc.

    Asking question and discussing possibilities does not mean one states
    Apple will fail.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Saturday, November 28, 2020 18:33:05
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 5:14 p.m., JF Mezei wrote:
    On 2020-11-27 23:24, Alan Baker wrote:

    'No Security
    No Security doesn't enforce any of the above security requirements for
    your startup disk.'

    You lose.


    In order to get to the menu to disable this, you need to have OS-X, in particular the recovery partition (which is now on an APFS GUID
    partition which contains the AFPS "partition" for recovery).

    And?



    On the M1 machines, it isn't clear if the built-in SSD even has a GUID partitioning scheme, it could be native APFS since there is no EFI which required GUID partition for the boot. Good luck installing windows on
    that SSD if it is partitioned APFS natively with no GUID. And you need
    to keep it in order to access that recovery boot menu to disable the
    security (in case some glitch causes it to return).

    "Here’s everything you can do with macOS Recovery on your M1 Mac with
    Apple Silicon:

    Repair your internal disk
    Install or reinstall macOS
    Use the Safari browser
    Restore your files from a Time Machine backup
    Set security options for different disks"

    <https://www.idownloadblog.com/2020/11/20/how-to-boot-your-m1-mac-into-macos-recovery/>




    Also, still not clear to me whether Linux, even if it supported APFS,
    could run from that SSD since it is controlled by the secure enclave.
    (so you have to boot from external drives).

    Sorry, but I've provided an actual cite, so now you get to do the same
    to support your claim that the SSD is "controlled by the secure enclave".

    I literally just showed you a reference that says you can turn off
    security on the internal drive and let it boot anything you want.



    You are quick to insult, but nevet provide actual hard information, just marketing gobledeegook.


    An actual Apple support document is "marketing gobledeegook", you twit?


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Saturday, November 28, 2020 18:35:31
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 5:38 p.m., JF Mezei wrote:
    On 2020-11-28 09:10, Alan Browne wrote:

    That it's a walled garden of sorts does not take away from the plain,
    solid, uncontestable fact that they are computers.

    That is fine with me. My iPhone and iPad are "appliances" in the sense
    that I don't spend a lot of effort protecting them (backups) except for
    any music I purchase via them or photos I take. Everything else about
    them is backed up intrinsically.


    Are modern fridges computers?

    No. They are refrigerators that have a rudimentary computer within them.

    Next.

    They have an OS in them, sometimes there
    are sopftware upgrades for them, and many even have a large screen on
    door, Internet connectivity and a browser.

    Bully for them, twit.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Saturday, November 28, 2020 22:35:33
    From Newsgroup: comp.sys.mac.system

    In article <mjDwH.42454$Uz.30734@fx46.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


    Current Mac Pros go to 1.5 TB of RAM and I doubt Apple will disappoint that end of the professional market.

    Well your buddies Lewis, nospam and their ilk all stated 8GB is plenty because M1 requires much less memory than Intel.

    8-16gb is perfectly fine for a macbook air, if not overkill.

    you do realize the intel macbook air it replaced was also 8/16gb, right?

    once again, these are the *first* models. future models will support
    more memory. to claim otherwise is idiotic.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Saturday, November 28, 2020 22:35:57
    From Newsgroup: comp.sys.mac.system

    In article <ATCwH.185645$2j.146120@fx38.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

    Yes I realize. But I am responding to your ilk's statements that 8GB is
    plenty because M1 doesn't need as much memory,

    they do not. that is a well established fact.

    Yet to see any explanation for why applications require less RAM when
    running on ARM/M1 vs x86.

    because you don't care to look.

    The folks who got seeds from Apple and did the early benchmarks reported
    only on performance, didn,t report on paging.

    some did, and they said it was not noticeable, one of the advantages of
    unified memory on the soc.

    Later reports do mention
    the paging that happens on the 8GB. The fact that even with paging, the machine outperformas the older Apple laptop based on Intel is even more admirable, but it does not make an "establish fact" that M1 requires
    less memory.

    yes it does.

    the built in gpu is outperforming many discrete gpus with a *lot* less power. keep in mind these are low end systems.

    The comparisons so far were with the Intel machines with built-in Intel
    GPUs. And yes, the M1 beats the Intel ones easily.

    and does so with less memory.

    Another thing to consider is that when you work with a native 4K
    resolution screen, the GPU moves a lot more data. When you work in an
    video editing app where the video is scaled to much smaller side to fit
    the panel in the app (not full screen), then you need to consider that
    the app itself can do previews in background so that when you need to
    dispaly video it is very fast.

    the m1 macs support 6k displays.

    This is why the real tests is when someone exports videos. (which the
    newer benchmarks form people who didn't get seeds will publish). Those benchmarks still show the M1 ahead. But for such work, the performance
    is not as stellar as just showing the video on screen. And this is where
    the 16GB has better performance due in part to less paging and better cooling.

    exporting is i/o bound, not memory bound.

    it's the shape of things in the very first models.

    Correct. And we don't know what the next Mxx chips will be like. But
    based on how Apple presented it, the built-in GPU appears to be a fairly
    hard standard and it isn't clear how Apple will deal with the Mac Pro or
    iMac Pro.

    it is if you look at industry trends.

    Same with whether any macs will have PCI-E bus for expansion. The architecture and OS integration become a lot simpler if you have fixed
    self contained configs and need not support peripherals you don't make.

    they have pci expansion via thunderbolt.

    the only current mac to have pci slots is the mac pro and that model is
    likely to be the last to transition to apple silicon.

    more nonsense. where did you get the idea the built in ssd is useless
    when booting from an external drive?

    I would have to re-read the IOS guide to Security section on the secure enclave access to the drive (with knowledge it is now used on computers,
    not just iDevices).

    re-read it all you want, you still won't understand it.

    Even Apple's public documehts tell people they must do a backup on
    esternal drive because data on an SSD controlled by Secute Enclave (or
    T2) is by design, non recoverable (to prevenrt 3 letter organisations
    from spying on you).

    that has nothing to do with booting from an external drive.

    you're all over the map.

    You cannot format the drive externally and then install it. You need to
    keep APFS partition because you need to use Recovery boot to set
    security options to allow remote boot, disable code signing of boot code
    etc.

    no.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 05:08:14
    From Newsgroup: comp.sys.mac.system

    In message <PBCwH.42501$sW6.36723@fx47.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-27 23:24, Alan Baker wrote:

    'No Security
    No Security doesn't enforce any of the above security requirements for
    your startup disk.'

    You lose.

    In order to get to the menu to disable this, you need to have OS-X,

    1) The computer comes with macOS already installed.
    2) The computer comes with the recovery partition pre-installed.
    3) M1 Macs do not run any version of OS X.
    4) There is no such think as "OS-X" and never has been.

    On the M1 machines, it isn't clear

    This is the code for "JF makes shit up based on idiocy, ignorance, and
    lies."

    --
    Slab: Jus' say 'AarrghaarrghpleeassennononoUGH'. --Feet of Clay
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 05:16:32
    From Newsgroup: comp.sys.mac.system

    In message <XWCwH.17891$lo15.15617@fx35.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-28 00:49, Lewis wrote:

    So he honestly believes that Apple has switched their platform to a new
    chip and has NO IDEA how they will release machines over the next 2
    years that will be any faster or better than the $700 Mac mini they just
    released.

    He has referred to Apple and to hundreds of people who have received the
    M1 machines as either liars or stupidly misguided or paid off
    accomplices in a conspiracy to make the M1 Mac appear better than they
    are.

    You shoudld apply to Trump Organization, your ability to skew facts and

    You are a FUD spreading sack of lying shit who is incapable of reading
    or listening. You can constantly posted utter bullshit over and over
    again, for YEARS.

    He continues to deny that the M1 machines can process 4K video better
    than his 7 year old machine,

    I never said that.

    You most certainly did. And repeatedly claimed it was impossible for a
    machine with 8GB of RAM to even edit streams of 4K video and that
    Apple was lying.


    Jason Snell recently discussed running a de-noiser tool on his M1 mac.
    This tool is the reason he purchased a 10 core iMac Pro, and the tool
    maxes out the iMac. The iMac is faster, but only a bit. And the
    de-noiser is running in Rosetta.

    oh, so you do admit now that some Intel Macs are still faster for some
    tasks.

    No one anywhere has ever said otherwise. An $6500 iMac Pro from 2018 is
    still a bit faster than an $700 Mac mini.

    --
    What are you doing here, sad little nerd king?
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 05:20:37
    From Newsgroup: comp.sys.mac.system

    In message <ATCwH.185645$2j.146120@fx38.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-28 00:47, nospam wrote:

    Yes I realize. But I am responding to your ilk's statements that 8GB is
    plenty because M1 doesn't need as much memory,

    they do not. that is a well established fact.

    Yet to see any explanation for why applications require less RAM when
    running on ARM/M1 vs x86.

    The folks who got seeds from Apple and did the early benchmarks reported
    only on performance, didn,t report on paging. Later reports do mention
    the paging that happens on the 8GB. The fact that even with paging, the machine outperformas the older Apple laptop based on Intel is even more admirable, but it does not make an "establish fact" that M1 requires
    less memory.

    You finally acknowledge that an 8GB M1 Mac far outperforms a Intel
    machine even with paging, but yet you still want to claim the M1 with
    less memory doesn't require less memory to outperform the Intel
    machines.

    The Stupid runs deep.

    Another thing to consider is that when you work with a native 4K
    resolution screen, the GPU moves a lot more data.

    Less, in fact, than if the video has to be scaled.

    --
    May you live in interesting times
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Sunday, November 29, 2020 18:21:39
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 02:35:31 +0000, Alan Baker said:
    On 2020-11-28 5:38 p.m., JF Mezei wrote:
    On 2020-11-28 09:10, Alan Browne wrote:

    That it's a walled garden of sorts does not take away from the plain,
    solid, uncontestable fact that they are computers.

    That is fine with me. My iPhone and iPad are "appliances" in the sense
    that I don't spend a lot of effort protecting them (backups) except for
    any music I purchase via them or photos I take. Everything else about
    them is backed up intrinsically.


    Are modern fridges computers?

    No. They are refrigerators that have a rudimentary computer within them.

    Next.

    Some fridges have bult-in screens that aren't really much different to
    an Android tablet device. People have even hacked their fridges to be
    able to stream-play Xbox games on them. <https://www.extremetech.com/computing/316177-you-can-now-play-doom-eternal-on-a-samsung-fridge>



    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 05:25:11
    From Newsgroup: comp.sys.mac.system

    In message <mjDwH.42454$Uz.30734@fx46.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-28 09:17, Alan Browne wrote:

    Current Mac Pros go to 1.5 TB of RAM and I doubt Apple will disappoint
    that end of the professional market.

    Well your buddies Lewis, nospam and their ilk all stated 8GB is plenty because M1 requires much less memory than Intel.

    The facts are clear. I know you despise facts, but the facts don't care.

    Of course, you won't challenge them because I am the designated target
    for any/all gratuitous insults without ever providing answers/facts.

    You are the moron FUDster who gets EVERYTHING wrong. That's a role you
    took on and refuse to give up.

    Apple will not create a low volume variant that is significantly
    different from the rest of the Axx/Mxx family in order to support
    external memory, external GPUs, PCI-express etc.

    You, as usual, know nothing and state your uninformed opinions as facts.

    --
    I'm the High King of Fillory. I took a blood test.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Sunday, November 29, 2020 00:47:11
    From Newsgroup: comp.sys.mac.system

    In article <rpvb53$vg7$1@gioia.aioe.org>, Your Name
    <YourName@YourISP.com> wrote:

    Are modern fridges computers?

    No. They are refrigerators that have a rudimentary computer within them.

    Next.

    Some fridges have bult-in screens that aren't really much different to
    an Android tablet device.

    some fridges run android
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 29, 2020 01:04:17
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 00:08, Lewis wrote:

    1) The computer comes with macOS already installed.
    2) The computer comes with the recovery partition pre-installed.


    On Intel, the volume is a GUID partitioning scheme with an EFI partition
    and an APFS partition, within which are APFS volumes, including
    boo9table OS-X and bootable recovery.

    It is not clear what Secure Boot supports as boot volumes. Consider a
    case where trhe boot volume is expected to be APFS as primary
    partitioning scheme.

    You'll have to do fancy footwork to backup the AFPS volume integrally,
    format drive as GUID scheme, create an APFS partition and then restore
    the APFS backup into it tro have OS0X, recovery in it, and you can then
    create GUID partition for Linux/Windows/whatever else OS you want.

    But then, the question arises of what type of boot environment "Secure
    Boot" supports. Does it have a EFI emulator to boot another system? Does
    Linux have Secure Boot support ?

    That is why you are likely stuck to external drives for any alternate OS booting. And we'll need documentation on what Secure Boot supports and
    which operating systems have support to boot from Secure Boot.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 29, 2020 01:09:44
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 00:20, Lewis wrote:

    You finally acknowledge that an 8GB M1 Mac far outperforms a Intel
    machine even with paging,

    I never said otherwise. My argument is with your claim that M1 requires
    less memory.

    If you agree that the 8GB model pages a lot more than the 16GB model,
    then why do you argue that the M1 based Macs require less memory than
    their Intel counterpart?

    Just because performace is good despite paging does not mean that the M1
    chip requires less memory to run the same programs. Consider that if
    the machine had modern aount of memory (say 24GB), those video renders
    would be even faster than then are on only 8GB.


    You or your ilk said that "exports" are I/O intensive. You've obviously
    never used after effects.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Saturday, November 28, 2020 22:45:32
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 10:04 p.m., JF Mezei wrote:
    On 2020-11-29 00:08, Lewis wrote:

    1) The computer comes with macOS already installed.
    2) The computer comes with the recovery partition pre-installed.


    On Intel, the volume is a GUID partitioning scheme with an EFI partition
    and an APFS partition, within which are APFS volumes, including
    boo9table OS-X and bootable recovery.

    OK... ...so?


    It is not clear what Secure Boot supports as boot volumes. Consider a
    case where trhe boot volume is expected to be APFS as primary
    partitioning scheme.

    It not being clear to YOU is not actually a problem.


    You'll have to do fancy footwork to backup the AFPS volume integrally,
    format drive as GUID scheme, create an APFS partition and then restore
    the APFS backup into it tro have OS0X, recovery in it, and you can then create GUID partition for Linux/Windows/whatever else OS you want.

    You literally have no clue whatsoever whether anything you just wrote
    there bears any relationship to reality.


    But then, the question arises of what type of boot environment "Secure
    Boot" supports. Does it have a EFI emulator to boot another system? Does Linux have Secure Boot support ?

    Irrelevant.


    That is why you are likely stuck to external drives for any alternate OS booting. And we'll need documentation on what Secure Boot supports and
    which operating systems have support to boot from Secure Boot.

    No. Read slowly and carefully:

    Apple says you can turn off "Secure Boot" entirely.

    Let's look at it again:

    'About Startup Security Utility
    Use Startup Security Utility to make sure that your Mac always starts up
    from your designated startup disk, and always from a legitimate, trusted operating system.

    If you're using a Mac with the Apple T2 Security Chip, Startup Security Utility offers three features to help secure your Mac against
    unauthorized access: Firmware password protection, Secure Boot, and
    External Boot.'

    So you're clear: this applies to Macs that use the enclave, right?

    'Change Secure Boot settings

    Use these settings to make sure that your Mac always starts up from a legitimate, trusted operating system.

    ...

    No Security

    No Security doesn't enforce any of the above security requirements for
    your startup disk.'


    <https://support.apple.com/en-ca/HT208198>
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 11:59:21
    From Newsgroup: comp.sys.mac.system

    In message <CRGwH.42473$Uz.39770@fx46.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-29 00:08, Lewis wrote:

    1) The computer comes with macOS already installed.
    2) The computer comes with the recovery partition pre-installed.

    On Intel, the volume is a GUID partitioning scheme with an EFI partition
    and an APFS partition, within which are APFS volumes, including
    boo9table OS-X and bootable recovery.

    So what?

    It is not clear

    And there you go again, opining on things you know nothing about.

    You'll have to do fancy footwork to backup the AFPS volume integrally,
    format drive as GUID scheme, create an APFS partition and then restore

    You are, as always, making shit up and proving yourself to be a fool.
    You have repeated this bullshit over and over again, based on nothing
    but your ignorance and your desire to spread FUD and lies, You have no
    basis for this claim whatsoever, and yet you continue to make it.

    Surprising no one at all, you are, again and as usual, 100% wrong.

    M1 Mac Book Air:

    /dev/disk0 (internal):
    #: TYPE NAME SIZE IDENTIFIER
    0: GUID_partition_scheme 500.3 GB disk0
    1: Apple_APFS_ISC â¨â© 524.3 MB disk0s1
    2: Apple_APFS â¨Container disk3â© 494.4 GB disk0s2
    3: Apple_APFS_Recovery â¨â© 5.4 GB disk0s3

    Shit for brains going to shut the fuck up now?

    the APFS backup into it tro have OS0X,

    I have no idea what you are blathering about.

    Backing up and restoring is not an issue and your idiotic FUD is not
    fooling anyone.

    But then, the question arises of what type of boot environment "Secure
    Boot" supports. Does it have a EFI emulator to boot another system? Does Linux have Secure Boot support ?

    I have no idea and I also don't fucking care. Like most people I did not
    buy a Mac to boot fucking Linux. Why the fuck would anyone want to boot
    linux on a Mac when you can literally run all the Unix software there is
    right under macOS? And you can run Linux right inside macOS as well.

    That is why you are likely stuck to external drives for any alternate OS booting.

    1) You do not know this
    2) who fucking cares?
    3) if that is your complaint about macs, PLEASE go buy a fucking Intel box
    and stop using Macs. PLEASE. PLEASE. Hurry up. Ubuntu iOS over that-a-way. https://ubuntu.com

    And we'll need documentation on what Secure Boot supports and
    which operating systems have support to boot from Secure Boot.

    No, "we" won't.

    If Microsoft gets off their ass and decided to make ARM64 Windows not a steaming pile of shit, then they will get it running on M1 Macs. There
    will be no need to boot into ARM64 Windows, of course, but there is also
    no reason to think it would not be possible. But there would literally
    be absolutely no reason to do so.

    You can run a Linux OS on the M1 Macs right now, of course, if you
    really want to, and this was explained and demonstrated back in June in
    a video you claimed you watched, though the consensus at the time based
    on your complete lack of knowledge of the contents of the video was that
    if you watched it at all you certainly did not absorb any information
    from it as everything you said about it was entirely wrong.

    Seems to be a theme with you.

    --
    I laugh in the face of danger. Then I hide until it goes away.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 12:09:14
    From Newsgroup: comp.sys.mac.system

    In message <IWGwH.17447$nc.5915@fx19.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-29 00:20, Lewis wrote:

    You finally acknowledge that an 8GB M1 Mac far outperforms a Intel
    machine even with paging,

    I never said otherwise.

    LIAR.

    My argument is with your claim that M1 requires less memory.

    No, your argument has been with every single thing that Apple and
    HUNDREDS (thousands by now) of people have said about the M1.

    That the M1 requires less memory is a FACT that you just acknowledged
    above, in the part that you snipped out.

    It is not opinion, the M1 Macs do a lot more, a lot faster, adn they do
    it with LESS RAM.

    If you agree that the 8GB model pages a lot more than the 16GB model,

    It might, it might not. I do not have an 8GB model and I am not likely to
    have one, Other people have said that it does, and that it is still so
    fast they do not notice the paging and it outperforms the Intel machines
    with more RAM. You discount these people and refer to them as paid-off
    by Apple with free computers, because you are an inveterate liar.

    then why do you argue that the M1 based Macs require less memory than
    their Intel counterpart?

    Because they do, as you admitted two posts up.

    Just because performace is good despite paging does not mean that the M1
    chip requires less memory to run the same programs. Consider that if
    the machine had modern aount of memory (say 24GB),

    A number you pulled out of your ass? has Apple *EVER* offered a mchine
    with 24GB of RAM? I don;t think so.

    What where the RAM options on the previous Mac Book Air? 8GB and 16GB?
    Oh yes, they were. What where the memory options on the preious 2-Port
    MBP? 8GB and 16GB? RIGHT AGAIN!

    those video renders would be even faster than then are on only 8GB.

    Perhaps they would be, but the point is that they run NOW and they run
    in REAL TIME and they run WITHOUT DROPPING FRAMES, which the Intel
    machines of the same models could NOT DO.

    You or your ilk said that "exports" are I/O intensive.

    No, shit-for-brains, I never said anything like that. CONVERTING is
    intensive.

    --
    Ah we're lonely, we're romantic / and the cider's laced with acid /
    and the Holy Spirit's crying, Where's the beef? / And the moon is
    swimming naked / and the summer night is fragrant / with a mighty
    expectation of relief
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Sunday, November 29, 2020 08:55:41
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 20:38, JF Mezei wrote:
    On 2020-11-28 09:10, Alan Browne wrote:

    That it's a walled garden of sorts does not take away from the plain,
    solid, uncontestable fact that they are computers.

    That is fine with me. My iPhone and iPad are "appliances" in the sense
    that I don't spend a lot of effort protecting them (backups) except for
    any music I purchase via them or photos I take. Everything else about
    them is backed up intrinsically.


    Are modern fridges computers? They have an OS in them, sometimes there
    are sopftware upgrades for them, and many even have a large screen on
    door, Internet connectivity and a browser.

    They are fridges equipped with a computer with very limited 'scope' of use.

    Stop being a silly boy.


    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Sunday, November 29, 2020 09:14:13
    From Newsgroup: comp.sys.mac.system

    On 2020-11-28 21:02, JF Mezei wrote:
    On 2020-11-28 09:17, Alan Browne wrote:

    Current Mac Pros go to 1.5 TB of RAM and I doubt Apple will disappoint
    that end of the professional market.

    Well your buddies Lewis, nospam and their ilk all stated 8GB is plenty because M1 requires much less memory than Intel.

    Whatever their specific claims (and I'm not looking for them) 8 GB is
    plenty depending on context.

    I'd assume it's par just to be conservative about it but it could be
    less. If one compiles a moderate/large program for intel and for Mx,
    each destined for intel and Mx machines respectively and both for Big
    Sur, it would be interesting to see. (ie: not compiled as universal).

    In the context of an MBA and many uses of MBP or Mac Mini, 8 GB is
    indeed plenty for many users whose use is browsing, e-mail,
    spreadsheets, word processing, presentations, photo editing, video
    editing (smaller projects) and so on. My SO has been using her MBA
    thusly for years w/o issue - and it of course has GPU sharing the CPU's
    RAM. Alas no big excuse to buy an M1 MBA at this time.

    If one thinks they want more, then 16 GB is plenty for a huge number of
    tasks.

    For the high memory need users you can be sure Apple will not
    disappoint, and that those models will also have even more powerful
    CPU/GPU sets.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Sunday, November 29, 2020 09:20:09
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 09:14, Alan Browne wrote:

    In the context of an MBA and many uses of MBP or Mac Mini, 8 GB is
    indeed plenty for many users whose use is browsing, e-mail,
    spreadsheets, word processing, presentations, photo editing, video
    editing (smaller projects) and so on.  My SO has been using her MBA
    thusly for years w/o issue - and it of course has GPU sharing the CPU's RAM.  Alas no big excuse to buy an M1 MBA at this time.

    oops: my SO's machine on which she does all that (except movies) is 4 GB
    of RAM.


    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 29, 2020 15:33:06
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 06:59, Lewis wrote:

    M1 Mac Book Air:

    /dev/disk0 (internal):
    #: TYPE NAME SIZE IDENTIFIER
    0: GUID_partition_scheme 500.3 GB disk0
    1: Apple_APFS_ISC â¨â© 524.3 MB disk0s1
    2: Apple_APFS â¨Container disk3â© 494.4 GB disk0s2
    3: Apple_APFS_Recovery â¨â© 5.4 GB disk0s3

    Thanks for the info. A rare time when you actually provide any.

    It's how conversatiosn should proceed when there are questions.

    Does this mean that IOS still runs on GUID with APFS on top?



    Backing up and restoring is not an issue and your idiotic FUD is not
    fooling anyone.

    Apple states you have to backup to external drive because a backup on a
    SSD is not recoverable due to encryption that is tied to that specific hardware.

    I have no idea and I also don't fucking care.

    Yet you choose to insult people who do care.


    If Microsoft gets off their ass and decided to make ARM64 Windows not a steaming pile of shit, then they will get it running on M1 Macs.

    Heard something about licensing problems between Microsoft and ARM. No
    idea if true or not. But the boot console remains the issue since
    Microsoft would have to get the specs from Secure Boot, find a way to
    either sign the OS or permanently disbale code signing. ( if OS-X
    recovery partition ios gone, there would be no way to undo a "factory
    reset" of NVRAM to allow unsigned OS to boot).

    Apple could provide s "Boot Camp" equivalent to emulate an EFI boot
    consile to make Windows boot.



    You can run a Linux OS on the M1 Macs right now, of course,

    Linus Torvalds disagrees with you. https://arstechnica.com/gadgets/2020/11/__trashed-6/

    Not just the boot console, but also the GPU access.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 29, 2020 15:46:45
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 07:09, Lewis wrote:

    That the M1 requires less memory is a FACT that you just acknowledged
    above, in the part that you snipped out.

    Funny how you are unable to prvide any factual reason why a 64 bit RISC architecture would recquire less RAM to run the same app running on a
    CISC 64 bit architecture.

    making claims often enough doesn'T make it a "FACT".

    It is not opinion, the M1 Macs do a lot more, a lot faster, adn they do
    it with LESS RAM.

    They don't do "a lot more". They don't do it with less RAM, they simply
    page RAM to disk because there isn't enough physical RAM.

    The M1,s performance compensates for the loss of performance due to
    paging such that you still have good experience.

    Also, here is a question:

    When you are working on a 4K video on Final Cut Pro and edit it and play
    it within the video editing app in a window that isn't anywhere near 4k
    in size, are you working on the actual 4K video, or working on a lower resolution proxy ?

    A number of video editing apps create preview files that are used for
    actual work, and those may be of resolution that is much lower to make
    the work more efficient (especially when working on small screen for a
    laptop). **IF** that is the case by default on Final Cut pro, it would
    mean that the fancy performance you see isn't really editing 4K videos
    but rather their proxies at lower resolution (but when you export, it
    then processes all the editing/effects onto the original 4K).

    So when you watch those videos of people editing and comparing
    operformance, you need to keep an eye out to see if proxies are used
    either explicitely, or are the default for that app.


    It might, it might not. I do not have an 8GB model and I am not likely to have one,

    So, you posted disk utility listing without having an M1?

    OR

    If you claim the 8GB is plenty because M1 requires memory, how come you
    bought the 16GB model if you did buy one?



    You or your ilk said that "exports" are I/O intensive.

    No, shit-for-brains, I never said anything like that. CONVERTING is intensive.


    On of your ilk stated yesterday that export was I/O intensive because I
    said it was CPU intensive. Are you actually agreeing with me now?



    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Sunday, November 29, 2020 15:48:28
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 08:55, Alan Browne wrote:

    They are fridges equipped with a computer with very limited 'scope' of use.


    Is a fridge equipped with web browser, touch screen, keeping track of
    inventory in fridge etc just a friedge, but a Chromebook that does the
    same a computer?


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Browne@bitbucket@blackhole.com to comp.sys.mac.system on Sunday, November 29, 2020 16:16:04
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 15:48, JF Mezei wrote:
    On 2020-11-29 08:55, Alan Browne wrote:

    They are fridges equipped with a computer with very limited 'scope' of use.


    Is a fridge equipped with web browser, touch screen, keeping track of inventory in fridge etc just a friedge, but a Chromebook that does the
    same a computer?


    My car has many dozen microprocessors in it including an ECU that is
    pretty powerful in computing terms. And a wonderful centre console
    (Android based) that Apple CarPlay presents on and interfaces to.
    It's still a car no matter how many computers are built into it.

    None of this changes the salient fact that an iPhone, iPad, etc, and Chromebooks for that matter are computers. Personal, portable,
    powerful, very versatile computers.

    --
    "...there are many humorous things in this world; among them the white
    man's notion that he is less savage than the other savages."
    -Samuel Clemens
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 29, 2020 13:28:40
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 12:48 p.m., JF Mezei wrote:
    On 2020-11-29 08:55, Alan Browne wrote:

    They are fridges equipped with a computer with very limited 'scope' of use.


    Is a fridge equipped with web browser, touch screen, keeping track of inventory in fridge etc just a friedge, but a Chromebook that does the
    same a computer?

    A fridge with an integrated computer is still a fridge.

    Just as a car with a DVD player is still a car and not a DVD player.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 29, 2020 13:30:58
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 12:33 p.m., JF Mezei wrote:
    On 2020-11-29 06:59, Lewis wrote:

    M1 Mac Book Air:

    /dev/disk0 (internal):
    #: TYPE NAME SIZE IDENTIFIER
    0: GUID_partition_scheme 500.3 GB disk0 >> 1: Apple_APFS_ISC â¨â© 524.3 MB disk0s1
    2: Apple_APFS â¨Container disk3â© 494.4 GB disk0s2
    3: Apple_APFS_Recovery â¨â© 5.4 GB disk0s3

    Thanks for the info. A rare time when you actually provide any.

    So that puts him up by an infinite ratio on you.


    It's how conversatiosn should proceed when there are questions.

    Does this mean that IOS still runs on GUID with APFS on top?

    Don't know. Don't care.

    It doesn't change your bullshit into truth.




    Backing up and restoring is not an issue and your idiotic FUD is not
    fooling anyone.

    Apple states you have to backup to external drive because a backup on a
    SSD is not recoverable due to encryption that is tied to that specific hardware.

    Cite please.


    I have no idea and I also don't fucking care.

    Yet you choose to insult people who do care.

    You don't care. You just like throwing around feces.



    If Microsoft gets off their ass and decided to make ARM64 Windows not a
    steaming pile of shit, then they will get it running on M1 Macs.

    Heard something about licensing problems between Microsoft and ARM. No
    idea if true or not. But the boot console remains the issue since
    Microsoft would have to get the specs from Secure Boot, find a way to
    either sign the OS or permanently disbale code signing. ( if OS-X
    recovery partition ios gone, there would be no way to undo a "factory
    reset" of NVRAM to allow unsigned OS to boot).

    But you'll state it as IF it's true anyway.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Sunday, November 29, 2020 13:32:11
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 12:46 p.m., JF Mezei wrote:
    On 2020-11-29 07:09, Lewis wrote:

    That the M1 requires less memory is a FACT that you just acknowledged
    above, in the part that you snipped out.

    Funny how you are unable to prvide any factual reason why a 64 bit RISC architecture would recquire less RAM to run the same app running on a
    CISC 64 bit architecture.

    making claims often enough doesn'T make it a "FACT".

    Explanations never trump empirical data.

    Not knowing HOW a bumblebee flies doesn't make them fall out of the air.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 21:48:16
    From Newsgroup: comp.sys.mac.system

    In message <6ATwH.188636$2j.177426@fx38.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-29 06:59, Lewis wrote:

    M1 Mac Book Air:

    /dev/disk0 (internal):
    #: TYPE NAME SIZE IDENTIFIER
    0: GUID_partition_scheme 500.3 GB disk0
    1: Apple_APFS_ISC â¨â© 524.3 MB disk0s1
    2: Apple_APFS â¨Container disk3â© 494.4 GB disk0s2
    3: Apple_APFS_Recovery â¨â© 5.4 GB disk0s3

    Thanks for the info. A rare time when you actually provide any.

    But not a rare time when you continued to post utter bullshit you made
    up based on nothing other than your FUDster inclinations.

    It's how conversatiosn should proceed when there are questions.

    There were no questions. There was YOU making up SHIT.

    Does this mean that IOS still runs on GUID with APFS on top?

    What the fuck is wrong with you? I mean, seriously, do you have some
    sort of brain disorder? Are you on medication for it, because you
    should be.

    Backing up and restoring is not an issue and your idiotic FUD is not
    fooling anyone.

    Apple states you have to backup to external drive because a backup on a
    SSD is not recoverable due to encryption that is tied to that specific hardware.

    You do not backup to the same physical drive you are trying to backup.
    NO ONE does that, because it is MORONIC. Again, what the fuck is wrong
    with you?

    I have no idea and I also don't fucking care.

    Yet you choose to insult people who do care.

    No, you do NOT care, you simply want to spread FUD. How often have you
    booted your Mac into Linux? And how often have to run Linux under an M1
    Mac hypervisor?

    Zero and Zero?

    If Microsoft gets off their ass and decided to make ARM64 Windows not a
    steaming pile of shit, then they will get it running on M1 Macs.

    Heard something about licensing problems between Microsoft and ARM.

    No you didn't. That is more of you making up LIES to spread FUD.

    idea if true or not. But the boot console remains the issue since
    Microsoft would have to get the specs from Secure Boot,

    This is laughable, even for you.

    find a way to either sign the OS

    Yep, signing the OS is certainly a mystery that may well be beyond
    Microsoft's abilities. Yeah, that totally makes sense. :eyeroll:

    Again, WHAT THE FUCK IS WRONG WITH YOU??

    You can run a Linux OS on the M1 Macs right now, of course,

    Linus Torvalds disagrees with you.

    I don't give a fuck what Linus says, you CAN run Linux right now under
    macOS.

    --
    May the forces of evil become confused on the way to your house.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 21:50:44
    From Newsgroup: comp.sys.mac.system

    In message <WMTwH.53523$Uz.4241@fx46.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-29 07:09, Lewis wrote:
    It might, it might not. I do not have an 8GB model and I am not likely to
    have one,

    So, you posted disk utility listing without having an M1?

    Your depths of stupidity are truly astonishing.

    --
    'Are you Death?' IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
    SCYTHE.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From nospam@nospam@nospam.invalid to comp.sys.mac.system on Sunday, November 29, 2020 17:15:31
    From Newsgroup: comp.sys.mac.system

    In article <slrnrs85p0.v8c.g.kreme@claragold.local>, Lewis <g.kreme@kreme.dont-email.me> wrote:

    Apple states you have to backup to external drive because a backup on a
    SSD is not recoverable due to encryption that is tied to that specific hardware.

    You do not backup to the same physical drive you are trying to backup.
    NO ONE does that, because it is MORONIC. Again, what the fuck is wrong
    with you?

    there are a lot of morons in this world.

    some people do exactly that, backing up to another partition on the
    same drive. i wish i was kidding.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Sunday, November 29, 2020 22:31:50
    From Newsgroup: comp.sys.mac.system

    In message <291120201715311293%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
    In article <slrnrs85p0.v8c.g.kreme@claragold.local>, Lewis <g.kreme@kreme.dont-email.me> wrote:

    Apple states you have to backup to external drive because a backup on a
    SSD is not recoverable due to encryption that is tied to that specific
    hardware.

    You do not backup to the same physical drive you are trying to backup.
    NO ONE does that, because it is MORONIC. Again, what the fuck is wrong
    with you?

    there are a lot of morons in this world.

    some people do exactly that, backing up to another partition on the
    same drive. i wish i was kidding.

    That certainly would explain why JF things being told not to backup to
    the internal SSD is a "problem" as there is nothing too stupid for him.


    --
    Seeing, contrary to popular wisdom, isn't believing. It's where
    belief stops, because it isn't needed any more. --Pyramids
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Your Name@YourName@YourISP.com to comp.sys.mac.system on Monday, November 30, 2020 15:29:48
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 21:28:40 +0000, Alan Baker said:
    On 2020-11-29 12:48 p.m., JF Mezei wrote:
    On 2020-11-29 08:55, Alan Browne wrote:

    They are fridges equipped with a computer with very limited 'scope' of use. >>
    Is a fridge equipped with web browser, touch screen, keeping track of
    inventory in fridge etc just a friedge, but a Chromebook that does the
    same a computer?

    A fridge with an integrated computer is still a fridge.

    But it also has an "integrated computer", and, with some hacking, some
    of them are no different an Android tablet, which could be termed as a "palmtop computer".

    Therefore it is either a "fridge-computer" or a "computer-fridge" ...
    of course the proper technical term uses the latest fad nomenclature:
    "smart fridge".


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Monday, November 30, 2020 00:38:11
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 16:28, Alan Baker wrote:

    A fridge with an integrated computer is still a fridge.

    A phone with an integrated computer is still a phone. My Siemens M55
    phone had radio player, WAP browser, could load JAVA apps, mail client
    etc. In many ways like an iPhone (but not as elegant). It was still
    considered a phone.

    Yes, an iPhone has more RAM, more storage than an IBM 5451 mainframe
    that McGill had with 8MB of RAM serving 134 users at McGill. But I view
    it more as an appliance than a ccomputer. few people write code, scripts
    on their iPhone to run on the iPhone. You write software on a real
    computer and then load it on the iPhone (if you have the privilege to do
    so as developper) or just buy apps at a App Store to load on your appliamce.


    The definition of "computer" is difficult to make.


    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Monday, November 30, 2020 00:39:47
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 16:30, Alan Baker wrote:

    Don't know. Don't care.

    It doesn't change your bullshit into truth.



    So you admit to know knowing or caring, yet somehow you have
    authoritative knowledge to claim I am wrong.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Monday, November 30, 2020 00:42:31
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 17:31, Lewis wrote:

    That certainly would explain why JF things being told not to backup to
    the internal SSD is a "problem" as there is nothing too stupid for him.


    I stumbled on a note from Apple that for T2 equipped Macs, you you need external backups. I merely related that here.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Monday, November 30, 2020 00:10:41
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 9:39 p.m., JF Mezei wrote:
    On 2020-11-29 16:30, Alan Baker wrote:

    Don't know. Don't care.

    It doesn't change your bullshit into truth.



    So you admit to know knowing or caring, yet somehow you have
    authoritative knowledge to claim I am wrong.


    I asked for your references...

    ...you wouldn't provide them.

    The one reference you provided to support your claim that you couldn't
    use another OS because of Secure Boot...

    ...actually proved you wrong.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Monday, November 30, 2020 00:10:57
    From Newsgroup: comp.sys.mac.system

    On 2020-11-29 9:42 p.m., JF Mezei wrote:
    On 2020-11-29 17:31, Lewis wrote:

    That certainly would explain why JF things being told not to backup to
    the internal SSD is a "problem" as there is nothing too stupid for him.


    I stumbled on a note from Apple that for T2 equipped Macs, you you need external backups. I merely related that here.


    Where is this note.

    Cite please.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From JF Mezei@jfmezei.spamnot@vaxination.ca to comp.sys.mac.system on Monday, November 30, 2020 05:03:21
    From Newsgroup: comp.sys.mac.system

    On 2020-11-30 03:10, Alan Baker wrote:

    Cite please.


    https://support.apple.com/en-us/HT208344


    There was more obvious one I had seen, but since your purpose in life is
    just to insult me, there is no reason for me to waste my time on you.

    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Alan Baker@notonyourlife@no.no.no.no to comp.sys.mac.system on Monday, November 30, 2020 02:31:40
    From Newsgroup: comp.sys.mac.system

    On 2020-11-30 2:03 a.m., JF Mezei wrote:
    On 2020-11-30 03:10, Alan Baker wrote:

    Cite please.


    https://support.apple.com/en-us/HT208344


    There was more obvious one I had seen, but since your purpose in life is
    just to insult me, there is no reason for me to waste my time on you.


    I can see why you snipped your own earlier statement:

    I stumbled on a note from Apple that for T2 equipped Macs, you you need
    external backups. I merely related that here.

    And then we see what the article actually says:

    'Always back up your content to a secure external drive or other secure
    backup location so that you can restore it, if necessary.'

    So the point is not the externality. That's a given.

    What they're discussing is need to use a SECURE backup if you want to
    maintain your security; that backing up to an insecure location defeats
    the whole purpose.

    What they are NOT doing is drawing any relationship between a T2 chip
    and some special need to do your backups externally because you have a
    machine with one.

    You lose.
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Lewis@g.kreme@kreme.dont-email.me to comp.sys.mac.system on Monday, November 30, 2020 13:17:39
    From Newsgroup: comp.sys.mac.system

    In message <7z%wH.34697$hg2.19347@fx20.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
    On 2020-11-29 16:28, Alan Baker wrote:

    A fridge with an integrated computer is still a fridge.

    A phone with an integrated computer is still a phone.

    No, because it is PRIMARILY a computer and the phone is, almost
    entirely, an afterthought.

    My Siemens M55

    Things have changed in the last twenty years.

    But I view it more as an appliance than a ccomputer.

    But you are a fool, and ignorant to boot. There are very few computer
    tasks that a modern phone (even an Android one) cannot do.

    few people write code,

    That is, of course, neither true nor the measure of what a computer is,
    and never has been.

    scripts

    And that is just wrong.

    on their iPhone to run on the iPhone.

    Still wrong.

    You write software on a real computer

    Nearly no one writes software. Nearly no one who uses computers writes software, This has been true since the first computer.

    The definition of "computer" is difficult to make.

    No it's not, you just have an idiotic and entirely wrong idea of what a computer is, so you are confused.

    --
    The point about being killed by magic was that it was much more
    inventive than, say, steel; there were all sorts of interesting
    new ways to die, and he couldn't put out of his mind the shapes
    he'd seen, just for an instant, before the wash of octarine fire
    had mercifully engulfed them. --Sourcery
    --- Synchronet 3.18b-Win32 NewsLink 1.113
  • From Jolly Roger@jollyroger@pobox.com to comp.sys.mac.system on Monday, November 30, 2020 17:41:57
    From Newsgroup: comp.sys.mac.system

    On 2020-11-30, Alan Baker <notonyourlife@no.no.no.no> wrote:
    On 2020-11-30 2:03 a.m., JF Mezei wrote:
    On 2020-11-30 03:10, Alan Baker wrote:

    Cite please.

    https://support.apple.com/en-us/HT208344

    There was more obvious one I had seen, but since your purpose in life is
    just to insult me, there is no reason for me to waste my time on you.

    I can see why you snipped your own earlier statement:

    I stumbled on a note from Apple that for T2 equipped Macs, you you need >>>> external backups. I merely related that here.

    And then we see what the article actually says:

    'Always back up your content to a secure external drive or other secure backup location so that you can restore it, if necessary.'

    So the point is not the externality. That's a given.

    What they're discussing is need to use a SECURE backup if you want to maintain your security; that backing up to an insecure location defeats
    the whole purpose.

    What they are NOT doing is drawing any relationship between a T2 chip
    and some special need to do your backups externally because you have a machine with one.

    You lose.

    He excels at it.

    --
    E-mail sent to this address may be devoured by my ravenous SPAM filter.
    I often ignore posts from Google. Use a real news client instead.

    JR
    --- Synchronet 3.18b-Win32 NewsLink 1.113