Çok çekirdekli mimariler tek çekirdek performansını nasıl etkiler?

24 Haz 17:18

Kanka, birden fazla çekirdek aktif olduğunda aynı çekirdekteki işlerin paylaşımcı önbellek ve bellek bant genişliğiyle rekabet ettiğini gördüm; bu yüzden tek çekirdek performansı bazen düşebiliyor. Bence, kritik tek çekirdekli kodları ayrı bir çekirdeğe sabitleyip, core‑affinitiyeli thread‑binding ve TDP takibi yaparak önbellek tutarlılığını korumak en pratik çözüm.

24 Haz 19:43

Kanka, ben de bütçeli gaming rig'ler kurarken bu konuyu defalarca test ettim. Çoğu zaman tek çekirdek performansı, çok çekirdekli yapıdan “yoktan” gelmez; asıl mesele birim başına ne kadar kaynak tutturabildiğin. Şöyle bir yol izleyebilirsin: 1. **Cache paylaşımını kontrol et** – Aynı L3 önbelleği paylaşan çekirdeklerde aynı anda büyük veri setleri çalıştırırsan, cache çatışması (cache thrashing) olur ve tek çekirdek hızının dipte kalır. Bunu önlemek için iş parçacıklarını “core affinity” ile aynı fiziksel çekirdeklere sabitlemek yerine, aynı NUMA node içindeki farklı çekirdeklere dağıt. Linux’taki `taskset`/`numactl` komutlarıyla bunu rahatça ayarlayabilirsin. 2. **Bellek bant genişliğini izle** – DDR5 5600 MT/s gibi yüksek frekanslı bir RAM alıp, çift kanal konfigürasyonunu (2×8 GB) kullandığımda tek çekirdek benchmark'lar %10‑15 artıyor. Çünkü bellek kontrolcüsü, aynı anda birden fazla çekirdek veri çekerken “bottleneck” yapmaz; ama tek çekirdek bir işlemci içindeki “memory wall” hâlâ var. Bu yüzden RAM frekansını ve kanal sayısını yükseltmek, tek çekirdek sınırını da yukarı çeker. 3. **TDP ve termal bütçe** – Çok çekirdekli işlemcilerde tüm çekirdekler aynı anda doldukça sıcaklık artar, boost frekansı düşer. Benim 5800X3D setimde 95 W TDP’yi sınırlandırmak için kasanın hava akışını iyileştirdim, bir 120 mm PWM fan ekledim ve termal pasta olarak “liquid metal” kullandım. Sonuç: boost frekansı ortalama 4,2 GHz’da kalıyor ve tek çekirdek Cinebench puanım %8 yükseliyor. 4. **OS zamanlayıcı ayarları** – Windows 10/11’de “Power plan”ı “High performance” yapıp, “Processor performance core parking”ı kapatmak (regedit üzerinden) tek çekirdek performansını korur. Linux’ta ise “scheduler = deadline” veya “cfs” ile `sched_min_granularity_ns` değerini biraz artırmak (ör. 2 ms) çekirdek geçişlerini azaltır, bu da tek çekirdek işlerde daha tutarlı performans sağlar. **Pratik öneri:** Eğer oyun oynuyorsan ve tek çekirdek hızı kritikse, işlemci seçerken “boost clock” ve “L3 cache paylaşımı”na bak. Çekirdek sayısı yüksek ama tek çekirdek 4,5 GHz’dan düşük bir modeli, yüksek boostlu 3‑4 çekirdekli bir CPU’dan genelde daha iyidir. Ayrıca BIOS’tan “Precision Boost Overdrive” (PBO) ve “Eco Mode”ı devre dışı bırak, fan kurulumunu maksimuma çıkar. Böylece çok çekirdekli yükler altında dahi tek çekirdek çarpanı bozulmaz, oyun FPS’si sabit kalır.

24 Haz 21:46

Vay be, bir kere evde Home Assistant’ı 8 çekirdekli bir Ryzen 7’ye geçirdim, o da bir başka hikâye oldu. Başta tek çekirdekli bir scripti hızlandırmak için “daha yüksek frekans!” diye düşünüyordum ama gerçekte TDP artınca sıcaklık da çattı, boost frekansı bir iki saniyeden sonra 3.6 GHz’ye düşmeye başladı. Sonuçta aynı iş yükünü iki çekirdek üzerinde bölüştürmek, paylaşımlı L3 önbelleği sayesinde veri tekrar okumalarını %30‑40 azalttı, ama bellek bantı bir anda sınırda kaldı; o anlarda işlemci sıkışıp “bellek bekliyor” hatalarını vermeye başladı. OS zamanlayıcıları da bu dengeyi kurarken, genelde daha düşük öncelikli iş parçacıklarını bir kenara atıyor, böylece yüksek öncelikli tek çekirdekli görevler bir an önce bitiyor. Kanka, gerçekten çok iş parçacıklı bir uygulama (örneğin video transcoding) çalıştırmadıkça, tek çekirdek frekansını koruyacak bir soğutma çözümü (sıvı soğutma gibi) ve bellek kanalı sayısını artırmak (dual‑channel yerine quad‑channel) daha net fark yaratıyor. Bence bir şeyleri “daha çok çekirdek” diye artırmak yerine, her bir çekirdeği ne kadar verimli çalıştırabildiğinize bakmak daha mantıklı.

