Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.portables > #1336 > unrolled thread

Who is going to buy the first Arm (M1) MacBooks?

Back to article view | Back to comp.sys.mac.portables

Contents

  Who is going to buy the first Arm (M1) MacBooks? ant@zimage.comANT (Ant) - 2020-11-11 14:46 -0600
    Re: Who is going to buy the first Arm (M1) MacBooks? Alan Baker <notonyourlife@no.no.no.no> - 2020-11-11 12:57 -0800
      Re: Who is going to buy the first Arm (M1) MacBooks? ant@zimage.comANT (Ant) - 2020-11-11 16:40 -0600
        Re: Who is going to buy the first Arm (M1) MacBooks? Tim <timstreater@greenbee.net> - 2020-11-11 22:45 +0000
          Re: Who is going to buy the first Arm (M1) MacBooks? ant@zimage.comANT (Ant) - 2020-11-11 20:00 -0600
            Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-11 21:06 -0500
            Re: Who is going to buy the first Arm (M1) MacBooks? Your Name <YourName@YourISP.com> - 2020-11-12 15:09 +1300
        Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-11 17:46 -0500
        Re: Who is going to buy the first Arm (M1) MacBooks? Alan Baker <notonyourlife@no.no.no.no> - 2020-11-11 15:27 -0800
          Re: Who is going to buy the first Arm (M1) MacBooks? Your Name <YourName@YourISP.com> - 2020-11-12 12:50 +1300
        Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-11 20:07 -0500
          Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-11 20:15 -0500
            Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-12 13:34 -0500
              Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-12 14:20 -0500
              Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-13 10:15 +0000
              Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-13 11:43 -0500
                Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-13 12:47 -0500
                Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-13 13:22 -0500
                  Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-13 15:40 -0500
            Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-12 14:00 -0500
              Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-12 14:21 -0500
                Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-13 02:13 -0500
                  Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-13 06:30 -0500
                    Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-13 15:43 +0000
                      Re: Who is going to buy the first Arm (M1) MacBooks? Jolly Roger <jollyroger@pobox.com> - 2020-11-13 16:42 +0000
                      Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-13 13:16 -0500
                        Re: Who is going to buy the first Arm (M1) MacBooks? Jolly Roger <jollyroger@pobox.com> - 2020-11-13 19:19 +0000
                        Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-13 20:18 +0000
                          Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-13 16:58 -0500
                            Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 00:51 +0000
              Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-13 11:45 -0500
            Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-13 11:27 -0500
          Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-12 14:56 +0000
        Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-12 14:54 +0000
    Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-11 22:22 +0000
      Re: Who is going to buy the first Arm (M1) MacBooks? Alan Baker <notonyourlife@no.no.no.no> - 2020-11-11 14:39 -0800
        Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-12 14:48 +0000
      Re: Who is going to buy the first Arm (M1) MacBooks? ant@zimage.comANT (Ant) - 2020-11-11 16:40 -0600
        Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-11 17:46 -0500
        Re: Who is going to buy the first Arm (M1) MacBooks? Tim <timstreater@greenbee.net> - 2020-11-11 22:46 +0000
        Re: Who is going to buy the first Arm (M1) MacBooks? Your Name <YourName@YourISP.com> - 2020-11-12 12:39 +1300
          Re: Who is going to buy the first Arm (M1) MacBooks? ant@zimage.comANT (Ant) - 2020-11-11 20:01 -0600
            Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-12 14:51 +0000
              Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-12 14:12 -0500
                Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-12 14:21 -0500
                  Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-13 11:56 -0500
                    Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-13 20:20 +0000
                      Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-13 15:47 -0500
                        Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 00:54 +0000
                          Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-13 20:06 -0500
                            Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 09:47 +0000
                              Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-14 05:21 -0500
                                Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-14 08:29 -0500
                                  Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-14 12:21 -0500
                                    Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-14 13:04 -0500
                                      Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-14 13:40 -0500
                                  Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-14 12:40 -0500
                                    Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-14 13:04 -0500
                                    Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-14 13:26 -0500
                                      Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-14 14:48 -0500
                                        Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-14 15:08 -0500
                                        Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-14 15:50 -0500
                                          Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-14 22:46 -0500
                                            Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-15 11:56 -0500
                                              Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-16 09:47 -0500
                                                Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-16 10:43 -0500
                                                  Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-16 17:25 -0500
                                                Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-16 15:48 +0000
                                                Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-16 14:01 -0500
                                                  Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-16 18:53 -0500
                                                    Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-16 21:33 -0500
                                                    Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-17 20:04 -0500
                                        Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 23:28 +0000
                                    Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 18:40 +0000
                                      Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-14 13:47 -0500
                                        Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-14 14:52 -0500
                                          Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-14 15:08 -0500
                                          Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 23:26 +0000
                                            Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-14 22:52 -0500
                                              Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-15 10:15 +0000
                                                Re: Who is going to buy the first Arm (M1) MacBooks? Your Name <YourName@YourISP.com> - 2020-11-16 09:05 +1300
                                              Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-15 08:09 -0500
                                              Re: Who is going to buy the first Arm (M1) MacBooks? nospam <nospam@nospam.invalid> - 2020-11-17 14:42 -0500
                                Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 14:04 +0000
                                Re: Who is going to buy the first Arm (M1) MacBooks? Jolly Roger <jollyroger@pobox.com> - 2020-11-14 15:41 +0000
                                  Re: Who is going to buy the first Arm (M1) MacBooks? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-11-14 12:46 -0500
                                    Re: Who is going to buy the first Arm (M1) MacBooks? Jolly Roger <jollyroger@pobox.com> - 2020-11-14 18:00 +0000
                          Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-14 09:30 -0500
                            Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 16:51 +0000
                              Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-14 12:12 -0500
                                Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 18:34 +0000
                                  Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-14 14:20 -0500
                                    Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-14 23:20 +0000
                                      Re: Who is going to buy the first Arm (M1) MacBooks? Alan Browne <bitbucket@blackhole.com> - 2020-11-14 19:39 -0500
                Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-13 10:12 +0000
        Re: Who is going to buy the first Arm (M1) MacBooks? Lewis <g.kreme@kreme.dont-email.me> - 2020-11-12 14:50 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#1347

