[HN Gopher] Undocumented arm64 ISA extension present on the Appl...
___________________________________________________________________
Undocumented arm64 ISA extension present on the Apple M1
Author : ytch
Score : 166 points
Date : 2020-12-28 13:51 UTC (9 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| hyperpallium2 wrote:
| After four different CPU ISA's (68000, powerpc, x86, ARM) an
| Apple ISA is next.
| duskwuff wrote:
| Apple was actually considering designing their own CPUs as
| early in the mid/late 80s. As far as I'm aware, they never got
| to the point of fabrication, but the architecture and ISA was
| pretty fully fleshed out:
|
| https://archive.org/details/scorpius_architecture
| Teongot wrote:
| There's a tidy mathematical progression in Apple CPU
| architectures.
|
| 6502 (Apple 1,2,3): 1976
|
| 68k (Mac): 1984 (+8 years)
|
| PPC: 1994 (+10 years)
|
| x86: 2006 (+12 years)
|
| ARM: 2020 (+14 years)
|
| If the trend continues, we will see Apple's next architecture
| in 2036.
| ithkuil wrote:
| 2036, Apple Mill
| mhh__ wrote:
| Well, the people behind the Mill might not being around in
| 16 years time.
|
| That being said, I would really like to see the Mill make
| it to Silicon - even if it doesn't work in the end, it's
| much more interesting to me than RISC-V.
| bitwize wrote:
| From a third-party developer's perspective the ISA will be
| Swift.
|
| The actual CPU ISA will be a closely guarded trade secret. It
| will, however, run Swift code 2-3x faster (on a single-core
| basis) than any commercially available commodity CPU --
| especially since Apple pays silicon fabs to _not_ manufacture
| 3nm hypercubic gallium-arsenide ICs or whatever the cutting
| edge is on behalf of competitors.
| rasz wrote:
| :) reminds me of
| https://www.destroyallsoftware.com/talks/the-birth-and-
| death...
| klelatti wrote:
| I assume this is satire.
| stephc_int13 wrote:
| I hate Apple for that. They very often use non-standard tech and
| we'll end up with Apple proprietary processors instead of the
| standard stuff x64/ARM64.
| lwhi wrote:
| I don't understand the significance of this.
|
| Could someone who does add some context?
| vegetablepotpie wrote:
| Apple added custom instructions on top of the ARM instruction
| set to do matrix operations.
|
| Matrix operations are used _a lot_ in some algorithms, such as
| in computer graphics and machine learning and these
| instructions help those operations go faster.
|
| Although the ARM ISA has a multiply and accumulate instruction,
| it would take many more instructions on a standard ARM core to
| compute a matrix with only standard instructions. That enables
| the M1 chip to be faster in this case when developers use these
| instructions in their applications.
| giantrobot wrote:
| > That enables the M1 chip to be faster in this case when
| developers use these instructions in their applications.
|
| Or more typically the _compiler_ will emit those instructions
| and everyone gets them for free.
| teknopaul wrote:
| only if the compiler knows they exist
| a1369209993 wrote:
| That's actually generally _not_ true WRT SIMD /vector
| instructions (see eg http://yosefk.com/blog/humans-and-
| compilers-need-each-other-... which contrasts this with the
| more compiler-friendly VLIW case); they impose nontrivial
| requirements on data structures and ABI, so the application
| code needs to at least be aware of the _possibility_ of
| vectorization, even if it 's agnostic to whether the
| implementation actually uses it.
| floatingatoll wrote:
| Correction:
|
| ^when applications use these instructions; either as a result
| of use of a system API/framework, of the compiler optimizing
| code into these M1 instructions, or of the developer writing
| M1 assembler themselves.
|
| It is very likely that the majority of cases that use these
| instructions will be compiled by Xcode without the knowledge
| of developers that these instructions exist at all.
| 2wrist wrote:
| Similar to Altivec from the PowerPC days?
| ericlewis wrote:
| From what I can tell reading this: the Accelerate framework
| from Apple seems to use custom instructions possibly unique to
| the M1 chip but potentially similar to Intel AMX. Accelerate
| is, as I sort of understand it- a way to do advanced math in a
| very quick / power efficient way. It is touted as deeply
| integrated with Apple processors from the day it launched and
| (I think) even recommended to be used over SIMD and the sort (I
| could certainly be very wrong about this). It dove tails with
| some of the machine learning work Apple did as well, is
| portable among Apple systems, and can be assumed to be
| optimized.
|
| Ninja edit: I've not seen how it was achieved until now, but a
| custom ISA extension isn't wholly surprising.
|
| Edit 2: as for why this is significant.. I'm not sure it is. It
| is interesting to know how Accelerate can pull off what it does
| though. IIRC there are other machine learning frameworks which
| take advantage of the neural engine- but Accelerate possibly
| doesn't- despite having machine learning capabilities.
| Lammy wrote:
| It also means that any binaries built to use those
| instructions won't run on any non-Apple ARM64 CPUs, at least
| not easily. Sort of like how early-era Intel Hackintosh users
| had to have CPUs with SSE3 support or wait/hope for SSE2
| patches.
| ericlewis wrote:
| I'm relatively sure that Accelerate does work fine on intel
| processors and is still the recommended means of doing
| heavy math. But that could just be because they knew of
| this eventual future. I'm not sure what Accelerate does
| under the hood for intel machines. But I would assume
| perhaps falls back to whatever intel might support.
| giantrobot wrote:
| Say hello to Function Multi-versioning [0]. You tell the
| compiler to build a version for each march defined in the
| attribute. When that function is called a quick CPU check
| (via CPUID) is performed and if there's a version specific to
| the current CPU that will run instead of the more general
| implementation. ICC has supported this for a long time and
| it's widely used in Intel's MKL.
|
| LLVM also supports FMV but uses a slightly different method
| to define it in code. IIRC there was an LLVM issue tracking
| work to support GCC's way of declaring FMV but I don't know
| if that landed yet.
|
| Since the function's signature is the same between the
| multiple implementations the caller doesn't need to change of
| their code to get a free boost from features like AVX2 or
| these M1 instructions. When an M2 comes out with better
| vector instructions or something and a new Accelerate
| framework is released, anyone using the framework get a free
| performance increase without recompiling anything.
|
| [0] https://lwn.net/Articles/691932/
| ChuckMcM wrote:
| Like Intel, Apple has chosen to add some instructions to the
| processor which accelerate certain operations (in this case
| matrix operations). Unlike Intel, Apple has not yet chosen to
| actually document the M1 architecture. This is where a
| vertically integrated company like Apple (or IBM back in the
| day) can leverage "inside knowledge" about their chips to
| achieve performance that is not readily comparable (or
| reproducible) on a different instruction set architecture
| (ISA).
|
| Historically (see IBM vs Memorex) obscuring your interfaces has
| been a losing proposition in the long term, even while
| delivering favorable margins in the short term. Unlike Intel
| which needs to get third parties to write software for their
| chips, Apple writes their own software and so it means they can
| hold on to their advantage while third parties (like the author
| of the post) reverse engineer what is going on.
|
| It will be "historically significant" if Intel adds a feature
| to their chips in order to stay competitive with this
| development. The last time they did that was when AMD
| introduced Opteron. All in all, its basically just a puzzle
| that people who are interested in how things work get to work
| on in their spare time.
| joseph_grobbles wrote:
| Apple added special AMX instructions specifically for matrix
| operations. They added them back with the A13, and then
| improved them for the M1. These are primarily focused on
| machine learning _training_ where you do backpropagation
| through huge matrix operations.
|
| They provide a very wide coverage library set that works on all
| supported platforms optimally. You interact with AMX through
| those libraries, and direct usage is considered unsupported.
| Apple may completely change it with the next iteration, where
| they can just change those libraries and every arm's-length
| application will get those benefits for free.
|
| Apple sells whole systems. They aren't selling CPUs for third
| parties, and there is no reason they need to encourage their
| own proprietary extensions. Indeed, it would be more evil if
| they were asking people to pepper their own code with this,
| instead of just using libraries that abstract you from the
| magic.
|
| As a tiny, tiny vendor in the computing space -- as HN often
| assures us -- I'm not seeing the great evil many are claiming.
|
| (indeed, of course this is downvoted but I chuckle that another
| comment implores that Apple is evil because this will lead to
| code and binaries that only work on Apple devices. Which is
| quite literally _exactly the opposite_ of what Apple is doing,
| which is forcing use through optimized libraries, abstracting
| from their own proprietary extensions. People just love
| bitching)
| notretarded wrote:
| >These are primarily focused on machine learning training
| where you do backpropagation through huge matrix operations
|
| How is this different from normal matrix operations?
| joseph_grobbles wrote:
| Scale, and only scale. As with most extensions, there's
| negative value if you're doing a small number of calcs, but
| it pays off in larger needs like ML training.
|
| We've been calculating matrixes for time eternal, but AMX
| has just recently become a thing. Intel just introduced
| their own AMX instructions.
| jonathonf wrote:
| From my limited understanding: it looks like a matrix
| coprocessor, and implies that hardware-accelerated matrix
| processing has been built into the M1.
|
| Matrix processing comes in useful for AI/ML/CV-type
| applications. It's something GPUs are generally very good for.
| mhh__ wrote:
| In the bigger picture Apple aren't really documenting anything
| for their new toys, which is not the end of the world but is a
| huge step back for openness. There is - as far as I can see -
| _no_ long-form documentation for M1 other than patents.
|
| I already refuse to own apple products so I don't really have
| any skin in the game, but consider that if microsoft were like
| this the blind eye would not be turned - buy our new product,
| everything you run is up to us, we won't document it, maybe
| we'll upstream the compiler, tough shit.
|
| The fact that they can be like this is really proof that their
| market position is much stronger than most HNers seem to think
| it is.
| EricE wrote:
| Or maybe different people have different needs and don't care
| if every device is "open".
|
| The vast majority of people are not enamored with technology
| for technologies sake. These are tools. Does the tool do what
| I want with the least amount of friction? That's what they
| care about.
|
| Also how does Apples stance on one product in any way change
| the device you are using to post in any way? Are Apple thugs
| coming to your house destroying non-Apple tech? Of course
| not!
|
| It always amuses me how Apple can simultaneously be
| irrelevant due to their market share and also be the greatest
| threat to open computing by their temerity at daring to have
| different computing models.
|
| If you don't like their computing model then don't use it.
| Railing that they aren't supporting your vision lockstep is
| pretty freaking arrogant.
|
| Their market position is strong because they provide value
| that people desire. The market is not a zero sum game. Apples
| mere existence does diminish your computing experience.
| Indeed Apples existence and continually pushing computing in
| new areas has benefited everyone in the last 40 years -
| whether you use Apple or not. Just think where computing
| would be of the attitude that you were only a real computer
| user if you assembled it - at the component to board level,
| not just bolting pre-mad parts to a pre-made case -
| persisted? People criticized Apple for selling complete
| computers with the Apple II.
|
| Your complaint isn't that different.
| ksk wrote:
| >If you don't like their computing model then don't use it.
| Railing that they aren't supporting your vision lockstep is
| pretty freaking arrogant.
|
| If you don't like/agree/see value in this persons comment
| then why are you engaging with them? That's how silly your
| position sounds.
|
| Now back to the substance of your comment.
|
| >Or maybe different people have different needs and don't
| care if every device is "open".
|
| How could "not open" be a need of someone?
|
| >These are tools. Does the tool do what I want with the
| least amount of friction? That's what they care about.
|
| How does an Apple engineer documenting the design add
| friction in any way to what you're doing?
|
| > Indeed Apples existence and continually pushing computing
| in new areas has benefited everyone in the last 40 years -
| whether you use Apple or not.
|
| Apple has helped popularize the smartphone as a consumer
| device to consume music/media, do light business on
| (emails, IM, documents, etc) and do a few minor creative
| tasks digitally such as drawing, music, etc. They do get a
| lot of credit for that. They have also co-created an
| application platform for other businesses to sell software.
| But then they robbed 30% of their sales too - They get
| negative credit for being so greedy.
|
| Your argument that they have "continually pushed computing"
| is a bit of a stretch. Give us your best
| argument/examples/facts.
| mhh__ wrote:
| > Or maybe different people have different needs and don't
| care if every device is "open".
|
| Just because Apple are boiling the frog doesn't make it a
| good thing.
| joosters wrote:
| A terrible analogy, they aren't hurting anybody,
| something which would be fundamentally wrong. A better
| analogy would be that Apple is baking bread in a way that
| you don't like. Which is only a problem if you are forced
| to eat it.
| mhh__ wrote:
| > A terrible analogy, they aren't hurting anybody,
|
| Hence the term boiling the frog. If _everyone_ bakes
| their bread like this, and they definitely wish they
| could, that would be bad.
| joosters wrote:
| >> A terrible analogy, they aren't hurting anybody,
|
| > Hence the term boiling the frog
|
| Tell that to the frog!
| segfaultbuserr wrote:
| > _If you don't like their computing model then don't use
| it. Railing that they aren't supporting your vision
| lockstep is pretty freaking arrogant._
|
| Alternatively, try to learn more about it by reverse
| engineering, which is what this article is all about.
| sharken wrote:
| As someone who was actually thinking about getting the M1
| based on the great performance and battery life, but without
| any actual use for it, I can see what you mean.
|
| But the lack of openness is enough to stop those ideas, a new
| Surface laptop or next generation AMD mobile is much more
| useful.
|
| I just hope that a battery life breakthrough is on the
| horizon from AMD or Intel.
| selectodude wrote:
| >I just hope that a battery life breakthrough is on the
| horizon from AMD or Intel.
|
| Intel has their Lakefield chips which use the same
| big.LITTLE configuration but their first large release
| chips will be Alder Lake next year.
|
| My concern is less with Intel and AMD's ability to
| implement the cores as much as Microsoft's ability to
| implement a scheduler. They never came to grips with the
| weirdness of AMD's Bulldozer architecture.
| api wrote:
| Process node is a large part of it. Fab a Ryzen at 5nm and
| it will at least be in the ballpark, though X64 decode
| complexity makes it hard to completely close the gap.
|
| There is also nothing stopping someone else from matching
| or beating M1 performance with another ARM64 core or
| RISC-V. Both of those have simple easy to parallelize
| decoders. It will be done if there is demand. AMD, Marvell,
| Qualcomm, and Intel all have the expertise to do it.
| Probably TI too if they wanted to reenter the CPU market.
| klelatti wrote:
| I think you have to look beyond 'technical' ability and
| factor in commercial incentives: like who would be buying
| these CPUs and how many? Zero chance of an AMD or Intel
| ARM core like this in the near future. Marvell have
| pulled out of the Arm server market IIRC. Qualcomm a
| possibility but they have underwhelmed in the past.
|
| Nvidia would be my favourite post the Arm acquisition but
| they probably have their eye on other markets.
| MichaelZuo wrote:
| The implication I assume that there would be pushback on
| Microsoft for doing the same would be because of the
| possibility of nefarious undocumented changes. What possibly
| nefarious things could an undocumented ISA extension do?
| hyperman1 wrote:
| Presumably the next iteration of the processor can remove
| them and use the opcodes for something else. Apple
| recompiles their system library, hence is unaffected. You
| can't do the same so peak M1 performance is unavailable for
| you.
| MichaelZuo wrote:
| Could those opcodes then be used for anything nefarious,
| or would it just restrict third parties from fully
| utilizing the processor?
| Someone wrote:
| If you think Apple wants to do something nefarious to
| users of their hardware, don't buy or use it.
|
| If they can't be trusted, they don't need to add opcodes.
| MichaelZuo wrote:
| Well the point of the question is trying to establish if
| it's even possible in the first place. If there is no
| credible way, then there is no need to fear there are
| nefarious reasons for implementing such a change for
| either Apple or Microsoft, outside of restricting third
| parties. If there is, then it's as you say.
| mhh__ wrote:
| _Undocumented_
|
| It's not about EEE it's about Apple taking this attitude in
| the first place.
| tenebrisalietum wrote:
| Apple can make tools that use the undocumented ISA, which
| they don't have to release to the public, potentially using
| it to develop applications with performance advantages that
| no one other than Apple can attain.
|
| It's similar to how Microsoft doesn't make all APIs on
| Windows public and uses non-public ones for various reasons
| --except this is in hardware.
|
| It's possible the undocumented ISA is used to speed up x86
| emulation and might be kept secret due to intellectual
| property concerns or similar.
| emteycz wrote:
| They didn't have to open the platform for other software
| (OS) at all. Let's be happy with what we got.
| _underfl0w_ wrote:
| > Let's be happy with what we got.
|
| Ouch. It's exactly this mentality that enables malicious
| actors - "it could be worse". It could always be worse,
| but that doesn't make it sufficient justification.
|
| Functional equivalent: "It could always be _even more_
| anticompetitive. Let 's be happy with what we got."
| emteycz wrote:
| Eh, _what_? What malicious actors? What sufficient
| justification, and justification of what and to whom?
| What could be worse? What could be more anticompetitive,
| and competing with what exactly? I said nothing like
| this, your "equivalents" are from an entirely different
| world.
|
| I said we should be happy Apple decided to open their
| platform - because they didn't have to, at all. It's
| entirely their right to not open anything, not write any
| documentation, or not even allow 3rd party software at
| all. If you don't like it, don't buy their overpriced
| premium products - it's not for you. I wouldn't want my
| own company to be forced to do/not do stuff, so of course
| I don't wish that upon Apple. There are enough entirely
| open computing platforms that are VERY cheap to obtain
| and easy to use, perhaps that would be a better choice
| for you.
| _underfl0w_ wrote:
| Meh, nothing serious, just that the "it could be worse"
| line of thinking can be a little dangerous if broadly
| applied since it could _always_ be at least marginally
| worse, that 's all I meant.
|
| Completely agree about forcing them to do or avoid
| strategies, though governing bodies may disagree!
|
| Jokes aside, it seems that despite occasional
| marketing/rhetoric from Apple, their platform represents
| the minimum bound of "openness". It's only open enough to
| allow further business - e.g. allowing 3rd parties to
| develop apps in the store (from which they take a cut of
| proceeds) - rather than being open for the spirit of it,
| if that makes any sense.
|
| They _are a business_ so that 's not exactly something
| one could fault them for, though.
| emteycz wrote:
| Yes, what I am saying is that we can't fault them for
| being a business. We should be looking for our open
| computing platform elsewhere - I think there is more than
| enough options. If a supposedly "open" platform wasn't
| open then that would be bad, but Apple is about something
| different - offering a premium vertically integrated
| product for people that don't even know what a CPU or OS
| is. If they were forced to open their platform it is very
| much possible there wouldn't be any Apple platform at
| all, and I don't want that kind of world.
|
| > though governing bodies may disagree!
|
| That's why I am reacting so strongly. If people begin to
| apply your thinking too broadly (e.g. to businesses like
| Apple) it will lead to governing bodies behaving like
| that. Let's apply this kind of thinking to platforms that
| claim to be open.
| user-the-name wrote:
| > Apple can make tools that use the undocumented ISA,
| which they don't have to release to the public,
| potentially using it to develop applications with
| performance advantages that no one other than Apple can
| attain.
|
| Why would they? They sell hardware, not really software.
| simion314 wrote:
| >They sell hardware, not really software.
|
| But they make more money from the Apple Store and the
| other services and they are always giving advantages to
| their own stuff on iOS like using private APIs or
| bypassing security rules .
| fsflover wrote:
| > Why would they?
|
| I don't know why, but they are already doing it with
| browsers on iOS: https://docs.house.gov/meetings/JU/JU05/
| 20190716/109793/HHRG...
|
| _Are there any WebKit functions that Apple allows Safari
| to use but that competing browsers are not permitted to
| use?_
|
| _WebRTC for videoconferencing_ , _Intelligent Tracking
| Protection_ , _Fullscreen API_
| tenebrisalietum wrote:
| Hardware doesn't work without at least some sort of
| software.
|
| I really _wish_ they (or any one with modern fast CPU and
| motherboard designs) would sell hardware only bare-bones
| with no OS or even bootloader, but history shows a mass
| market won 't support that.
| simonh wrote:
| From an Apple perspective openness is a feature, not a goal
| in itself. Youre worrying about this or that specific ARM
| instruction, but Apple doesn't even want you to care whether
| it's ARM, or Intel, Or PowerPC, or whatever. It's an Apple
| system, part of the MacOS ecosystem and supported by Apple
| dev tools and power user features.
|
| If that's not the world you are interested in, what are you
| even doing owning a Mac? Apple does not try to be all things
| to all people the way e.g. Microsoft has.
| mhh__ wrote:
| > If that's not the world you are interested in, what are
| you even doing owning a Mac?
|
| I would like consumers to have at least semblance of
| freedom. You have to consider that for most consumers,
| almost everything mentioned in this thread from top to
| bottom is complete Greek to the average person buying a
| computer.
|
| This particular question (Documenting stuff), is the cherry
| on top. The Sundae itself is Apple's locked-in approach to
| their ecosystem. The result of the Epic squabble is much
| more important for example, similarly I don't think it's a
| good thing that Apple can force Stadia to be non-native (If
| you were a lifelong Apple customer would you know there was
| any alternative?).
|
| The world is only going to get more technological - thanks
| to things like the cloud, the Orwells of the future will be
| writing about technology.
|
| As a final remark, I believe there should be broad but
| shallow regulation for the whole sector, Apple are just the
| most obvious example.
| zamalek wrote:
| > consider that if microsoft were like this the blind eye
| would not be turned
|
| Microsoft was taken to court over undocumented APIs in Win
| 3.x that gave their own software an unfair advantage. This is
| why the Win32 documentation exists today.
| rwmj wrote:
| _> Apple aren 't really documenting anything for their new
| toys_
|
| This seems an odd strategy for an accelerator. How are they
| expecting that people will use these new instructions? Only
| through Apple-supplied closed source compilers and libraries?
| (This is not meant to indicate you're wrong, only I'm
| confused about Apple's strategy)
| Someone wrote:
| The Accelerate Framework is a library with common functions
| such as BLAS, neural networks, Fourier transforms and
| compression
| (https://developer.apple.com/documentation/accelerate)
|
| That is similar to Intel providing such functions in a
| library for their CPUs (https://software.intel.com/content/
| www/us/en/develop/tools/o...).
|
| A difference, of course, is that Apple can ship it with its
| OS, and does so.
|
| I would guess they're not or not yet willing to commit to
| shipping these instructions in future hardware (possibly,
| but that is more guesswork, because they have to work
| around bugs to use them. Those NOPs this article is talking
| about might be to work around them)
| ac29 wrote:
| > How are they expecting that people will use these new
| instructions? Only through Apple-supplied closed source
| compilers and libraries?
|
| This sounds right. Forcing people to use Apple supplied and
| supported libraries allows Apple to make major changes in
| hardware without breaking compatibility (there are always
| edge cases, though).
| rwmj wrote:
| If the compiler generates these instructions, won't old
| binaries break if Apple later make changes in the
| hardware? (For shared libraries it would be "ok" because
| the old binary could use the new library, as long as
| Apple didn't also break the ABI).
| comex wrote:
| Accelerate.framework is a shared library distributed with
| the OS. Like most other system libraries, it's not
| available as a static library, and though you could
| theoretically ship a copy of it in an app bundle, you're
| not supposed to. Instead the ABI is kept backwards-
| compatible.
|
| There's no publicly available _compiler_ , proprietary or
| not, that produces binaries that use the instructions.
| Someone wrote:
| The public compiler wouldn't generate them, or only
| generate them when compiling with a special flag.
| egsmi wrote:
| In theory that's what bitcode protects against.
|
| Today, that doesn't save binaries not distributed through
| the store or ones you compiled yourself via other
| compiler chains.
|
| It is possible to change that. One could even imagine it
| as part of the loading procedure.
|
| https://lowlevelbits.org/bitcode-demystified/
| realusername wrote:
| Apple does not care that much about backward
| compatibility so having two incompatible binaries with
| the same architecture wouldn't shock me that much.
| adrian_b wrote:
| Apple provides libraries that developers are supposed to
| use (e.g. "Accelerate").
|
| Apple does not provide any support for using directly their
| undocumented ISA extensions, or their undocumented GPU, NPU
| etc.
| mhh__ wrote:
| They aren't even documenting the microarchitecture of the
| CPU either.
| whatshisface wrote:
| > _The fact that they can be like this is really proof that
| their market position is much stronger than most HNers seem
| to think it is._
|
| Elsewhere on the HN front page is a computer made with a
| Russian internal CPU. The CPU has a custom ISA based on x86,
| and isn't open. The documentation is poor, and nobody has the
| source code for the compiler. It's also about 5 years behind
| the state of the art in x86. How can a product like this
| exist? Easy. Russia needs them for military hardware because
| they're not going to put Intel in their defense radar
| systems. The manufacturer has a niche to sell to.
|
| Instead of being 5 years behind, Apple's closed and
| undocumented ISA is 2 years ahead. How much moreso, if the
| Russian CPU can survive in the market, can they.
| spamizbad wrote:
| Seems clear that Russian CPU is targeted towards the
| Russian defense industry, where all that NIH and secrecy
| can arguably be leveraged into national security as its a
| less cost-sensitive application.
|
| The M1 is a CPU for global consumer products.
| whatshisface wrote:
| Of course, and Apple's ISA is targeted towards the People
| Who Buy Macs industry. By not making it available to
| datacenters, they are supporting other CPU vendors in the
| race to catch up. It will help AMD a lot in their bid to
| catch up that all investors can see that Apple won't be
| competing with them.
| _underfl0w_ wrote:
| > By not making it available to datacenters, they are
| supporting other CPU vendors in the race to catch up.
|
| This is by far the most charitable characterization of
| this monetization scheme I've seen so far. Some would
| argue this is actually in place to ensure that purchases
| go directly through Apple each time (i.e. a one-to-one of
| customers to hardware purchases), rather than through a
| cloud provider who may purchase hardware once and allow
| thousands of customers to access it. c.f. Apple's
| restrictions on subletting use for no less than a single
| day per "machine".
| whatshisface wrote:
| "Apple is extracting value at monopoly-pricing levels" ==
| "Apple is leaving tasty treats on the table to lure
| competitors." They're the same statement but phrased in
| different ways. Any price above the equilibrium lures
| competitors - that's how markets avoid monopoly pricing,
| in the absence of external factors that protect the
| monopoly.
| mhh__ wrote:
| The Russian CPU isn't surviving in a market
| bnt wrote:
| I exist there for I am?
| a1369209993 wrote:
| It's not surviving in a _market_ , because it's not in a
| market - it's being produced for a specific consumer,
| whose requirements are idiosyncratic enough[0] that the
| market refuses to service them.
|
| 0: a very low bar in this case, given the existence of
| things like Intel Management Engine, but it would be much
| the same if they insisted on something less justifiable
| like running all the CPU pins at 12-volt logic levels
| mhh__ wrote:
| They key word is market - The Elbrus is obviously propped
| up by the Russian government and it's tentacles. It's not
| an invalid business model but it's not a good way to
| measure technology.
| ardy42 wrote:
| > The Russian CPU isn't surviving in a market
|
| How so?
|
| It's actually not that different from Apple Silicon when
| you think about it.
|
| Apple Silicon: you only get it when you buy an iPhone,
| iPad, ARM Mac, etc. in the Smartphone or PC market; and
| it enables features that make those devices competitive.
|
| Russian Elbrus: you only get it when you buy some Russian
| military hardware in the defense market; and it enables
| features that make those devices competitive.
| mhh__ wrote:
| Because guaranteed sales from the government is clearly
| not the same as having to compete with Intel and AMD
| whatshisface wrote:
| M1 does not compete with Intel or AMD. (M1)(Apple)(OSX)
| competes with (Intel | AMD)(Choose any OEM)(Windows |
| Linux). All sales of the M1 chip are "guaranteed sales,"
| to Apple itself, building macs.
| rgovostes wrote:
| On the other hand, Apple released their 64-bit ARM backend
| for LLVM[1] in 2014. They announced their intention do so
| almost immediately after the first ARM64 phone, but the
| process took several months because it had to be merged with
| a duplicate backend developed by others.
|
| I think it is likely that support for these instructions will
| be upstreamed to LLVM, and the teams involved in this
| monumental transition (which was announced like ~50 days ago)
| simply didn't put it at the highest priority on the list of
| things that developers need to know to get their apps working
| on Day 1.
|
| A fair criticism is that some of the more technical
| documentation, such as on the Mach-O ABI, have disappeared
| from Apple's developer site, or been relegated to an
| unsearchable archive[2], so it's very reasonable to be
| skeptical of ISA extensions ever being documented there.
|
| The developer site has _always_ sucked though, and it seems
| to me they 've declared bankruptcy and are rebuilding it on
| machine-generated docs and WWDC content for app developers.
| Occam's razor.
|
| 1:
| https://www.phoronix.com/scan.php?page=news_item&px=MTY0NzE
|
| 2: https://developer.apple.com/library/archive/navigation/
| mhh__ wrote:
| My point about the docs isn't the day-to-day stuff, but the
| things that cannot be machine generated - to write a good
| compiler you need to know the details of how the CPU is put
| together underneath.
|
| Intel will give you 800 pages on how to optimize for their
| current ISA (AMD will give you 45, but still)
| rgovostes wrote:
| As I understand it, Intel will also sell you a compiler
| that can optimize better than GCC because they know
| internal microarchitecture details. To me, that seems
| like a more clear-cut by-design conflict of interest
| between chip designer and user than these undocumented
| instructions.
| tcbawo wrote:
| Do you think Intel considers their compiler a profit
| center/growth market? Or are trying to offset the expense
| of maintaining their own compiler?
| mhh__ wrote:
| Intel's compiler is basically free for plebs but not for
| datacentres.
|
| LLVM and GCC are good enough (brilliant, even) for
| general purpose compilation, but for a (say)
| supercomputer which is guarded by guns having Intel on
| the phone can be worth it.
| dayjobpork wrote:
| You think it is bad that a company provides good
| documentation on how their product works and how to use
| it?
| rgovostes wrote:
| This is not an accurate characterization of what I wrote
| whatsoever. Please don't misquote people in order to
| start flamewars.
| brigade wrote:
| AMX was first announced for the A13 [1], so it's been in
| the wild for over a year now.
|
| 1: https://www.anandtech.com/show/14859/apple-announces-
| new-iph...
| my123 wrote:
| And Apple M1 implements AMX2, not the original AMX in the
| A13.
|
| I'm not sure if Apple plans to ever maintain AMX
| compatibility across CPU versions...
| duskwuff wrote:
| You've hit on an important point here. As soon as Apple
| documents one of their CPU extensions, they've put
| themselves in the position of having to support it long-
| term. Leaving it undocumented gives them the freedom to
| make breaking changes from one CPU generation to the next
| -- hopefully with the end goal of deciding on an
| implementation and documenting the end result.
| supermatt wrote:
| I just started getting into macOS and iOS development and
| the documentation is HORRENDOUS.
|
| Even the classroom educational material Apple put out is
| incomplete, outdated, and often completely wrong!
|
| Additionally, It seems to be impossible to compile anything
| in Xcode other than a hello-world without gettting
| undocumented warnings and (non fatal) errors logged, which,
| if you can find a matching thread on their forums, usually
| results in a "just mark it down as log noise".
|
| Has it always been this bad?
| scrose wrote:
| I just started working with Swift again after building a
| couple toy apps when Swift was brand new. I feel your
| pain with their documentation!
|
| What bothers me most is how their documentation for
| anything is a massive scrollfest[0], followed by links
| everywhere, yet the actual documentation still feels
| sparse enough that I almost exclusively try to just read
| the source code and make guesses. Rails docs sure aren't
| going to win any design awards, but at least I can access
| everything on a single page![1]
|
| [0]
| https://developer.apple.com/documentation/swiftui/view
|
| [1] https://api.rubyonrails.org/classes/ActionController/
| LogSubs...
| keyle wrote:
| No it wasn't always this bad. The speed at which Swift
| has changed has left the documentation behind. I've
| complained about this numerous times.
|
| Simply put, if you want useful doco don't look at the
| latest version of the language. They literally stripped
| the useful notes and examples and it's now a straight API
| print out.
|
| If you use stackoverflow (sarcasm) be prepared to
| constantly be using older versions of swift and
| translating them to the latest. Feel free to submit
| updates to them.
|
| So it does help to understand what changed in the
| language versions. I think anything past Swift 3 is
| similar to today. Xcode does help a little telling you
| what you pasted makes no sense to a degree.
|
| It's a very sad state of affairs I'm afraid.
| TheNewAndy wrote:
| Yes. I have recently released my first game in the app
| store. It is a simple game, and so this is probably the
| 3rd rewrite of it.
|
| The second rewrite was when I finally had an apple
| device, so I thought "I will do everything the apple way"
| - I used Swift and SpriteKit, and tried to do everything
| exactly how I thought the Apple people would like.
|
| I then dropped that laptop, and was told it would cost
| more than the price of the laptop to repair, so I decided
| to do another rewrite - this time, using my linux laptop.
|
| The experience of writing it in plain documented C, and
| using libSDL2 for most of the IO was far superior.
| Writing my own physics engine instead of using the
| SpriteKit one made the actual gameplay better (because it
| meant I could easily fudge physics a bit to make it more
| fun).
|
| Only at the very end of the project did I then go through
| the painful process of making it happy with xcode, happy
| to build for iOS, and then finally happy with the Apple
| review process (including hacking my SDL build to remove
| bluetooth peripheral support so I didn't need to request
| unwanted permissions).
|
| I now have an M1 Macbook Air, and I've briefly looked
| again at doing things the "apple way" (e.g. swiftui) and
| I'm coming to a similar conclusion.
| gcblkjaidfj wrote:
| Apple must support base LLVM functionality because it is
| the core of their extend-embrace-extinguish strategy. This
| says nothing that they will extend that offer to their
| undocumented secret sauce, as you imply.
| rgovostes wrote:
| Don't be absurd. LLVM was a research project until Apple
| hired Chris Lattner and poured money into it to make a
| viable alternative to GCC. They've been among the
| project's top contributors (financially and in terms of
| code) for 15 years. That's quite the long con.
|
| Apple creates plenty of proprietary technologies but I
| can't think of a time they've been credibly accused of
| crushing an open technology that already existed.
| legulere wrote:
| CUPS is the closest where you could accuse Apple of doing
| that I guess.
| monocasa wrote:
| They did that, in part, because they were subject of one
| of the first GPL enforcement actions, originally being
| unwilling to open source their objc GCC frontend. They
| being Nextstep at the time, but there's not a huge
| distinction these days.
|
| Their investment in LLVM is very much an attempt to keep
| reproprietization on the table.
| rgovostes wrote:
| I absolutely believe that the investment in LLVM was
| justified to executives as a way to avoid GPL-licensed
| software, which Apple has long been allergic to.
|
| But it should be noted that the GPL violation you refer
| to was in 1989. Put in context, that was ~16 years before
| they started investing in LLVM, and they have done so
| continuously for the past ~15 years.
| monocasa wrote:
| Ultimately what the executives think is the reason is the
| real reason, as we saw from Oravle reproprietizing
| Solaris.
|
| And yes, it was a while back that literally lawyers had
| to get involved in their blatant GPL violation in the
| compiler space. We absolutely get to judge a company on
| it's past actions.
| legulere wrote:
| The way you put it non copyleft licenses are just there
| for bait and switch. I don't know any case where that
| happened where there was outside contributions.
| monocasa wrote:
| Oracle reproprietized all of Solaris, including the
| outside contributions up to that point.
|
| And I assume that Apple has support for these
| instructions this whole thread is about in their
| toolchains, so if that's the same version that's in
| xcode, reproprietization is already happening.
|
| Leaving reproprietization on the table is the whole point
| of non-copyleft open source.
| ur-whale wrote:
| >In the bigger picture Apple aren't really documenting
| anything for their new toys,
|
| This should not come as a surprise, it has _always_ been
| Apple 's default stance.
|
| Apple has been, is, and will very likely always be a closed
| ecosystem.
|
| They might sometimes appear or pretend to be open, but it's
| essentially good PR/marketing (e.g. stash Unix underneath a
| closed-source stack, call yourself open source and proceed to
| lure all the open source devs to the platform).
| Someone wrote:
| I think it's more a sign of the times than Apple being
| Apple that they don't tell you what hardware you buy when
| you buy one of their systems or how it is connected.
| Television manuals used to contain hardware schematics, car
| manuals used to be way more detailed, etc.
|
| Apple also had detailed info on their hardware. The Apple
| II reference manual had schematics, mapped it to the PCB,
| described what each part did, described 6502 assembly and
| had an assembly listing of the monitor ROM. The only thing
| missing to build a copy, I think, was an assembly listing
| of the Basic interpreter.
|
| The phone book edition of Inside Macintosh also had info on
| the hardware, but a lot less of it.
| calo_star wrote:
| This really isn't new. It looks like instead of treating the
| "Neural Engine" as an I/O device like the GPU, it's accessed
| as a coprocessor. It makes sense for them to only expose
| their functionalities through libraries as the underlying
| hardware implementation will go through changes in the
| future. After all, does, say, Nvidia, document their GPU's
| ISA?
| mhh__ wrote:
| Yes. Not as much as the average CPU but still documented:
| https://developer.nvidia.com/blog/nvidia-ampere-
| architecture...
| vmception wrote:
| My life is so much better being in the Apple ecosystem.
|
| Some of it was unintentional, but now its iPhone, Macbook
| Pro, Apple Watch, Airpods Pro, and IOT devices that use
| Homekit. I have an iPad but I use it the least.
|
| Pre-Intel I used to make fun of "Apple fanboys". But aside
| from the niche and incompatibilities of the PowerPC
| architecture back then, that turned out to be a lot of other
| immaturities I had and was raised with.
|
| I also used to use Android, but the "look how many advanced,
| poorly integrated and under maintained things I can do by
| myself" concept didn't stay appealing for very long.
| mhh__ wrote:
| This is a non-sequitur. There is nothing stopping Apple
| from doing things in an open manner - it's purely cultural.
| The fact that they don't is why I do not buy for a second
| that they can be trusted with privacy, whether they care or
| not.
|
| The quality of Apple's ecosystem is because of the
| centralized effort put into it and them owning the stack,
| not because the end result is walled-in.
| retaeelppa wrote:
| Once you're done frolicking in the garden, tech outside can
| use some help.
|
| ICS and CUPS are a testament to how strange Apple is as a
| company. See also: libimobiledevice.org
|
| I hold that they're hands-down the worst company at
| marketing.
| vmception wrote:
| Speaking of the garden, what garden!?
|
| iOS devices have had a file system users can at least
| save and retrieve from for years now.
|
| The mobile app landscape has changed from the gold rush
| early last decade, and I rarely install anybody's. I
| empathize with the developers still trying to make it
| there, but its not a user's problem.
|
| The protocols that Apple chooses to promulgate work
| really well.
|
| Flagship games work really well.
|
| The garden has gotten really big, I can't see the walls
| anymore but little bad gets in.
|
| Computers do what I want them to, here. They don't do
| what I want them to do outside of here. For context, I
| jump into a Windows instance, or routinely put compute
| instances in the cloud.
| mlazos wrote:
| I'm thinking this is related to the machine-learning coprocessor.
| They likely expose this to developers through their ML API and
| don't want to have to support this for external customers if it
| changes. Still this is a great find!
___________________________________________________________________
(page generated 2020-12-28 23:00 UTC)