[kwlug-disc] about silicon

[Mikalai Birukou]

> Found a nice blog post explaining why M1 is fast.
> https://debugger.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2

And since M1 story is validation of RISC, this article 
https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020-7b4d42c9a9de 
reminds of, quote

```

Back in 1987, the top of the line x86 processor was an intel 386DX, 
while a top of the line RISC processor was MIPS R2000.

Despite the fact that the intel processor had more transistors, 275 000 
vs 115 000 on the MIPS and had twice as much cache, the x86 processor 
was completely demolished in performance tests.

Both processors ran at 16 MHz clock rate, but the RISC processor had 2–4 
times higher performance, depending on benchmark used.

Thus it is not strange that by the early 90s it had become a generally 
accepted idea that RISC processors had vastly better performance.

```

>     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).
>>
>>     <moving into discussing silicon and near it>
>>
>>>     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.
>>>>     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?
>>>>
>>>>>      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.
>>     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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20201213/acc70caa/attachment.htm>