Tüm geliştiricilerin bilmesi gereken GPU hesaplama
(codeconfessions.substack.com)- GPU’lar düşük tekil komut gecikmesinden ziyade büyük ölçekli paralel işlem hacmini önceleyen bir mimariye sahiptir; bu yüzden derin öğrenme, grafik ve sayısal hesaplama gibi aynı türden işlemleri büyük miktarda yapan işlerde güçlüdür
- CPU’lar pipelining, out-of-order execution, speculative execution ve çok katmanlı cache ile ardışık yürütme gecikmesini azaltırken, GPU’lar çok sayıda ALU ve thread ile gecikmeyi gizleyip işlem hacmini artırır
- 32 bit hassasiyet düzeyinde Nvidia Ampere A100 19.5 TFLOPS, 2021 tarihli Intel 24 çekirdekli işlemci ise 0.66 TFLOPS sunar; sayısal hesaplama işlem hacmi farkı büyümeye devam ediyor
- CUDA kernel’lerinde CPU tarafındaki host code çalıştırma hazırlığını üstlenir, GPU tarafındaki device code ise grid·block·thread yapısında çalışır; thread’ler 32’li gruplar hâlinde warp olarak bağlanır ve SIMT modeliyle işlenir
- Gerçek performans, bir SM içindeki register, shared memory, block slot ve thread slot kaynaklarının nasıl paylaştırıldığına büyük ölçüde bağlıdır; occupancy düşükse gecikmeyi gizlemek zorlaşır ve en yüksek işlem hacmine ulaşılamayabilir
CPU ve GPU’nun tasarım hedefleri arasındaki fark
- CPU, öncelikle ardışık komut yürütmeyi hızlı işleyecek şekilde tasarlanır
- Komut yürütme gecikmesini azaltmak için instruction pipelining, out-of-order execution, speculative execution ve multilevel cache gibi özellikler kullanır
- İki sayıyı toplamak gibi tek bir işlem ya da kısa bir işlem akışı, CPU tarafından GPU’dan daha düşük gecikmeyle işlenebilir
- GPU ise büyük ölçekli paralellik ve yüksek işlem hacmi merkezli tasarlanır
- Video oyunları, grafik, sayısal hesaplama ve derin öğrenme gibi çok sayıda lineer cebir ve sayısal işlemin hızlı yapılması gereken işler bu yapıya çok uygundur
- Aynı türden milyonlarca ya da milyarlarca işlem söz konusu olduğunda, GPU büyük ölçekli paralellik sayesinde CPU’dan çok daha hızlı olabilir
- Sayısal hesaplama performansı, saniye başına kayan nokta işlemi sayısını ifade eden FLOPS ile ölçülür
- Nvidia Ampere A100, 32 bit hassasiyette 19.5 TFLOPS işlem hacmi sunar
- 2021 itibarıyla Intel 24 çekirdekli işlemci, 32 bit hassasiyette 0.66 TFLOPS düzeyindedir
- GPU ile CPU arasındaki işlem hacmi farkı her yıl büyümektedir
GPU’nun gecikmeyi gizleme yöntemi
- GPU, tek tek komutların gecikmesi yüksek olsa bile çok sayıda thread ve hesaplama kaynağı kullanarak gecikme toleransı sağlar
- Bir thread komut sonucunu beklerken GPU, beklemeyen başka thread’leri çalıştırır
- Bu zamanlama sayesinde hesaplama birimleri mümkün olduğunca sürekli çalışır ve yüksek işlem hacmi korunur
GPU compute mimarisi
- GPU, birden fazla streaming multiprocessor (SM) dizisinden oluşur
- Her SM; birden çok streaming processor, core ve thread içerir
- Nvidia H100, 132 SM’ye sahiptir ve her SM’de 64 core bulunur; toplamda 8,448 core eder
- Her SM’de tüm core’ların paylaştığı sınırlı miktarda on-chip bellek bulunur
- Bu bellek shared memory ya da scratchpad olarak adlandırılır
- SM’in kontrol birimi kaynakları da core’lar tarafından ortak kullanılır
- Her SM, thread yürütmesi için donanım tabanlı bir thread scheduler içerir
- İş yüküne bağlı olarak tensor core, ray tracing unit gibi özel işlev birimleri ya da hızlandırılmış hesaplama birimleri de bulunabilir
GPU bellek hiyerarşisi
-
Register
- Her SM’de çok sayıda register bulunur
- Nvidia A100 ve H100, SM başına 65,536 register içerir
- Register’lar core’lar arasında paylaşılır ve thread gereksinimlerine göre dinamik olarak tahsis edilir
- Çalışma sırasında belirli bir thread’e tahsis edilen register’lar o thread’e özeldir; başka thread’ler bunları okuyamaz veya yazamaz
-
Constant cache
- SM üzerinde çalışan kodun kullandığı sabit verileri cache’ler
- GPU’nun veriyi constant cache’e koyabilmesi için programcının kod içinde nesneyi açıkça sabit olarak tanımlaması gerekir
-
Shared memory
- Her SM’de bulunan küçük, hızlı ve düşük gecikmeli programlanabilir on-chip SRAM’dir
- Aynı SM üzerinde çalışan thread block’ları tarafından paylaşılır
- Birden fazla thread aynı veri parçasını kullanıyorsa, yalnızca bir thread’in global memory’den okuması ve diğerleriyle paylaşması yinelenen yüklemeleri azaltabilir
- Ayrıca thread block içindeki thread’ler arasında senkronizasyon mekanizması olarak da kullanılır
-
L1 cache ve L2 cache
- Her SM’de, L2 cache’ten sık erişilen verileri cache’leyen bir L1 cache bulunur
- L2 cache tüm SM’ler tarafından paylaşılır ve global memory’de sık erişilen verileri cache’leyerek gecikmeyi azaltır
- L1 ve L2 cache, SM açısından saydam çalıştığı için SM veriyi global memory’den alıyormuş gibi görünür
-
Global memory
- GPU’da off-chip global memory bulunur; bu, yüksek kapasiteli ve yüksek bant genişlikli DRAM’dir
- Nvidia H100, 80GB HBM ve 3000GB/s bant genişliği sunar
- Global memory, SM’lerden uzakta olduğu için gecikmesi yüksektir; ancak on-chip bellek hiyerarşisi ve çok sayıdaki hesaplama birimi bu gecikmeyi gizlemeye yardımcı olur
CUDA kernel’leri ve thread yapısı
- CUDA, Nvidia GPU’lar için program yazmaya yarayan bir programlama arayüzüdür
- GPU’da çalışacak hesaplama, C/C++ fonksiyonlarına benzeyen bir kernel biçiminde ifade edilir
- Örnek olarak, iki vektörü girdi alıp bunları eleman bazında toplayarak sonucu üçüncü bir vektöre yazan bir vektör toplama kernel’i verilebilir
- Kernel çalıştırıldığında çok sayıda thread başlatılır; bu bütün yapıya grid denir
- Grid, bir veya daha fazla thread block’tan oluşur
- Her thread block, bir veya daha fazla thread’den oluşur
- Block sayısı ve thread sayısı, veri boyutu ile istenen paralellik düzeyine göre değişir
- 256 boyutlu bir vektör toplamında, 256 thread’lik tek bir block kurularak her thread’in vektörün bir elemanını işlemesi sağlanabilir
- Daha büyük problemlerde GPU’nun kullanılabilir thread sayısı yetersiz kalabilir; bu durumda her thread birden fazla veri noktasını işleyebilir
- CUDA uygulaması iki parçaya ayrılır
- Host code, CPU üzerinde çalışır ve veri yükleme, GPU belleği ayırma ve belirlenen thread grid’iyle kernel çalıştırmayı üstlenir
- Device code, GPU üzerinde çalışır ve gerçek kernel fonksiyonunu tanımlar
GPU’da bir kernel’in çalıştırılma aşamaları
-
Veriyi host’tan device’a kopyalama
- Kernel çalışmadan önce gereken veriler CPU belleğinden GPU global memory’sine kopyalanmalıdır
- Modern GPU donanımlarında unified virtual memory kullanılarak host memory’den doğrudan okuma da yapılabilir
-
Thread block’ları SM’lere zamanlama
- Gerekli veri GPU belleğinde hazır olduğunda thread block’lar SM’lere atanır
- Bir block içindeki tüm thread’ler aynı SM üzerinde aynı anda işlenir
- GPU, çalıştırma öncesinde ilgili thread’lerin ihtiyaç duyduğu SM kaynaklarını ayırmak zorundadır
- Pratikte birden fazla thread block aynı SM’ye eşzamanlı olarak atanabilir
- SM sayısı sınırlı olduğundan ve büyük kernel’lerde block sayısı çok fazla olabildiğinden, tüm block’lar hemen çalıştırılamaz
- GPU bekleyen block’ların bir listesini tutar; bir block bittiğinde sıradaki bekleyen block’lardan biri yürütmeye alınır
-
SIMT ve warp
- Bir SM’ye atanan thread’ler yeniden 32’li gruplar hâlinde düzenlenir; bu gruba warp denir
- Güncel nesil Nvidia GPU’larda warp boyutu 32’dir, ancak gelecekteki donanımlarda bu değişebilir
- SM, warp içindeki tüm thread’lere aynı komutu getirip verir
- Thread’ler aynı komutu eşzamanlı yürütür, ancak verinin farklı kısımlarını işler
- Bu model single instruction multiple threads (SIMT) olarak adlandırılır ve CPU’lardaki SIMD komutlarına benzer
- Volta sonrası modern GPU’larda, warp’tan bağımsız olarak thread’ler arası tam eşzamanlılığa izin veren independent thread scheduling de bulunur
-
Warp zamanlaması ve gecikme toleransı
- Bir SM içindeki tüm processing block’lar warp işliyor olsa da, belirli bir anda gerçekten komut çalıştıran warp sayısı bunların yalnızca bir kısmıdır
- Bunun nedeni, SM’in yürütme birimi sayısının sınırlı olmasıdır
- Bir warp uzun süren bir komutun sonucunu bekliyorsa, SM o warp’ı beklemeye alır ve beklemesi gerekmeyen başka warp’ları çalıştırır
- Her warp içindeki her thread kendi register kümesine sahip olduğu için, warp’lar arasında geçişte ek bir overhead oluşmaz
- CPU’daki süreç context switch işlemi ise register’ları ana belleğe kaydedip başka bir sürecin durumunu geri yüklemeyi gerektirdiğinden maliyetlidir
-
Sonuç verisini device’tan host’a kopyalama
- Kernel içindeki tüm thread’lerin yürütmesi tamamlandığında sonuçlar yeniden host memory’ye kopyalanır
Kaynak bölüşümü ve occupancy
- GPU kaynak kullanımını ölçmek için occupancy adlı bir gösterge kullanılır
- Occupancy, bir SM’ye atanmış warp sayısının o SM’nin destekleyebileceği azami warp sayısına bölünmesiyle elde edilir
- En yüksek işlem hacmi için %100 occupancy istenir, ancak çeşitli kısıtlar nedeniyle bu her zaman mümkün değildir
- Her SM’de register, shared memory, thread block slot ve thread slot gibi sabit yürütme kaynakları bulunur
- Bu kaynaklar, thread gereksinimleri ile GPU sınırlarına göre dinamik biçimde paylaştırılır
- Nvidia H100 örneği
- Her SM 32 block, 64 warp yani 2048 thread çalıştırabilir
- Block başına en fazla 1024 thread desteklenir
- Block boyutu 1024 thread olarak ayarlanırsa, 2048 thread slot’u 2 block arasında paylaştırılır
- Dinamik bölüşüm, sabit bölüşüme göre hesaplama kaynaklarını daha verimli kullanabilir
- Sabit bölüşümde her thread block sabit miktarda yürütme kaynağı alır
- Bazı durumlarda thread’lere gerekenden fazla kaynak ayrılabilir; bu da kaynak israfı ve işlem hacmi düşüşüne yol açar
- Occupancy’yi düşüren örnekler
- Block boyutu 32 thread olarak seçilip toplam 2048 thread gerekiyorsa 64 block oluşur
- Ancak her SM aynı anda yalnızca 32 block işleyebildiği için gerçekte sadece 1024 thread çalışır ve occupancy %50 olur
- SM başına 65,536 register varken 2048 thread’i aynı anda çalıştırmak için thread başına en fazla 32 register kullanılabilir
- Kernel thread başına 64 register gerektiriyorsa, SM başına yalnızca 1024 thread çalışabilir; occupancy yine %50’ye düşer
- Düşük occupancy, gecikmenin yeterince gizlenmesini engelleyebilir ve donanımın en yüksek işlem hacmine ulaşması için gereken hesaplama throughput’unu da azaltabilir
- Verimli GPU kernel’leri yazmak için, yüksek occupancy’yi korurken gecikmeyi azaltacak şekilde kaynaklar dikkatle paylaştırılmalıdır
- Fazla register kullanımı kodun kendisini hızlandırabilir, ancak occupancy’yi düşürebilir; bu nedenle optimizasyon dengesi önemlidir
Daha fazla incelenebilecek kaynaklar
- Programming Massively Parallel Processors: 4. baskı en güncel başvuru kaynağıdır, ancak önceki baskılar da kullanılabilir
- Programming Massively Parallel Processors: Prof. Hwu’nun çevrimiçi dersleri
- Nvidia’s CUDA C++ Programming Guide
- How GPU Computing Works
- GPU Programming: When, Why and How?
1 yorum
Hacker News yorumları
Biri bu yazı için itiraz e-postası göndermiş: https://twitter.com/abhi9u/status/1715753871564476597
Bu HN kurallarının ihlali. Hatta site yönergelerinde ve SSS’de yer alacak kadar önemli tek madde bu; HN kullanıcıları da bu konuda çok hassas
S: Yazım için oy isteyebilir miyim?
C: Hayır. Kullanıcılar, birinin tanıtmak istediği bir içerik olduğu için değil, kendileri entelektüel olarak ilginç bulduklarında oy vermeli. Bu kuralı ihlal ederseniz yazıya, hesaba veya siteye ceza verilebilir ya da engellenebilir; bu yüzden yapmayın
https://news.ycombinator.com/newsfaq.html
Oy, yorum veya gönderim talep etmeyin. Kullanıcılar tanıtım amacıyla değil, bizzat karşılaştıkları bir şeyi kişisel olarak ilginç bulduklarında oy vermeli ve yorum yapmalı
https://news.ycombinator.com/newsguidelines.html
Artık öğrendiğime göre bir daha yapmayacağım
“Veriyi host’tan cihaza kopyalama” kısmında asenkron kopyalama olmamasına şaşırdım. GPU’dan azami verim almak istiyorsanız, host ile GPU arasında veri kopyalanırken GPU boşta kalmamalı
Birçok framework, asenkron iş gönderimiyle birlikte çalışabilen asenkron kopyalama zamanlama mekanizmaları sağlar. Yazının kendisi daha çok GPU’ya giriş niteliğinde, ama gerçek GPU programlamada pahalı GPU’yu sonuna kadar kullanmak için bunun ötesinde türlü türlü püf noktaları ve teknikler var. Günümüzdeki optimizasyonların çoğunda olduğu gibi gizli uçurumlar ve doğrusal olmayan davranışlar çok olduğundan profiling araçları çok yardımcı olur
Yine de çok sayıda FP64 birimi olan bir GPU kullanırsanız ciddi hızlanma olabilir. Bunlar genelde gaming GPU’ları değildir, ama elinizde zaten bir 4060 varsa FP64 performansı yaklaşık 300 GFLOPS olduğundan CPU’dan yüksek olma ihtimali büyük. Modern CPU’lar da bu alanda güçlü; her çekirdek saat çevrimi başına birden fazla FP64 işlemi çıkarabilir
“Çoğu programcı CPU’yu derinlemesine anlar” şeklindeki ilk cümle o kadar açıkça doğru değil ki, yazı harika olabilecek olsa bile geri kalanını ciddiye almak zorlaşıyor
Üniversitede eğlencesine felsefe dersi almıştım; orada bir cümleyi hemen çöpe atmadan daha iyi bir biçime sokup okuma becerisi kazandım. Artık beynim aşırı genellemeleri veya bariz yanlışları bile otomatik olarak makul ölçüde yakın doğru önermelere çeviriyor. Argüman ilerledikçe bu fikirleri yeniden kurabiliyor ve metnin tamamını mantıksal olarak tutarlı değerlendirebiliyorum
Bu sayede kötü yazıları okuduğumda bile ilgilendiğim konular hakkında yeni doğru/yanlış öncüller ve iddialar kalıyor; böylece zihinsel dünyam genişliyor
Üniversitede CPU mimarisinin temel olgularını öğrendim, genel manzarayı çok temel düzeyde biliyorum ve arada sınırlı bilgimi güncelleyen şeylerle karşılaşıyorum; ama buna “derin anlayış” demezdim. “CPU’nun nasıl çalıştığına, tasarlandığına ve kullanıldığına dair temel anlayış” demek daha doğru görünüyor
Assembly’de ustaysanız düşük seviyede CPU kullanmayı “derinlemesine anlıyorum” diyebilirsiniz belki, ama yine de biraz abartılı geliyor. CPU/GPU tasarım uzmanı olmakla da aynı şey değil
Bu yüzden katılıyorum. Yine de yazı ilginç, özellikle diyagramlar iyi
“Çalışma sırasında bir thread’e ayrılan register’lar o thread’e özeldir, başka thread’ler okuyamaz veya yazamaz” kısmının istisnaları var
HLSL’in wave intrinsic’leri ve CUDA’daki benzer özellikler, mevcut wavefront içindeki diğer thread’lerin register’larını okuyabilir. Ayrıca bellek mimarisi paragrafına, cache’in aynı dispatch/grid içindeki thread’ler arasında tutarlılık garantilemediği, ancak çip genelinde küresel olarak bulunan özel bir işlev bloğunun global bellek atomic işlemlerini uyguladığı da eklenebilir
SIMD programlama gerçekten sert
Ekrandaki tüm pikseller üzerinde hesaplama yapmak mı istiyorsunuz? Sorun yok
Dallanma koşulu koymak mı istiyorsunuz? Ah
Neden hâlâ GPU diyoruz? PPU (paralel işleme birimi) daha iyi bir ad gibi geliyor
drone ile quad-copter ilişkisi de buna benziyor
Harika bir yazı. Üstelik GPU’lar yaptıkları iş konusunda aklıma gelen her şeyden daha gelişmiş ve daha performanslı.
Ama SIMD’yi, daha esnek başka paradigmaları öğrendikten sonra “olmasa da olur” kategorisine koymak isterim. Ben MIMD ile kümeleri/transputer’ları tercih ediyorum; bunlar 2000’ler civarında ortadan kaybolmuş gibi görünüyor. Bugünkü durum geliştiriciden veriyi bizzat taşımasını, aynı anda erişilebilen bellek konumu sayısına yönelik keyfî sınırlamalar altında shader yazmasını, GPU/CPU için ayrı diller kullanıp işi mükerrer yapmasını, ışın izleme gibi özellikler için hangi donanımın bulunduğunu bilmesini ve OpenGL/Metal/Vulkan gibi güçlü varsayımları olan framework’lere bağlanmasını istiyor. GPU, beni gitmek istediğim yere asla götüremeyecek bir yan kol; bu yüzden son 25 yıl, yanlış zaman çizgisinde yaşayan biriymişim gibi geçti.
Kabaca söylemek gerekirse, Moore yasasının sona erdiği kısıtlar içinde ölçeklenebilir genel amaçlı CPU; yerel belleğe sahip çok çekirdekli bir yapı olmalı, veriyi copy-on-write içerik adreslemeli bellek ya da başka önbellekleme yöntemleriyle paylaşmalı ve kullanıcının masaüstü bilişim ortamında tüm hesaplama biçimlerini özgürce keşfedebilmesi için tek bir birleşik adres alanı sunmalı. Standart assembly dili kullanır, ama genelde Erlang/Go, Octave/MATLAB ve ideal olarak Julia gibi fonksiyonel programlama dilleriyle programlanır. 3D render ve yapay zeka kütüphaneleri bunun üzerindeki katmanlardır; temel unsur değildir.
İlginç biçimde GPU’lar, benim sözünü ettiğim çok çekirdekli düzene kabaca ulaşmış durumda; ancak sürücüler kullanıcıyı genel amaçlı MIMD için gereken bare-metal erişimden ayırıyor. GPU üstünlüğünü kırmanın tek yolunun FPGA olduğunu düşünüyordum; belki de GPU donanımını birleşik belleğe sahip bir MIMD gibi gösteren bir sürücü yazma fırsatı olabilir. GPU çekirdeklerinin tamsayı işlemlerini ne kadar iyi yaptığına emin değilim, ama 64 bit kayan noktanın 32 bit tamsayı kısmıyla yaklaşık olarak karşılanabilir gibi. Bu tür ödünler yüzünden bir MIMD makinesi GPU’dan 10–100 kat yavaş olabilir, ama CPU’dan 10–100 kat hızlı olabilir. Üstelik mobil pazarın kontrolü ele geçirip performanstan çok fiyat ve güç verimliliğine öncelik verdiği 2007 civarından sonra CPU’ları durgunlaştıran büyük önbelleklere ve hızlı veri yollarına aşırı bağımlı olmadan ölçeklenebilir. MIMD makineleri kümelenerek, kod değişikliği olmadan SETI@home gibi dağıtık hesaplama ağları da oluşturabilir. Sıradan kullanıcıya ne kadar güç kazandıracağını anlamak için, veri değil hesaplama için BitTorrent’e karşı FTP karşılaştırmasına benzetilebilir.
Apple Silicon mimarisinin NVIDIA’dan nasıl farklı olduğunu pek anlayamıyorum.
“Nvidia H100 GPU’da 132 SM, SM başına 64 çekirdek, toplam 8448 çekirdek var” cümlesine bakınca 8448 çekirdek kesinlikle etkileyici. Ama Apple M2 Ultra’da yalnızca 76 çekirdek mi var?
NVIDIA H100 GPU nasıl 110 kattan fazla çekirdeğe sahip olabilir? Kesinlikle M2 Ultra’dan 110 kat daha yüksek performanslı değil; burada neler oluyor?
NVIDIA blogundaki şu diyagrama bakın: https://developer-blogs.nvidia.com/wp-content/uploads/2021/g...
(https://developer.nvidia.com/blog/nvidia-ampere-architecture...)
Elbette her lane için ayrı program counter desteklenmesi açısından buna “thread” demek için bir gerekçe olduğunu hissedebilirler; ama nihayetinde önemli olan ALU’nun hızı ve işlem hacmidir.
Artık makine öğrenmesinin hassasiyet için neden kayan nokta kullandığını anladım. Bu bir tercih değilmiş; grafik kodu öyle kullanıldığı içinmiş
“Makine öğrenmesi neden bu kadar verimsiz?” bulmacasının bir başka parçası
Gerçek ortamlarda bellek kopyalama ek yükünün ne düzeyde olduğunu merak ediyorum. Genelde olduğu gibi çalışıyorsa oldukça acımasız olur. TCP işlemeyi donanıma devredip bundan kaçınacak kadar. Burada veri çok daha fazla, ama daha büyük parçalar halinde işleniyor
Yani kayan noktalı görüntü mini-batch’ini kopyalamak hâlâ yeterince hızlı. Çünkü gradyan/SGD iterasyonu yavaş ve hesaplama yükü çok büyük. Karma hassasiyet kullanılsa bile böyle
Sığ ağlarda yalnızca özgün sıkıştırılmış veriyi GPU belleğine kopyalayıp, açma vb. işlemleri GPU’da yapmanın avantajı olabilir. Ancak modern GPU’ların hâlâ PCIe 5’i benimsememiş olması, ham hesaplama performansının daha önemli olmasından kaynaklanıyor
Son olarak tensor core’ların etkisi de büyüktü ve ağa bağlı olarak çok hızlı oldukları için kullanım oranı çok düşük kalabilir
Eğitim matematiği de sayıların sürekli olduğunu varsayar
Ancak CPU tabanlı LLM’lerin neden quantization yaptığını merak ediyordum. Anladığım kadarıyla bu, ağırlık hassasiyetini düşürerek daha az bellek kullanma süreci
Hassasiyet eksikliğinin fark yaratıp yaratmadığı belirsiz. Öyleyse başta neden kayan nokta kullanılıyor? Hassasiyet önemli değilse, ek hassasiyet gerçek bir neden olmadan daha fazla kaynak tükettirir ve muhtemelen gerekenden birkaç basamak daha fazla kaynak kullanır
Bu alan, performansı anlayan insanlar tarafından başlatılmadı. Araçları kullanıp bir şeyler yaptılar ama “neden” yok. Araç öyle yaptığı için öyle yaptılar
Bunun önemli olmasının nedeni şu: Sıradan CPU’larda bile veriye erişmenin bir yolu, başka bir yoldan birkaç basamak daha hızlı olabilir; ama bunu bilmek gerekir. LLM maliyetini birkaç basamak azaltmak istemez misiniz?
Birkaç yıl önce CPU ve GPU’nun zorlu kısımlarını ele alan şu sunum ve slaytlar da bakmaya değer
Alexander Titov — Know your hardware: CPU memory hierarchy https://youtu.be/QOJ2hsop6hM
https://github.com/alexander-titov/public/blob/master/confer...
Know Your Hardware - CPU Memory Hierarchy -- Alexander Titov -- C%2B%2B Moscow Meetup March 2019.pdf
https://github.com/alexander-titov/public/blob/master/confer...
GPGPU - what it is and why you should care -- Alexander Titov -- CoreHard 2019.pdf