<div dir="ltr">> The only libre GPU project I know of is <a href="https://libre-soc.org/" target="_blank">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<div>What architecture did they choose for this? POWER is the only one that is open source and mature right now.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 13, 2020 at 2:26 PM Doug Moen <<a href="mailto:doug@moens.org">doug@moens.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><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/" target="_blank">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="gmail-m_-7206252879490643291qt"><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="gmail-m_-7206252879490643291qt-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 <<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a>><br></div><div>Date: 2020-12-13 13:06 (GMT-05:00)<br></div><div>To: <a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a><br></div><div>Cc: Mikalai Birukou <<a href="mailto:mb@3nsoft.com" target="_blank">mb@3nsoft.com</a>><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" target="_blank">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><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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="gmail-m_-7206252879490643291qt-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="gmail-m_-7206252879490643291qt-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" target="_blank">kwlug-disc@kwlug.org</a><br></div><div><a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">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" target="_blank">kwlug-disc@kwlug.org</a><br></div><div> <a rel="noreferrer" href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br></div></blockquote></div></div><div><br></div><pre>_______________________________________________
kwlug-disc mailing list
<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a>
<a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
<br></pre></blockquote><div><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" target="_blank">kwlug-disc@kwlug.org</a><br></div><div><a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br></div><div><br></div></blockquote><div><br></div></div>_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a><br>
<a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" rel="noreferrer" target="_blank">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote></div>