On 2020-11-11 22:40:49 +0000, Ant said:
> In comp.sys.mac.system Lewis <g.kreme@kreme.dont-email.me> wrote:
>> In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant 
>> <ant@zimage.comANT> wrote:
>>> 
>>> So, who is going to buy the first Arm (M1) MacBooks? ;)
>> 
>> I am ordering a MBA as soon as I decide if I should increase the RAM or
>> not. It will be mostly for my wife who almost certainly doesn't need
>> 16GB, but I am torn.
> 
> Aren't the RAMs still soldered in? If so, then you might as well go as big as
> you can afford. Same for storage. :(

Yep. It is one of the biggest pain-in-the-backside points with Apple 
these days, especially considering Apple's over-pricing of RAM and 
storage drives.  :-(

[toc] | [prev] | [next] | [standalone]

#1352

In comp.sys.mac.hardware.misc Your Name <YourName@yourisp.com> wrote:
> On 2020-11-11 22:40:49 +0000, Ant said:
> > In comp.sys.mac.system Lewis <g.kreme@kreme.dont-email.me> wrote:
> >> In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant 
> >> <ant@zimage.comANT> wrote:
> >>> 
> >>> So, who is going to buy the first Arm (M1) MacBooks? ;)
> >> 
> >> I am ordering a MBA as soon as I decide if I should increase the RAM or
> >> not. It will be mostly for my wife who almost certainly doesn't need
> >> 16GB, but I am torn.
> > 
> > Aren't the RAMs still soldered in? If so, then you might as well go as big as
> > you can afford. Same for storage. :(

> Yep. It is one of the biggest pain-in-the-backside points with Apple 
> these days, especially considering Apple's over-pricing of RAM and 
> storage drives.  :-(

That's frustrating. :(
-- 
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| |
   \ _ /
    ( )

[toc] | [prev] | [next] | [standalone]

#1357

In message <VoydnTnDncvpCjHCnZ2dnUU7-dWdnZ2d@earthlink.com> Ant <ant@zimage.comANT> wrote:
> In comp.sys.mac.hardware.misc Your Name <YourName@yourisp.com> wrote:
>> On 2020-11-11 22:40:49 +0000, Ant said:
>> > In comp.sys.mac.system Lewis <g.kreme@kreme.dont-email.me> wrote:
>> >> In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant 
>> >> <ant@zimage.comANT> wrote:
>> >>> 
>> >>> So, who is going to buy the first Arm (M1) MacBooks? ;)
>> >> 
>> >> I am ordering a MBA as soon as I decide if I should increase the RAM or
>> >> not. It will be mostly for my wife who almost certainly doesn't need
>> >> 16GB, but I am torn.
>> > 
>> > Aren't the RAMs still soldered in? If so, then you might as well go as big as
>> > you can afford. Same for storage. :(

>> Yep. It is one of the biggest pain-in-the-backside points with Apple 
>> these days, especially considering Apple's over-pricing of RAM and 
>> storage drives.  :-(

> That's frustrating. :(

No it's not. It means the RAM is much faster and more tightly integrated
with the CPU and GPU and that much less needs to be moved around (for
one, no copying RAM from the "system" to the "GPU".


-- 
"Are you pondering what I'm pondering?"
"Wuh, I think so, Brain, but will they let the Cranberry Duchess stay
	in the Lincoln Bedroom?"

[toc] | [prev] | [next] | [standalone]

#1363

On 2020-11-12 09:51, Lewis wrote:

> No it's not. It means the RAM is much faster and more tightly integrated
> with the CPU and GPU and that much less needs to be moved around (for
> one, no copying RAM from the "system" to the "GPU".

Haven't verified this, but a friend pointed out thet PCI-express bus
speed is faster than DDR4 transfers.


With "normal" chips, you know how many channels to memory you have and
have the speed. So you can compare two systems's performance. (when you
have many cores, access to RAM can become the bottleneck so RAM
performance becomes important.

What sort of memery controller Apple uses will matter, especially when
you consider how many portions of the chip now have access to ram
separately (not just CPU cores, but alspo GPU cores, Secure enclave,
neural engine, IO controller etc).


Asll we know is "unified memory" which is meaningless marketing mumble
jumble.

It is only once independant testers riun standard benchmarks that we'll
have an idea of actual performance. Apple's keynote provided nothing of
value on performance. (look at their graphs, pretty lines, but no
scale/numbers for each axis).

Consider also that the Pro has a fan, the air doesn't. Yet, same CPU,
same OS. So it is very likely that the Air will be speed throttled due
to heat while the Pro will see better performance when doing lengthy work.

And it will make for interesting benchmark logic because you have cores
of different speeds. The 4 slow cores will slow down the average of the
4 fast ones.

[toc] | [prev] | [next] | [standalone]

#1366

In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:

> Asll we know is "unified memory" which is meaningless marketing mumble
> jumble.

nonsense.

[toc] | [prev] | [next] | [standalone]

#1376

On 2020-11-12 14:21, nospam wrote:
> In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
> <jfmezei.spamnot@vaxination.ca> wrote:
> 
>> Asll we know is "unified memory" which is meaningless marketing mumble
>> jumble.
> 
> nonsense.

It is marketing speak to a degree.  Per a Wikipedia article[1] the SOC 
uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the 
SOC.  Still needs a memory manager though that may be more deeply 
integrated in the CPU; likely has DMA of some kind, esp. for the GPU, 
but other I/O as well.

[1] that source has no reference so I declare escape clause.  But it's a 
good bet if someone has seen that in System Info declared as such on the 
many, many developer systems out there.

-- 
"...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

[toc] | [prev] | [next] | [standalone]

#1382

In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
> On 2020-11-12 14:21, nospam wrote:
>> In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
>> <jfmezei.spamnot@vaxination.ca> wrote:
>> 
>>> Asll we know is "unified memory" which is meaningless marketing mumble
>>> jumble.
>> 
>> nonsense.

> It is marketing speak to a degree.  Per a Wikipedia article[1] the SOC 
> uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the 
> SOC.  Still needs a memory manager though that may be more deeply 
> integrated in the CPU; likely has DMA of some kind, esp. for the GPU, 
> but other I/O as well.

> [1] that source has no reference so I declare escape clause.  But it's a 
> good bet if someone has seen that in System Info declared as such on the 
> many, many developer systems out there.

What many many developer systems out there?

(The DTK is not an M1 machine).


-- 
This is not a movie I saw, this is a dream I had. --Steven Wright

[toc] | [prev] | [next] | [standalone]

#1384

On 2020-11-13 15:20, Lewis wrote:
> In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
>> On 2020-11-12 14:21, nospam wrote:
>>> In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
>>> <jfmezei.spamnot@vaxination.ca> wrote:
>>>
>>>> Asll we know is "unified memory" which is meaningless marketing mumble
>>>> jumble.
>>>
>>> nonsense.
> 
>> It is marketing speak to a degree.  Per a Wikipedia article[1] the SOC
>> uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the
>> SOC.  Still needs a memory manager though that may be more deeply
>> integrated in the CPU; likely has DMA of some kind, esp. for the GPU,
>> but other I/O as well.
> 
>> [1] that source has no reference so I declare escape clause.  But it's a
>> good bet if someone has seen that in System Info declared as such on the
>> many, many developer systems out there.
> 
> What many many developer systems out there?

Thousands...

> 
> (The DTK is not an M1 machine).

I assumed it was.  Nevertheless, the use of the memory model cited above 
is quite possible and that that part of the fab is supplied by the chip 
maker whether on the same wafer or other.

And/or that someone made the same assumption that I did about the memory 
found on the dev kit.

-- 
"...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

[toc] | [prev] | [next] | [standalone]

#1387

In message <HhCrH.320247$GQ4.306084@fx02.iad> Alan Browne <bitbucket@blackhole.com> wrote:
> On 2020-11-13 15:20, Lewis wrote:
>> In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
>>> On 2020-11-12 14:21, nospam wrote:
>>>> In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
>>>> <jfmezei.spamnot@vaxination.ca> wrote:
>>>>
>>>>> Asll we know is "unified memory" which is meaningless marketing mumble
>>>>> jumble.
>>>>
>>>> nonsense.
>> 
>>> It is marketing speak to a degree.  Per a Wikipedia article[1] the SOC
>>> uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the
>>> SOC.  Still needs a memory manager though that may be more deeply
>>> integrated in the CPU; likely has DMA of some kind, esp. for the GPU,
>>> but other I/O as well.
>> 
>>> [1] that source has no reference so I declare escape clause.  But it's a
>>> good bet if someone has seen that in System Info declared as such on the
>>> many, many developer systems out there.
>> 
>> What many many developer systems out there?

> Thousands...

Nonsense.

>> (The DTK is not an M1 machine).

> I assumed it was.

You assumed wrong. As was detailed at the time it is a A12X. Literally
an iPad chip. It does not have unified memory. It does not have
USB-4/TB. It is not the same chip *at all*

> Nevertheless, the use of the memory model cited above is quite
> possible and that that part of the fab is supplied by the chip maker
> whether on the same wafer or other.

The chip maker supplies exactly what Apple designed, nothing more,
nothing less.

> And/or that someone made the same assumption that I did about the memory 
> found on the dev kit.

And that person was equally wrong.



-- 
Lead me not into temptation, I can find the way.

[toc] | [prev] | [next] | [standalone]

#1388

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

> 
> >> (The DTK is not an M1 machine).
> 
> > I assumed it was.
> 
> You assumed wrong. As was detailed at the time it is a A12X. Literally
> an iPad chip. It does not have unified memory. It does not have
> USB-4/TB. It is not the same chip *at all*

actually, it was an a12z. it was basically an ipad in a mac mini box.
which is good enough for development work.

[toc] | [prev] | [next] | [standalone]

#1389

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

>> 
>> >> (The DTK is not an M1 machine).
>> 
>> > I assumed it was.
>> 
>> You assumed wrong. As was detailed at the time it is a A12X. Literally
>> an iPad chip. It does not have unified memory. It does not have
>> USB-4/TB. It is not the same chip *at all*

> actually, it was an a12z. 

Yes, which differed from the A12X in that it had one more GPU core.

> it was basically an ipad in a mac mini box.

Very much so. I know several people who had them.

> which is good enough for development work.

Yeo, especially considering how simple the transition from Intel to ARM
was for the developers (One spent several days porting, but the others
did their ports in under a day and one spent less than 15 minutes).

The rest of their summer was spent figuring out what fun new things they
could do.

-- 
Anybody who could duck the Vietnam war can certainly duck a couple of
	shoes.

[toc] | [prev] | [next] | [standalone]

#1390

On 2020-11-14 04:47, Lewis wrote:

> Yeo, especially considering how simple the transition from Intel to ARM
> was for the developers (One spent several days porting, but the others
> did their ports in under a day and one spent less than 15 minutes).


Simple enough that it will take months more for Adobe to release native
Photoshop.

If you want to create binaries that make use of the new various
sub-processors like neural engine, image processor etc, support the
integrated GPUs etc, you need to start putting in a lot of conditional
code that applies only for a compilation targetted at the Mx chips, and
still generate your normal code for all other platforms.

Remains to be seen how much use Adobe will make the the proprietary
processors around he CPU, and how much Metal/GPU they will use.

It is also possible that merely recompiling wouldn't have yielded
marketable performance.

It is also possible that Adobe is waiting for usable Macs (aka: next
models with more RAM) and the delay has nothing to do with the porting
effort.

[toc] | [prev] | [next] | [standalone]

#1391

In article <kcOrH.306825$mK4.71532@fx03.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:

> 
> > Yeo, especially considering how simple the transition from Intel to ARM
> > was for the developers (One spent several days porting, but the others
> > did their ports in under a day and one spent less than 15 minutes).
> 
> 
> Simple enough that it will take months more for Adobe to release native
> Photoshop.

photoshop is a very complex app, with some core routines in assembly
that are hand tuned to specific versions of processors.


> If you want to create binaries that make use of the new various
> sub-processors like neural engine, image processor etc, support the
> integrated GPUs etc, you need to start putting in a lot of conditional
> code that applies only for a compilation targetted at the Mx chips, and
> still generate your normal code for all other platforms.
> 
> Remains to be seen how much use Adobe will make the the proprietary
> processors around he CPU, and how much Metal/GPU they will use.

photoshop is cross platform, so any change they make to the mac version
must also be done for the windows version so that the results are
identical for both. 

> It is also possible that merely recompiling wouldn't have yielded
> marketable performance.

given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.

> It is also possible that Adobe is waiting for usable Macs (aka: next
> models with more RAM) and the delay has nothing to do with the porting
> effort.

no.

[toc] | [prev] | [next] | [standalone]

#1397

On 2020-11-14 08:29, nospam wrote:

> photoshop is a very complex app, with some core routines in assembly
> that are hand tuned to specific versions of processors.
<s>
> 
> given that portions of photoshop are x86 assembly, it would be
> impossible to 'merely recompile' it.

Such can be done with translation tools (_x86 -> ARM assembler). 
They've possibly developed or acquired such for their iOS products.

The ARM 64 bit register set will offer a lot more opportunity to keep 
more data in register rather than on stack which will help functions 
blaze v. x86.

x86: 16 x 64b registers.

ARM_64:	31 x 64b - though the ARM procedure calling convention allocates 
several specifically.  Apple follow that convention to a large degree 
but have their own "guideline" for some register use and specifically 
reserve x18 and x29.  Apple also have slightly different stack/register 
conventions/alignments/restrictions than ARM.

-- 
"...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

[toc] | [prev] | [next] | [standalone]

#1402

In article <WmUrH.138317$nI.132802@fx21.iad>, Alan Browne
<bitbucket@blackhole.com> wrote:

> 
> > photoshop is a very complex app, with some core routines in assembly
> > that are hand tuned to specific versions of processors.
> <s>
> > 
> > given that portions of photoshop are x86 assembly, it would be
> > impossible to 'merely recompile' it.
> 
> Such can be done with translation tools (_x86 -> ARM assembler). 
> They've possibly developed or acquired such for their iOS products.

it can, but it would not be anywhere close to optimal.

adobe tweaks their core routines not just for i5/i7, but different
variants, which is one reason why photoshop is one of the fastest image
processing apps.

[toc] | [prev] | [next] | [standalone]

#1406

On 2020-11-14 13:04, nospam wrote:
> In article <WmUrH.138317$nI.132802@fx21.iad>, Alan Browne
> <bitbucket@blackhole.com> wrote:
> 
>>
>>> photoshop is a very complex app, with some core routines in assembly
>>> that are hand tuned to specific versions of processors.
>> <s>
>>>
>>> given that portions of photoshop are x86 assembly, it would be
>>> impossible to 'merely recompile' it.
>>
>> Such can be done with translation tools (_x86 -> ARM assembler).
>> They've possibly developed or acquired such for their iOS products.
> 
> it can, but it would not be anywhere close to optimal.

Why I said "possible".  Further, when going forward (architecture) it's 
easier to build optimization into the translation process.

It's also a good way to get the project ahead, validate the result, and 
then "hand optimize" the result in successive rounds.

-- 
"...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

[toc] | [prev] | [next] | [standalone]

#1398

On 2020-11-14 08:29, nospam wrote:

> given that portions of photoshop are x86 assembly, it would be
> impossible to 'merely recompile' it.

Surprised at that allegation since Photoshop used to run on 68k, PowerPC
and 32 bit 8086s.


The GPUs take in C++ code (or variant thereof). And x86 code isn't
optimized, so generally only used for low level hardware interfaces.

It wasn't that long ago that you and your ilk even refised to admit that
OS-X would have any assembly language, and now you state Photoshop (a
user mode application) has assembler.

Depending on demand, there might be an x26 assembler  *compiler* which
would then generate optimised ARM opcodes.

When Digital did the migration from VAX to Alpha, it found itself with a
LOT of VAX assembler code (Macro) and decided to create a Macro compiler
that generated optimized  Alpha binaries.  This prevented the need to
rewrite many of the older apps.

However, I suspect the amount of x86 assembler in the OS-X ecosystem is
really not sufficient to warrant developing such a compiler.  The
assembler portions in OS-X would be very low level and hace to be
rewritten to the new ARM environment (device interfaces etc) so a
compiler not very useful.

[toc] | [prev] | [next] | [standalone]

#1401

In article <jEUrH.365302$5_4.50688@fx40.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:

> 
> > given that portions of photoshop are x86 assembly, it would be
> > impossible to 'merely recompile' it.
> 
> Surprised at that allegation since Photoshop used to run on 68k, PowerPC
> and 32 bit 8086s.

obviously, the 68k and powerpc versions of photoshop had 68k and
powerpc assembly in them. this is not a difficult concept.

photoshop has been intel-only for over a decade, thus there is no 68k
or powerpc code anywhere to be found anymore. also not a difficult
concept.

> The GPUs take in C++ code (or variant thereof). And x86 code isn't
> optimized, so generally only used for low level hardware interfaces.
> 
> It wasn't that long ago that you and your ilk even refised to admit that
> OS-X would have any assembly language, and now you state Photoshop (a
> user mode application) has assembler.

i never said any such thing.

> Depending on demand, there might be an x26 assembler  *compiler* which
> would then generate optimised ARM opcodes.
> 
> When Digital did the migration from VAX to Alpha, 

there you go again...

[toc] | [prev] | [next] | [standalone]

#1403

On 2020-11-14 12:40, JF Mezei wrote:
> On 2020-11-14 08:29, nospam wrote:
> 
>> given that portions of photoshop are x86 assembly, it would be
>> impossible to 'merely recompile' it.
> 
> Surprised at that allegation since Photoshop used to run on 68k, PowerPC
> and 32 bit 8086s.

Pretty irrelevant.  Going forward at least, assembler for one 
architecture is pretty quickly converted to almost any other.  As 
architectures evolve it just gets easier as register sets expand and 
opcodes provide more options to do operations in fewer instructions.

> The GPUs take in C++ code (or variant thereof). And x86 code isn't
> optimized, so generally only used for low level hardware interfaces.

Not at all.  In treating large sets of integer values (which is what a 
digital image is "made of"), assembler offers many ways to do many 
things very efficiently and further allows for the ultimate of 
optimization and clever tricks that are not expressable efficiently in 
high level language.   This can even include FP ops with opportunistic 
avoidance of FWAIT if one takes extraordinary care.

On the other side of that dime, h/w control is now rarely implemented in 
assembler because the HOL's provide ample read/write to control 
registers and of course memory mapped I/O.  Tossup whether assembler or 
HOL is better, actually.  For hardware makers this is even preferred as 
they don't have to worry about what architecture and often even OS that 
a driver will run on.  Minor tweaks at most (and taken care via pragmas 
in the source code).

> It wasn't that long ago that you and your ilk even refised to admit that
> OS-X would have any assembly language, and now you state Photoshop (a
> user mode application) has assembler.

The OS can be 100% in C (or whatever mix) and apps can be 100% in 
assembler if need be, though usually limited to where needed.  Not 
saying Mac OS is assembler free, but as time has gone on, Apple have 
reduced that to bare minimum.

> Depending on demand, there might be an x26 assembler  *compiler* which
> would then generate optimised ARM opcodes.

x26 assembler? Eh?  *compiler*?  Do you mean translator or converter? 
Sure.  Quite plausible.

> When Digital did the migration from VAX to Alpha,
<S>
... get over it already.

> However, I suspect the amount of x86 assembler in the OS-X ecosystem is
> really not sufficient to warrant developing such a compiler.  The
> assembler portions in OS-X would be very low level and hace to be
> rewritten to the new ARM environment (device interfaces etc) so a
> compiler not very useful.

You mean translator.  Who knows.  I'd lean more to Apple simply 
re-writing the assembler portions for best efficiency since there is, 
ultimately, not that much assembler left in Apple OS'.  So might well 
rewrite the little bit there is as tightly as possible.  Esp. as 
portions of the OS are common to watch and presumably AirTag where 
energy use is most important.

The ARM assembler is available and Apple expressly provide their 
guidelines to developers for using ARM assembly language for Mac OS (and 
iOS and tvOS).  I didn't see iPad OS or Watch OS in there but assume the 
same guidance applies.  I assume that ARMs assembler is invokable from 
XCode but if not the assembler output object code certainly can be 
linked.  You need to follow ARM calling conventions with the Apple 
exceptions of course.

-- 
"...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

[toc] | [prev] | [next] | [standalone]

#1409

On 2020-11-14 13:26, Alan Browne wrote:

> Not at all.  In treating large sets of integer values (which is what a 
> digital image is "made of"), assembler offers many ways to do many 
> things very efficiently and further allows for the ultimate of 
> optimization and clever tricks that are not expressable efficiently in 
> high level language. 

When moving to RISC, this changes the equation because of the large
number of optomizations possible buy re-ordering of opcodes to allow the
chip to make best use of pipeline, branch prediction and other
perofrmance techniques.

And Assembler, by definition, generates opcodes that match your code
both in nature and order.  No optimizatiosn possible.

However, when a chip has an instruction to decode an H.264 stream for
instance, it can be more efficient to use assembler to use that
instriuction vs writing your own in higher level language that gets
optimized.


> x26 assembler? Eh?  *compiler*?  Do you mean translator or converter? 
> Sure.  Quite plausible.

COMPILER.  The compiler treats the source as high level language and
does the optimization, re-ordering of the code to fit the target
archictecture.  A translator merely translates already compiled code
without trying to understand the code and optmize it.

Rosetta 2 is a translator that takes code optimized for 8086 and
translates it to multiple ARM instructions that do the same whereas
recompiling will optimise the binary to run on ARM.

This is why Digital did a compiler for its Macro assembler when moving
platform so that the CISC VAX instructions would not only be translated
into a bunch of RISC instructions but could also optmize sets of
instructiosn just as any 3rd level language is optimized.


> ... get over it already.

So you refuse to discuss experiences of other ports and wish to keep
your head in sand and and blindly drink Apple's kool aid.


> You mean translator.

For applicationn where performance counts, I mean COMPILER. Where low
level code is truly needed, assembler is used because you can't optimize
it and it needs to be rewritten from scratch because handling of device
drivers, the types of io interfaces etc all very different.

In the case of OS-X, much already exists from IOS, so much could be
re-used, but there is still code needed for the new thunderbolt/USB-4
drivers and all the variants attached to it, including ethernet drivers
attached to the new thunderbolt/USB-4 IO interface.




> The ARM assembler is available and Apple expressly provide their 
> guidelines to developers for using ARM assembly language 

I am sure it is. But when targetting a RISC platform, assembly language
is much harder to beat efficieny of higher level languages because of
compiler and LLVM optimizations which know about how that CPU does
instruction pre-fetching, pipelining, branch prediction, etc.

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.sys.mac.portables

csiph-web