Mám dvoujádrového Wolfdale s 6MB L2 Cache a za Quad bych ho nevyměnil, protože dual core aspoň málo žere (proti Quadu) a chipset s ním méně topí. Kdybych ho neměl v krásné desce ga-ep45-ds5, tak by asi už letěl...

Na druhou stranu teď píšu z Pentium 4 531 +Win XP s vypnutým HT (to že ještě dává net nechápu) a to už minimálně do sklepa brzy půjde. A někomu na net nestačí moderní čtyřjádro ARM s malými jádry - ten Android je ale shit...

Minimálně je tam velký bacha, jak pracovat s pamětí, po stránce instrukcí a práce s nimi je to taky nebe a dudy CISC/RISC atd. V Linuxu/Androidu se dočítám, že si programátor má hlídat alokaci paměti a garbage collection v podstatě sám a není jistý, jestli mu danej procesor při TLB miss projede page table nebo si to má zařídit, jak chce atd. atp.

https://cs.wikipedia.org/wiki/Translation_Lookaside_Buffer
Prakticky všechny dnešní procesory obsahují TLB. U architektury IA-32 nebo x86-64 šetří „pouze“ hardwarové prohledávání víceúrovňové struktury tabulek v paměti. V okamžiku, kdy zde dojde k TLB miss, procesor sám, bez zásahu opračního systému, provede page walk, pokusí se najít správné mapování a provede update TLB. V některých jiných architekturách (např. MIPS) je hardwarově implementován pouze TLB a page walk pak musí být implementován softwarově v jádře operačního systému. V případě TLB miss zde tedy dojde k vyvolání výjimky a správné mapování musí nalézt příslušný handler přerušení, provést opravu TLB a restartovat instrukci, která výjimku vyvolala. Díky tomu je každý TLB miss na těchto architekturách velmi drahou operací.

Z předchozího popisu vyplývá, že rychlost překladu adres a tím i běhu programu je velmi závislá na tom, jak často dojde k TLB hitu. Kvůli tomu jsou prováděny optimalizace při překladu programu, aby se zvýšila jeho lokalita (ve smyslu opakované použití stejné paměti).

https://cs.wikipedia.org/wiki/MIPS_(architektura)
Procesor může tedy zpracovávat více instrukcí současně, avšak pouze za podmínky, že tyto instrukce nepoužívají stejné prostředky procesoru. Pokud splnění této podmínky při řazení instrukcí do pipeline zajišťuje přímo procesor, jedná se o tzv. interlocked pipeline. Pokud splnění této podmínky musí hlídat programátor nebo překladač, jedná se o non-interlocked pipeline. Z tohoto důvodu je efektivní programování procesorů s non-interlocked pipeline obtížnější, zejména ve spojení se složitějšími instrukcemi a delšími pipeline.

https://android.googlesource.com/kernel/common/+/refs/heads/android-5.4-...

.. warning::
``atomic_read()`` and ``atomic_set()`` DO NOT IMPLY BARRIERS!

Some architectures may choose to use the volatile keyword, barriers, or
inline assembly to guarantee some degree of immediacy for atomic_read()
and atomic_set(). This is not uniformly guaranteed, and may change in
the future, so all users of atomic_t should treat atomic_read() and
atomic_set() as simple C statements that may be reordered or optimized
away entirely by the compiler or processor, and explicitly invoke the
appropriate compiler and/or memory barrier for each use case. Failure
to do so will result in code that may suddenly break when used with
different architectures or compiler optimizations, or even changes in
unrelated code which changes how the compiler optimizes the section
accessing atomic_t variables.

https://android.googlesource.com/kernel/common/+/refs/heads/android-5.4-...
The side effects described below are stated for a uniprocessor
implementation, and what is to happen on that single processor. The
SMP cases are a simple extension, in that you just extend the
definition such that the side effect for a particular interface occurs
on all processors in the system. Don't let this scare you into
thinking SMP cache/tlb flushing must be so inefficient, this is in
fact an area where many optimizations are possible. For example,
if it can be proven that a user address space has never executed
on a cpu (see mm_cpumask()), one need not perform a flush
for this address space on that cpu.

This time we need to remove a PAGE_SIZE sized range
from the cache. The 'vma' is the backing structure used by
Linux to keep track of mmap'd regions for a process, the
address space is available via vma->vm_mm. Also, one may
test (vma->vm_flags & VM_EXEC) to see if this region is
executable (and thus could be in the 'instruction cache' in
"Harvard" type cache layouts).

v prípade GPU dokonca existuje iný mikrokód pre rôzne linuxové ovládače, nie len pre rôzne OS

https://wiki.gentoo.org/wiki/AMDGPU#Firmware

v prípade nie je to výraznejšie

https://launchpad.net/ubuntu/+source/nouveau-firmware

https://packages.gentoo.org/packages/sys-firmware/nvidia-firmware