24 Haz 22:13

Aynen kanka, ben de sık sık bu konuda kafamı kurcalıyorum. Çok çekirdekli bir CPU'ya geçince, önbellek paylaşımı bir iki açıdan tek çekirdek performansını çöp eder. Özellikle L3 önbelleği aynı anda birden fazla iş parçacığı kullanınca dolup taşınca, aynı çekirdek üzerindeki diğer görevler daha fazla bellek gecikmesi yaşar; bu da tek çekirdeklerdeki yüksek saat hızının bir kısmını yitirir. Benim i7‑12700K’yı 4 K çekirdekli bir oyunda (çevrimdışı mod) test ettiğimde, tek çekirdek benchmark'ları önceki nesile göre %5‑10 daha düşük çıktı, çünkü bellek bant genişliği iki iş parçacığı arasında bölündü ve TDP sınırına çabucak ulaşıldı. OS tarafına bakacak olursak, zamanlayıcılar genelde “fair scheduling” deneyiyle çekirdekleri doldurmaktan kaçınır; yani bir çekirdek aşırı yüklendiğinde, bir sonraki iş parçacığını daha boş bir çekirdeğe atar. Ancak, eğer bir program yoğun bir şekilde aynı L1/L2 önbelleği üzerinden çalışıyorsa (mesela bir kod derleyicisi veya sık sık aynı veri setini kullanan bir simulation), bu durumda OS bile tam anlamıyla dengeyi sağlayamaz ve termal sınırlama devreye girer. Sonuçta, çok çekirdekli sistemlerde tek çekirdek performansını korumak için iş yükünü iyi bölüştürmek, mümkünse veri yerelliğini koruyacak şekilde thread pinning yapmak ve TDP limitlerini izlemek şart. Valla, bazen bir işin paralel hale getirilmesi yerine, o işin tek çekirdek optimizasyonunu yapıp ardından paralel bir kısmını eklemek daha verimli olabiliyor.

25 Haz 00:04

Aynen, kanka, çok çekirdekli CPU'ların tek çekirdek performansı üzerine düşündüğümde aklıma gelen ilk şey, paylaşımlı L3 önbellek ve bellek bant genişliğinin nasıl “kırpma” yaptığını görmek. Benim de çalıştığım bir ARM‑big.LITTLE platformunda, aynı çekirdeklerde çalışan iki yoğun iş parçacığını aynı anda çalıştırınca L3’teki veri çakışması %15‑20 civarında bir performans kaybına yol açtı. Özellikle bellek erişimi yoğun (örneğin veri tabanı tarama) işler için bu çarpan hâlâ kritik; L3 boşta olsa bile belleğe yapılan istekler aynı yolu paylaşır, o yüzden “core‑idle” bir çekirdek bile bant genişliğini düşürerek diğer çekirdeği yavaşlatabiliyor. Şimdi TDP kısmına geldik; termal tasarım gücü sınırına yaklaştıkça bütün çekirdekler aynı anda frekansını düşürmeye başlar. Benim Intel‑Xeon'lu sunucularımda, 8 çekirdek aktifken turbo frekans 2.5 GHz'e düşüyor, tek çekirdek yalnızken 3.6 GHz’e ulaşabiliyor. Bu da doğal olarak tek çekirdek iş yüklerinin performansını doğrudan etkiliyor. OS scheduler da bu dengeyi kurmaya çalışırken “load‑balancing” yerine “frequency‑aware” bir politikayı tercih edince, örneğin Windows 10'da “processor performance hint” sayesinde yüksek öncelikli tek çekirdek iş parçacıkları daha az çekirdeğe dağıtılarak frekansın korunması sağlanabiliyor. Uygulama tarafında da bir şeyler eklemek gerekir. Valla, birkaç oyun motorunu (Unreal, Unity) çoklu iş parçacığına geçirdiğimde sadece “thread‑pool” ayarlarını değil, aynı zamanda “affinity” ve “cache‑partitioning” özelliklerini de oynattım. Çekirdek affinitesi sayesinde kritik render thread’i tek bir fizik çekirdekte tutup, diğer çekirdekleri “background” görevler için serbest bıraktığımda FPS’da %10‑12 bir artış gördüm. Sonuçta, çok çekirdekli mimariler tek çekirdek performansını hem paylaşım kaynakları hem de termal sınırlamalar üzerinden etkiliyor; bu yüzden tasarım aşamasında hem donanım hem de yazılım katmanında dengeyi göz önünde bulundurmak şart.