<!DOCTYPE html><html><head><title></title><style type="text/css">
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>There's a short thread discussing the medium post about M1 on the libre-soc mailing list.<br></div><div><a href="http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-December/001547.html">http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-December/001547.html</a><br></div><div><br></div><div>relevant excerpts:<br></div><div>> We had talked previously about building a 8-wide processor too, but we
decided we're putting that off till later since we wanted to get a working
processor first, then we'll have a better opportunity to go all out once we
demonstrated that we can make something that works.<br></div><div>> I was both fascinated and horrified to see that x86 multi issue decode
has to start decoding instructions from *random byte locations* in the
desperate hope that, half way through that, some of them will go "ah!
yippeee! i know the length of this instruction! all youse f*****rs can
stop wasting power now".<br></div><div>> By contrast the relative simplicity of ARM (and OpenPOWER) allow a
near-trivial length-detection and consequently 8-issue is perfectly
reasonable.<br></div><div><br></div><div>Since RISC-V is just a CPU, and is != SOC with CPU, GPU and integrated memory architecture, this is the only group I know working on a libre analogue of the M1.<br></div><div><br></div><div>On Sun, Dec 13, 2020, at 2:06 PM, Doug Moen wrote:<br></div><blockquote type="cite" id="qt" style=""><div>libre-soc.org also pivoted from designing an open source GPU to an integrated CPU/GPU SOC with a unified memory architecture, which decision the Apple M1 also seems to validate.<br></div><div><br></div><div>On Sun, Dec 13, 2020, at 2:01 PM, Doug Moen wrote:<br></div><blockquote type="cite" id="qt-qt" style=""><div>It would be awesome if somebody builds this kind of architecture for RISC-V. But that would require someone with deep pockets and a business case. I don't follow RISC-V so I dunno if anything like that can happen. The only libre GPU project I know of is <a href="https://libre-soc.org/">https://libre-soc.org/</a> and they abandoned RISC-V a year or two ago for a different architecture with massive superscalar out-of-order execution, something they apparently thought was lacking in RISC-V. What Jason said about OOE on the M1 puts their decision in context for me, since I am not a CPU nerd.<br></div><div><br></div><div>On Sun, Dec 13, 2020, at 1:44 PM, jason.eckert wrote:<br></div><blockquote type="cite" id="qt-qt-qt" style=""><div dir="auto">Beefing up the out of order execution prediction is definitely the main reason why the M1 SoC performs well - but this sort of execution can only be efficient if the instruction size remains constant, as is the case with RISC-only architechtures like ARM. This is where SGI MIPS was headed before they died.<br></div><div dir="auto"><br></div><div dir="auto">The main takeaway here IMO is that now that Apple has demonstrated that a phone SoC can be beefed up to perform general-purposed computing well, we'll start seeing more of this hit the market in the workstation space. And when those fast SoC systems start running Linux, developers will flock to them and that will accelerate the adoption of ARM in the cloud/datacenter. Yes, Amazon has their nice Graviton platform, but without developers running ARM on their workstations, adoption of ARM in the cloud/datacenter is not going to gain a lot of traction.<br></div><div dir="auto"><br></div><div dir="auto">If Apple allowed Linux to run natively on their M1 SoC, it would actually be a game-changer in this space. But that would require they release their SoC documentation to the open source community, as well as digitally sign Linux boot components im their secure enclave (neither of which is likely because Apple is as closed as Oracle's wallet ;-)<br></div><div dir="auto"><br></div><div dir="auto">What I'm most interested in seeing in the coming years is what Nvidia is planning for ARM (no matter what they say, they definitely have a plan in mind if they bought ARM).<br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div id="qt-qt-qt-composer_signature" dir="auto"><div style="font-size:85%;color:rgb(87, 87, 87);">Sent from my Samsung device running Android (basically Linux in drag)<br></div></div><div dir="auto"><br></div><div><br></div><div dir="auto" style="font-size:100%;color:rgb(0, 0, 0);" align="left"><div>-------- Original message --------<br></div><div>From: Mikalai Birukou via kwlug-disc <kwlug-disc@kwlug.org><br></div><div>Date: 2020-12-13 13:06 (GMT-05:00)<br></div><div>To: kwlug-disc@kwlug.org<br></div><div>Cc: Mikalai Birukou <mb@3nsoft.com><br></div><div>Subject: Re: [kwlug-disc] about silicon<br></div><div><br></div></div><div><br></div><blockquote type="cite"><div><div dir="auto">Found a nice blog post explaining why M1 is
fast. <br></div><div><a href="https://debugger.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2">https://debugger.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2</a><br></div></div></blockquote><p>I knew it! I felt it all my life! It takes insurmountable amount
of time to prepare place for painting, more than painting itself
takes. ... Eight preppers of micro-ops in M1 versus four in
Intel/AMD.<br></p><p>I still have feeling that co-locating memory also helps preppers'
result, besides the benefit of RISC's constant length of
instruction.<br></p><p>It also explains talks of AMD going with ARM. RISC-y business :)<br></p><blockquote type="cite"><div><div class="qt-qt-qt-gmail_quote"><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-qt-qt-gmail_quote"><div><div><div>Rust provides both Atomic Reference Counting (called
Arc) and non-atomic Reference Counting (called Rc). You
choose the one that makes sense. Hopefully the type
system complains if you use Rc in a context where
atomicity is required, but I don't use Rust. C++
provides only atomic refcounting in the standard
library; for the other kind you roll your own (which I
have done).<br></div><div><br></div><blockquote id="qt-qt-qt-m_816261540811853656qt" type="cite"><p><moving into discussing silicon and near it><br></p><blockquote type="cite"><div>Another trick is that Apple's dev languages and
frameworks (Swift and Objective-C) use reference
counting, which requires atomic increments and
decrements. On Intel, these operations are five
times slower than non-atomic operations; on Apple
Silicon they run at the same speed. This is
something I wish the other CPU vendors would get
right, because refcounting has some technical
advantages over tracing GC, and I use it in
software I write. C++ and Rust, both "performance"
languages, provide refcounting but not tracing GC.<br></div><blockquote id="qt-qt-qt-m_816261540811853656qt-qt" type="cite"><div>Regarding M1. My Understanding is that
placement of RAM inside of processor
package/silicon is the trick that makes it run
fast. Is there anything else?<br></div><div><br></div><blockquote type="cite"><div dir="ltr"> The Apple M1 looks decent, but
since Apple no longer lets you run Linux on
their hardware, I have no desire to ever buy
one.<br></div></blockquote></blockquote></blockquote><div>Does Rust standard refcounting, or implementation
of such pointers need to use atomic in/decrements?
Can't it use non-atomic something, given a more
detailed knowledge of ownership? Just wondering.<br></div><div><br></div><div>_______________________________________________<br></div><div>kwlug-disc mailing list<br></div><div><a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br></div><div><a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br></div><div><br></div></blockquote><div><br></div></div></div><div>_______________________________________________<br></div><div>kwlug-disc mailing list<br></div><div><a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br></div><div><a rel="noreferrer" href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br></div></blockquote></div></div><div><br></div><pre class="qt-qt-qt-moz-quote-pre">_______________________________________________
kwlug-disc mailing list
<a href="mailto:kwlug-disc@kwlug.org" class="qt-qt-qt-moz-txt-link-abbreviated">kwlug-disc@kwlug.org</a>
<a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" class="qt-qt-qt-moz-txt-link-freetext">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
<br></pre></blockquote><div class="qt-qt-qt-moz-signature"><div>-- <br></div><div>Mikalai Birukou <br></div><div>CEO | 3NSoft Inc.<br></div></div><div>_______________________________________________<br></div><div>kwlug-disc mailing list<br></div><div><a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br></div><div><a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br></div><div><br></div></blockquote><div><br></div></blockquote><div><br></div><div>_______________________________________________<br></div><div>kwlug-disc mailing list<br></div><div><a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a><br></div><div><a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br></div><div><br></div></blockquote><div><br></div></body></html>