Gönderen Konu: Eski bilgisayarların yenilerinden daha hızlı olması...  (Okunma sayısı 1196 defa)

0 Üye ve 1 Ziyaretçi konuyu incelemekte.

Çevrimdışı Ref

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 2247
  • Advanced User Simulator
    • ae unutmadan
https://danluu.com/input-lag/

8bit makinelerin daha düşük gecikmeye sahip olduğunun peşinde bir arkadaş... Çalışma sürüyormuş ama şimdiki sonuçlar şöyle:

makine                           latency

apple 2e                           30    1983   1MHz   3.5k
lenovo x1 carbon 4g win   150    2016   2.6 GHz   1G


Çevrimdışı matahari

  • RAAT
  • Retroman
  • *
  • İleti: 90
    • The Blog of Mert Börü
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #1 : 27 Aralık 2017, 17:35:38 »
Bu konunun dile getirilmesine çok sevindim. Her ne kadar birçok kişi için bu bir 'şehir efsanesi' olsa da, işin gerçeği hiç de öyle değil...

Günümüz PC mimarisinin -özellikle de PS4/Xbox konsolların- en zayıf noktası hardware input controller latency. Sanırım hatırlayacaksınız, PS4'ün piyasaya sürüldüğü ilk günden beri yaşanan 'kablosuz bağlantıda gecikme sorunu'nun çözülebilmesi için, yeni bir DualShock modeli geçen yıl Sony tarafından piyasaya sürülmüştü. Sanki bir mucizeymiş gibi tanıtılan (!) bu ürün, aslında gamepad'in pilini doldurmak için kullandığımız mini-USB kablosu sayesinde low-latency sinyal aktarımına olanak tanıyordu. - (Bu tasarımın neden daha önce akıl edilemediği ise tam bir trajedi!)

https://gamingbolt.com/ps4-pro-dualshock-4-controller-offers-minimal-latency-when-connected-to-a-usb-port

Bu ürün güncellemesi sayesinde gecikme süresi biraz olsun azaldı, ancak anakart mimarisinde GPU'ya öncelik sağlamak amacıyla yapılan 'bilinçli tercihler' yüzünden sisteme bağlı diğer tüm donanımların ikinci plana itilmesi gerçeğini değiştirmedi. Latency azaldı, ama hala çok ciddi ve rahatsız edici derecede mevcut!

Bunlar yetmezmiş gibi, işin bir de 'game engine' boyutu var. Onlar da sütten çıkmış ak kaşık değil.

Görevim gereği, 2017 yılı içerisinde yaklaşık 4 ay boyunca Unreal Engine üzerinde 'hardware input controller latency' ile ilgili olarak çok detaylı ölçüm, analiz ve ürün geliştirme çalışmaları yaptım. Unreal Engine’in standart API kullanımında yaşanan gecikme sorunlarını çözmek için bir middleware geliştirdim. Test ortamı için kullandığım konsolda, mevcut Unreal Engine API'ı ile ~0,300ms süren bir input fonksiyonunu override ettim, retro bir yöntemden faydalanarak süreyi ~0,005ms'ye indirmeyi başardım. Her frame'de bu fonksiyonun birçok kez çağırıldığını düşünürsek, 60 frame'lik bir oyunda kabaca 3 frame kazandığımızı söyleyebilirim. - (Aslında bu bir başarı sayılmamalı, zaten olması gereken bu!)

Konuyla ilgili sunumlar yapıp, geliştirdiğim kodu (ismi lazım değil) bir AAA oyun geliştirici firmayla paylaştım. Yaşanan sorunun çok basit bir yöntemle nasıl çözülebileceğini pratiğe dökerek örnekledim. Sunum sonunda aldığım geribildirim beni çok şaşırttı; "Meğer çözüm gözümüzün önündeymiş, ama biz görememişiz!" dediler. Ben de kendilerine "Uyguladığım teknik yeni değil ki, 30 küsür yıl önce ZX Spectrum'da keyboard kontrolünü biz bu şekilde yapıyorduk. Bu standart bir prosedür" dedim. Programlama ekibinin ve bütçesinin başındaki yöneticinin o anki bakışlarını görmenizi isterdim. ;)

Elbette bu, işin sadece yazılım kısmıyla ilgili bir optimizasyon. Bunun bir de anakart mimarisi bazında yapıldığını görebilsek, kimbilir ne ters taklalar attıracağız günümüz PC/konsollarına.

Uzun lafın kısası;
  • Evet, 'hardware input controller latency' olarak adlandırabileceğimiz bir sorun 2017 yılında gerçekten de mevcut.
  • Video oyun sektörünün büyük bir çoğunluğu bu sorunun varlığından bile haberdar değil! Farkında olan azınlık ise mevcut durumu kabullenmiş durumda.
  • Sorunun farkında olan AAA oyun geliştirici firmalar bu sorunu çözmek için Ar-Ge yapmak istemiyor, sorunun varlığını kabul ederek etrafından dolanıyor. Müşteri şikayeti geldiğinde, "Bizim elimizden gelen birşey yok, PS4/Xbox mimarisi böyle" deniyor. Bilinçli AAA oyun geliştirici firmalar ise, bu soruna odaklanan freelancer'ların peşinde koşuyor, çözüm için çok cömert tekliflerde bulunuyor.

Çevrimdışı Alpyre

  • RAAT
  • Retroman
  • *
  • İleti: 41
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #2 : 28 Aralık 2017, 09:34:35 »
Kaygılanmayın John Carmack abimiz o işe el attı, yakında çözer. :)


Çevrimdışı Ref

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 2247
  • Advanced User Simulator
    • ae unutmadan
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #3 : 28 Aralık 2017, 11:03:51 »
Test ortamı için kullandığım konsolda, mevcut Unreal Engine API'ı ile ~0,300ms süren bir input fonksiyonunu override ettim, retro bir yöntemden faydalanarak süreyi ~0,005ms'ye indirmeyi başardım.

0.3 milisaniye mi bu değerler yoksa 300ms mi? Tahminen 0.3 saniye kastediyorsun ki bu devasa bir rakam yahu. Anında farkedilir bu latency.

 
Alıntı
Kaygılanmayın John Carmack abimiz o işe el attı, yakında çözer.
matahari çözmüş zaten, hemen çağırıyorum tıfıl John'u, halletsinler.

Çevrimdışı matahari

  • RAAT
  • Retroman
  • *
  • İleti: 90
    • The Blog of Mert Börü
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #4 : 28 Aralık 2017, 14:14:52 »
0.3 milisaniye mi bu değerler yoksa 300ms mi? Tahminen 0.3 saniye kastediyorsun ki bu devasa bir rakam yahu. Anında farkedilir bu latency.

Hemen açıklayalım efendim...

Önce bir tespit: Ülkemizde ondalıklı sayılar için . (nokta) yerine , (virgül) kullanılıyor olması, haklı olarak hepimizin kafasını karıştırıyor. Biliyorsunuz, şöyle bir sorun söz konusu:

https://tr.wikipedia.org/wiki/Ondal%C4%B1k_i%C5%9Fareti

Bu yüzden Türkçe yazışmalarda mümkün olduğunca bu kurala uymaya çalışarak , (virgül) kullanıyorum. Retrojen'in düzgün Türkçe kullanımı konusundaki hassasiyetine şapka çıkartarak, izninizle alışkın olduğumuz floating point terminolojisi ile anlatmaya çalışayım. ;)

ms = milisaniye

0.300ms = 0.0003 saniye

Normalde 3'ten sonra iki sıfır kullanmamıza gerek yok, ancak 0.300ms'den 0.005ms'ye inişi daha rahat algılayabilmemiz için, her iki sayının basamak sayısını aynı tutuyorum. Sonuçta 0.295ms'lik bir kazançtan söz ediyoruz.

(Meraklısı için NOT: Oyun geliştirme camiasında kullandığımız terminoloji oldukça basit. CPU tabanlı performans ölçümü için cycle, GPU için ms (milisaniye) veya fps (frame/sec) kullanıyoruz. Bunun dışında kalan saniye, mikrosaniye, vs. gibi şeyleri kafa karıştırmamak için kullanmamayı tercih ediyoruz.)

60 frame'lik bir oyun için; 1 frame = 16.6ms

Bu sürenin yaklaşık olarak yarısı (~8ms) sistem ve Unreal Engine tarafından kullanılıyor, bize de diğer yarısı kalıyor. PS4/Xbox için her frame'de çağırılan hardware input controller fonksiyon sayısı 6 (altı). - (PC kullanmamız durumda; keyboard, mouse, vs. yüzünden bu sayı 20'ye kadar çıkabilir!)

6 x 0.300ms = 1.8ms

Bu durumda, her frame'de bize ayırılan ~8ms'lik sürenin kabaca 1/4'ünü harcamış oluyoruz!

Geliştirdiğim middleware sayesinde;

6 x 0.005ms = 0.030ms

İhmal edilebilir bir değer olması sebebiyle, PC/konsol hardware input controller sorununun çok büyük bir bölümünü Unreal Engine içinde çözmüş oluyoruz. Darısı diğer engine'lerin başına...

Çevrimdışı Ref

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 2247
  • Advanced User Simulator
    • ae unutmadan
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #5 : 28 Aralık 2017, 14:53:45 »
Hemen açıklayalım efendim...

yine bende bazı ışıklar yandı :)

Çevrimdışı witchdoktor

  • RAAT
  • Normalleşmiş Retroman
  • *
  • İleti: 709
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #6 : 28 Aralık 2017, 16:00:26 »
@matahari

Ağzım açık kaldı doğrusu. Donanım soyutlama katmanları bu kadar mı işlem gücü (~%25) tüketiyormuş?! Senin uygulaman sayesinde neredeyse 'zero latency' elde edilmiş oluyor. Konu açılmışken DirectInput API'sine XInput çok fazla şey kattı mı? Çoğu kontrolcüyü, XInput desteği olmadığı için (obsolete) yeni oyunlarda malesef kullanamıyoruz da.

Çevrimdışı matahari

  • RAAT
  • Retroman
  • *
  • İleti: 90
    • The Blog of Mert Börü
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #7 : 28 Aralık 2017, 16:41:35 »
Ağzım açık kaldı doğrusu. Donanım soyutlama katmanları bu kadar mı işlem gücü (~%25) tüketiyormuş?!

"İşlem gücü tüketmek" yerine "geciktirmek" dersek, yanıt evet.

Bu durum sadece günümüz sistemlerine özgü bir sorun değil. Eskiden de böyleydi. ZX Spectrum ve Amstrad'da 'frame-precise' ('ekran tarama hızı hassasiyetinde' anlamına gelen bir terim) input handling için 50 frame'den 3-4 tanesinin harcanması gerekirdi. Bu yüzden birçok oyunda, her frame'de tüm input portları kontrol etmek yerine, saniyede 2-3 kez kontrol etmek yeterli sayılırdı. Haliyle, bu da "Tuşa bastım, ama geç algıladı!" sendromunu doğururdu. Birçok oyunun hantal bir gameplay'e sahip olması doğrudan bu sorunla ilintiliydi.

Hardware input controller latency ile ilgili olarak en sorunsuz sistem Amiga'ydı. Joystick + Klavye için işlem sadece 2 raster line sürerdi. İstisnalar dışında, günümüz PC/konsolları bile kablo bağlantılı input okuma taleplerine bu kadar hızlı yanıt veremiyor. Bluetooth bağlantılı gamepad'ler ise bu sorunun zirve noktası!

Mesele, sistemin 8-bit ya da 64-bit olması değil. Asıl mesele, sistem mimarisi üzerinde yapılan 'öncelik ve tercihlerin' arkaplana itilen tüm birimleri perdelemesi. Bu bağlamda, "Eski bilgisayarların yenilerinden daha hızlı olması" başlığı sizi yanıltmasın. ;)

Senin uygulaman sayesinde neredeyse 'zero latency' elde edilmiş oluyor.

Bize ayırılan 8ms'lik sürenin sadece 0.030ms'sini kullanmış olmamız sebebiyle, sanırım öyle diyebiliriz. Gerçek anlamda 'zero latency' için donanım mimarisi bazında iyileştirmelere ihtiyacımız var.

Konu açılmışken DirectInput API'sine XInput çok fazla şey kattı mı?

Katabilseydi, bizim bu taklaları atmamıza gerek kalmazdı. ;)

Çevrimdışı witchdoktor

  • RAAT
  • Normalleşmiş Retroman
  • *
  • İleti: 709
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #8 : 29 Aralık 2017, 09:22:05 »
Hardware input controller latency ile ilgili olarak en sorunsuz sistem Amiga'ydı. Joystick + Klavye için işlem sadece 2 raster line sürerdi. İstisnalar dışında, günümüz PC/konsolları bile kablo bağlantılı input okuma taleplerine bu kadar hızlı yanıt veremiyor. Bluetooth bağlantılı gamepad'ler ise bu sorunun zirve noktası!

C64 de Amiga CIA (8520) çipinin hemen hemen aynısı olan 6526'yı kullanıyor IO arabirimi (belleğe haritalanmış) olarak, bu nedenle neredeyse gerçek zamanlı okumak mümkün (Paddle'lar ise SID çipi tarafından okunuyor). Klavye matrisi için iki ve her bir joystick için birer yazmaç mevcut. Bunların CIA tarafından hangi sıklıkla 'refresh' edildiğini merak ediyorum doğrusu.

Çevrimdışı matahari

  • RAAT
  • Retroman
  • *
  • İleti: 90
    • The Blog of Mert Börü
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #9 : 15 Mart 2018, 14:12:45 »
Yukarıda sözünü ettiğim UE4 Input/Video/Audio gecikme (latency) sorunlarına yönelik geliştirdiğim middleware’in kısıtlı (limited) özelliklerini içeren Unreal Engine uyarlaması (4.19) dün yayınlandı.

Sunulan yeni özellikle ilgili tüm detayları, aşağıdaki linkin "New: Low Input Latency Frame Syncing (Xbox One and PlayStation 4)" başlığı altında görebilirsiniz.

https://www.unrealengine.com/en-US/blog/unreal-engine-4-19-released

Arzu ederseniz, doğrudan bu özelliğe ait Unreal Dokümantasyon sayfasını da ziyaret edebilirsiniz.

https://docs.unrealengine.com/en-us/Platforms/LowLatencyFrameSyncing

Bu özellik, bundan böyle tüm kullanıcılar için ücretsiz olarak UE4 bünyesinde sunulacak. Middleware’in tüm (full) özelliklerini içeren uyarlama ise, sadece "projelerinin geliştirimine dahil olduğum" AAA oyun firmalarına açık olacak.

Üzerinde çalışmaya devam ettiğim bir sonraki uyarlama, UE4 Input/Video/Audio gecikme (latency) sorunlarına yönelik çok daha kapsamlı bir çözüm sunacak. Bu uyarlama, Xbox One ve PS4’e ek olarak, PC ve Mac ile de çalışabilecek.

Çevrimdışı peandoas

  • Retroman
  • ***
  • İleti: 27
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #10 : 15 Mart 2018, 21:41:46 »
@matahari öncelikle tebrikler :)

Konunun açıldığını gördüğümden beri sormak istediğim birkaç şey var ve ancak vakit bulup yazabildim. Konu biraz kayabilir salt input latency değil, output latency ile de alakalı çünkü sorum.10 - 12 yıl önce anesthetic ile birkaç defa bu konuyu tartışmıştık ama yıllardır (en azından benim açımdan) bir gelişme olmadığı için arada bir aklıma gelip gider. Özellikle nightlord ve mataharı’nın bu konudaki bilgileriyle sanıyorum bende merakımı giderebilirim.

Windows Vista çıkana kadar bu sorunun aynısını tüm Linux gui’lerinde yaşıyordum, Vista ile Windows’ta bu eksikliği kapattı diye düşünmeye başladım. Makina ve konigürasyon fark etmeksizin XP sonrası gui’lerin tamamında ben yavaşlık ya da gecikme algılıyorum (zaten GDİ’dan Direct2D’ye taşınan dönem). Linux’ta değişmedi hatta arttı diyebilirim ama basından beri Linux tarafında konuyu genelde gui’nin X üzerinden network protokolü yoluyla platform bağımsız sağlanmasına bağlamalarından dolayı bunu anlıyorum.

Bu fark ettiğim yavaşlık ya da gecikme özellikle arayüzde geçerli, oyunlar ve grafik/streaming için farklı ölçütler vardır eminim. Network ile bağlantılı herhangi bir programın gecikme, yavaşlık sorunu olmasını da beklemiyorum; web dediğimiz şey zaten yapısı gereği zevkli şeyleri bile zevksiz hale getirebilecek derecede yavaş (benim fikrim). En basitinden Bilgisayarım’a ya da bir klasöre tıkladığımda açılması için gereken süreden daha uzun sürede açıldığına eminim. Grafik işlemleri ile ilgili doğru düzgün bilgim olmadığı için hiç oturup programatik olarak ölçüm yapmadım ama gündelik hayatta benim karşılaştırmalarım bu yönde, gecikme kaç saniye ya da ms fark ediyordur bilemiyorum. Çevremde bu farkı gözlemleyen başka birine rastlamadımsa da halihazırda Windows XP ile 7/8/10’u yanyana getirip gösterdiğimde “aaa, evet...” diyebiliyorlar. Yıllar önce anesthetic ile tartışmamızı belirtme nedenim bu aslında, bir muhabbet sırasında konu buraya gelmişti ve sonrasında birkaç kere daha üzerinden geçmiştik. Linux’ta gui işlemlerinin nasıl gerçekleştiğini yine kendisinden öğrenmiştim aynı dönemde.

Windows XP’den Vista ve sonraki nesile geçerken olan şey neydi, merak ettiğim şeylerden birisi bu. Bir diğeri bahsettiğim bu şeyi benim dışında deneyimleyen başkaları var mı? Burada sormamın nedeni matahari’nın yazdığı şu cümle: Bu ürün güncellemesi sayesinde gecikme süresi biraz olsun azaldı, ancak anakart mimarisinde GPU'ya öncelik sağlamak amacıyla yapılan 'bilinçli tercihler' yüzünden sisteme bağlı diğer tüm donanımların ikinci plana itilmesi gerçeğini değiştirmedi. Latency azaldı, ama hala çok ciddi ve rahatsız edici derecede mevcut! Acaba benzeri bir yaklaşım gui’ler için geçerli mi? Ya da şu an elimizdeki bu gui tepkime hızı gayet iyi, standart bu olsun gibi bir yaklaşım mı oluştu? Arkaplandaki pek çok şey için kaynak ayrılırken, arayüze de bu kadar mı kalıyor, donanım soyutlamanın bedeli olarak ödediğimiz vergi midir? 250Mhz işlemcide sorunsuz ve hızlı tepki veren Windows XP’den, 16 çekirdekli ryzen’da Windows 10’un bu tepkimeden kaybetmesi normal mi, bu sayede başka faydalar mı görüyoruz? Ya da yok böyle bir yavaşlama - gecikme, bana ve bir avuç çapulcuya psikolojik olarak öyle mi geliyor?

Yani anlattığım şeyin teknik adı neyse bilemiyorum, belki responsiveness diyebilirim, kullandığım eski sistemlerle aynı değil. Bu gözlem benim gündelik yaşamda sürekli karşılaşıp kafama takılan şeylerden biri sadece, yıllardır bu sistemleri kullanıyorum, herhangi bir zaman kaybı yaşatmadı bana ama aklımda bir yerde sürekli duruyor. Hatta aynı şeyi Android’de fazlasıyla yaşadım, memory management’taki noktaların bile Android’de gözle görülür performans sorunları yaratması bilindiğinden çok ciddiye almadım. Yukarıda bahsetmediğim platform, macOS’ta da aynı şeyleri yaşıyorum ama diğerlerine göre daha iyi keza iOS’ta da öyle. Bu ikisinde bu sorunu nispeten az hissediyorum.

Son olarak “bende neden böyle çalışıyor” olarak algılanmasın. Konfigürasyonlar, driverlar, bilgisayarlar, sistemler değişiyor ama sorun kalıcı. Örneğin Linux’ta rendering için VESA’da kullanılsa, açık kaynak driverlar ya da üretici driverlarıda kullanılsa bu durum değişmiyor. Windows’ta durum aynı, 1.1GHz’lik onboard gpu’lu makinanın sürünmesi tamam ama 3 kusur GHz 16 çekirdek ile el ele çalışan herhangi bir İntel GPU’nun GTX 1070’in ya da RX 580’in 2000’lerdeki gui tepkimesini yakalayamaması bana anlamsız geliyor.

Bu zamana kadar web'de bu konuyla ilgili doyurucu bilgi bulamadım, sorduğum danıştığım kimselerin ya da benzer sorular sorulmuşsa yanıtları genelde "konfigürasyon/donanım/yazılım hatalıdır" ya da "herşey normal hızında, SANA ÖYLE GELMİŞTİR" den öteye gitmedi. Gözlerim bozuk, bana öyle gelmiş olmasını kabullenebiliyorum ama bugüne kadar öyle ya da böyle kullanmış olduğum her cihazın yanlış yapılandırılmış olmasını kabullenemiyorum :).

Çevrimdışı matahari

  • RAAT
  • Retroman
  • *
  • İleti: 90
    • The Blog of Mert Börü
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #11 : 16 Mart 2018, 14:51:58 »
Sorularınızı elimden geldiğince yanıtlamaya çalışacağım. Bunu yaparken, 'doğru bilinen yanlışların' düzeltilmesine de odaklanacağım. Bu bağlamda, biraz uzun bir yanıt olacak. Uyarmadı demeyin! 8)

öncelikle tebrikler :)

Çok naziksiniz, teşekkür ederim.

Özellikle nightlord ve matahari’nın bu konudaki bilgileriyle sanıyorum bende merakımı giderebilirim.

Öncelikle şunu belirtmekte fayda görüyorum; her ne kadar Windows üzerinde C++ ile kodlama geçmişim 1993'e kadar geri gitse de, bu tecrübem beni konunun uzmanı yapmaz. Sonuçta ben bir oyun geliştiricisiyim, tecrübe ve bilgi birikimim bu alanla kısıtlı. Eski bir Microsoft mühendisi ve Direct2D geliştiricisi olan nightlord'un sizi aydınlatması çok daha doğru olur diye düşünüyorum.

Bu bağlamda, aşağıda vereceğim yanıtları 'bir oyun geliştiricinin tecrübeleri' olarak algılamanızı rica edeceğim.

Bu zamana kadar web'de bu konuyla ilgili doyurucu bilgi bulamadım, sorduğum danıştığım kimselerin ya da benzer sorular sorulmuşsa yanıtları genelde "konfigürasyon/donanım/yazılım hatalıdır" ya da "herşey normal hızında, SANA ÖYLE GELMİŞTİR" den öteye gitmedi. Gözlerim bozuk, bana öyle gelmiş olmasını kabullenebiliyorum ama bugüne kadar öyle ya da böyle kullanmış olduğum her cihazın yanlış yapılandırılmış olmasını kabullenemiyorum.

Merak etmeyin, gözlerinizde bir sorun yok. :) Ref'in açtığı bu başlığa verdiğim ilk yanıta dikkat ederseniz, "Her ne kadar birçok kişi için bu bir 'şehir efsanesi' olsa da, işin gerçeği hiç de öyle değil..." demiştim.

Yani anlattığım şeyin teknik adı neyse bilemiyorum, belki responsiveness diyebilirim, kullandığım eski sistemlerle aynı değil.

'Responsiveness' doğru terim. Yaşamış olduğunuz olumsuz deneyim, GUI'nin size yeterince hızlı yanıt/tepki verememesinden kaynaklanıyor.

Konu biraz kayabilir salt input latency değil, output latency ile de alakalı.

Bu da doğru bir saptama. GUI'nin gecikmeli olarak size yanıt/tepki vermesini kabaca 'output latency' olarak değerlendirebiliriz.

Burada sormamın nedeni matahari’nın yazdığı şu cümle: Bu ürün güncellemesi sayesinde gecikme süresi biraz olsun azaldı, ancak anakart mimarisinde GPU'ya öncelik sağlamak amacıyla yapılan 'bilinçli tercihler' yüzünden sisteme bağlı diğer tüm donanımların ikinci plana itilmesi gerçeğini değiştirmedi. Latency azaldı, ama hala çok ciddi ve rahatsız edici derecede mevcut!

Acaba benzeri bir yaklaşım gui’ler için geçerli mi?

Elbette geçerli... Bir zincir, en zayıf halkası kadar güçlüdür.

Makina ve konigürasyon fark etmeksizin XP sonrası gui’lerin tamamında ben yavaşlık ya da gecikme algılıyorum. Windows XP’den Vista ve sonraki nesile geçerken olan şey neydi, merak ettiğim şeylerden birisi bu.

Bu yanıtı, yukarıda sorduğunuz soruların genel bir yanıtı olarak kabul edebilirsiniz.

Windows XP ve sonrası yaşanan sorunların kaynaklarını 3 başlık altında özetlemeye çalışacağım:

1.) İşletim sistemi cephesi

(2001) - Windows XP tanıtıldı. O güne dek sunulan en derli toplu Windows uyarlaması olması sebebiyle tarihteki yerini aldı.

(2002) - DirectX 9 tanıtıldı. Aynı yıl, simultaneous multithreading (SMT) destekli ilk Intel işlemci piyasaya sürüldü. Böylece, çok çekirdekli işlemcilere zemin hazırlayacak 'desktop parallel processing'in ilk adımı atılmış oldu. - (Soru: Windows XP ve DirectX 9 bu geçişe ne kadar hazırdı? Yanıtı bir alt maddede.)

(2015) - Windows 10 ve DirectX 12 tanıtıldı. Sanki mucizevi bir özellikmiş gibi (!) duyurulan 'Multi-Threaded Command Buffer Recording' sayesinde, artık bundan böyle tüm DirectX işlemlerinde ilk çekirdeğe aşırı yüklenmek yerine, yapılacak işlerin diğer çekirdeklere orantılı olarak dağıtılabileceği müjdesi verildi. Bir diğer deyişle, DirectX'in 13 yıldır evenly distributed çalışmadığı itiraf edildi. AMD'nin yayınladığı aşağıdaki iki grafiğe göre, DirectX 11'den 12'ye geçişte ciddi bir performans artışı sağlandığı yadsınmaz bir gerçek.





Çıkarım: Windows işletim sisteminin 'gerçek anlamda' parallel processing mimarisini içselleştirmesi ve tüm altyapısını bu mimariye göre güncellemesi (ya da yeniden yazması) 13 yıl sürmüş gözüküyor! Parallel processing'in verimli kullanımı adına, 2002'den günümüze dek alınan yol bu olmamalıydı diye düşünüyorum. Microsoft'un, Windows parallel processing mimarisini 90'lı yılların Sun Workstation'ları düzeyinde pratiğe dökememiş olması sebebiyle, yaşanan her türlü Input/Video/Audio gecikme, hıçkırma, vb. sorunlarda, Windows'un bu konudaki yetersizliği hiç şüphesiz sorgulanacak yerler listesinde ilk sırada olacaktır.

Tüm suç Windows'un mu? Elbette hayır!

2.) Donanım cephesi

Nostalji: Hatırlarsanız, Amiga ve Atari ST'nin o dönemdeki diğer sistemlere göre en büyük avantajı, yapılacak işleri custom chip'lere dağıtan mimarisiydi. Böylece, hem işlemci üzerindeki iş azalıyor, hem de her chip'in kendi işini yapması sebebiyle kullanıcıya paralel işlem yapma olanağı sunuluyordu. Zaten mantıklı olan da buydu.

(2011) - Intel, anakart üzerinde Northbridge diye bir chip'e artık gerek kalmadığını, bundan böyle Northbridge'in tüm işlevselliğinin işlemciye gömülü (embedded) olarak geleceğini açıkladı.

Sandy Bridge ve sonrası tüm işlemciler,

- PCIe controller
- Memory controller
- Graphics controller (optional)

işlemcinin içinde olacak şekilde tasarlandı ve üretildi. Gözle görülür bir performans artışı oldu. Anakart mimarisi sadeleşti. Üretim maliyetindeki düşüş, işlemci/anakart fiyatlarını görece ucuzlattı. Satan memnun, alan memnun... Ve fakat, ne karşılığında?

İşlemcinin içi sanki yeterince kalabalık değilmiş gibi bir dizi controller'ın çok dar bir alana sıkıştırılması doğal olarak ısı problemini beraberinde getirdi. Intel mühendisleri çözüm olarak, aşırı karmaşık olduğu iddia edilen PCIe controller mimarisini sadeleştirme (!) yoluna gittiler. Eski tasarıma göre, PCIe controller'ın 'lane' olarak adlandırılan tüm veriyolları aynı önceliğe sahipti. Bir diğer deyişle, her lane 'performans bağlamında' bir önceki/sonraki lane'den farksızdı. Sadece Transaction Layer bazında 'no-snoop', 'relaxed ordering' ve 'priority' belirlenebiliyordu. Özetle, aslında olabilecek en yalın mimariye sahipti... Yeni tasarım, eski mimarinin tüm özelliklerinin üzerine hem BIOS hem de yazılım bazında lane önceliğinin değiştirilmesine olanak tanıyacak yeni seçenekler sununca, tabir yerindeyse, mertlik bozuldu. Bazı donanım üreticileri, doğrudan BIOS üzerinden PCIe lane önceliklerini kendisine göre belirleyip, sabitledi. (bkz: Xbox, PS4) Bazı donanım üreticileri de, bu işin kullanıcıya bırakılmasını tercih etti. (bkz: Günümüz anakart üreticileri) Windows da geri kalmadı elbet; donanım üreticilerinin driver geliştirirken bu özelliği dikkate alabilmeleri için gerekli low-level güncellemeleri yaptı.

Sonuç: Konsollarda ağzınızla kuş tutsanız lane priority'yi değiştiremezken, masaüstü PC'ler için "Şu slottaki grafik kartının 16 lane'ini diğer donanımların önüne alıyorum, gerisini onlar düşünsün" benzeri buram buram bilgisizlik kokan forum entry'leri hızla çoğaldı. Size içtenlikle şunu söyleyebilirim ki, kendi kullandığım sistemlerde BIOS'a girip bu priority ayarlarını kesinlikle değiştirmiyorum. Zira, bunca yıllık tecrübem, bu tür bir eylemin 'istikrarsız sistem performansı' olarak bana geri döneceğini söylüyor. Kabaca özetlemem gerekirse; eve giren su hattının birim zamanda taşıdığı su miktarı aynı kaldığı sürece, açılan her yeni musluk diğer musluklardaki su miktarının azalmasına yol açacaktır. PCIe mimarisi buna göre tasarlanmadı. Her lane kendi içinde seri çalışırken, tüm lane'ler birbirleriyle paralel çalışır. Bu mimari, controller yapısı gereği, aynı anda tüm lane'lere eşit hız ve miktarda veri akışı sağlayacak şekilde tasarlanmıştır. Bunun aksini zorlamak, sonuçlarına katlanmamız gereğini beraberinde getirir.

Başta hardware input controller'lar olmak üzere, Video/Audio/CPU cache/PCIe controller/memory controller gibi birçok donanımda, tasarımlarının doğası gereği 'donanım bazında' gecikme (latency) mevcuttur. İhmal edilebilir nitelikte olan bu gecikmeler gayet normal sayılır. Ne zamana kadar? Siz bazı donanımlara öncelik verip, diğer donanımları ikinci plana itene dek... Kişisel görüşümce, PCIe mimarisi üzerinde yapılan değişiklikler hiç yapılmamalıydı, yapılsa bile öncelik belirleme seçenekleri son kullanıcıya hiç sunulmamalıydı.

3.) Yazılım cephesi

Birçok meslektaşım hâlâ parallel processing mantığına kendisini adapte edemedi. İnatla 80'li yıllardan kalma 'serial code execution' temelli kod yazmaya devam ediyor, sonra da "Sistemde o kadar çekirdek (core) olmasına rağmen gözle görülür bir performans artışı yok!" diye yakınıyorlar. Gerçek şu ki, yazılımcıların kendilerini bu konuda 'güncellemeleri' kaçınılmaz. Herşeyi tek bir fonksiyon içinde toplamak yerine, "Acaba ben bu işi diğer çekirdeklere nasıl paylaştırabilirim?" diye düşünmeleri gerekiyor.

Bu konuda kendilerini geliştirmesi gereken yazılımcıların başında, donanım üreticileri için device driver geliştirenler geliyor. Herşeyin paralel çalışması prensibi üzerine kurulu Windows 10 PC'de single-thread çalışan bir Bluetooth device driver, tüm sistemin performansını düşürmek için yeter de artar bile. Bu tür sorunlarla çok sık karşılaştığım için, bırakınız GUI gecikmelerini, mavi ekrana düşecek kadar sistemin boğulduğuna şahit oldum. - Bkz: Pili azalmakta olan Bluetooth klavyenin yarattığı "Paket kayboldu, tekrar gönderiyorum, tekrar gönderiyorum, tekrar gönderiyorum..." trafiğinin, single-thread Bluetooth driver ile yönetilmesi sendromu. :o

...

Bunlar sadece şu anda aklıma gelenler, yazmayı unuttuğum ya da yanlış yazdığım birşey varsa hoş görmenizi rica ediyorum. Zira, konu çok derin, matahari pek yorgun. :)

Çevrimdışı witchdoktor

  • RAAT
  • Normalleşmiş Retroman
  • *
  • İleti: 709
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #12 : 16 Mart 2018, 16:54:22 »
@matahari

Windows'ta paralel işlem mimarisini bilmiyorum ama şunu merak ediyorum; çalışmakta olan program parçacıkları (process?), işletim sisteminin atanmış öncelik ve sistem yüküne göre belirlenmiş 'time slice' süresince çalışmakta iken, aynı anda başka bir 'thread'de başka bir programa ait 'process' çalışamıyor mu? Örneğin; bluetooth sürücüsü bir thread'de belirlenen 'time slice' süresince çalışmakta iken diğer thread'lerde sistem (örneğin GUI rendering) ya da kullanıcı uygulamaları devam edemiyor mu?

Çevrimdışı matahari

  • RAAT
  • Retroman
  • *
  • İleti: 90
    • The Blog of Mert Börü
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #13 : 17 Mart 2018, 00:12:31 »
Sevgili witchdoktor,

İtiraf etmeliyim ki soruyu anlayabilmek için birçok kez üzerinden geçtim, tekrar tekrar okudum... Baktım olmadı, ara verdim. Akşam ailemle birlikte sinemaya gittim. Biraz kafa dağıttıktan sonra eve döndüm. Mesajını tekrar okudum! Nihayet, -haddim olmayarak- bazı kavramların sende tam olarak yerine oturmadığı sonucuna vardım. Bu sebeple, arzu edersen sorduğun sorunun içinde geçen (ve fazladan) birkaç kavramı tek tek açıklayayım. Böylece, sorduğun soruyu da aşağıdaki bilgilerin ışığında dolaylı olarak yanıtlamış olurum diye düşünüyorum. Eğer desteğe ihtiyaç varsa, çekinmeden tekrar sorabilirsin. Aklım erdiğince yardımcı olmaya çalışırım.

NOT #1: Soru Windows için sorulmuş, bu sebeple mevcut Windows terminolojisine uygun olarak yanıtlıyorum.

NOT #2: Hepimizin aynı dili konuşabilmesi adına, "kavramlar" konusunda çok hassasım. Eğer eksik kaleme aldığım ya da yanlış olduğunu düşündüğünüz bir yer varsa, lütfen paylaşınız. Amaç, aşağıdaki kavramları doğru, kalıcı ve en önemlisi herkesin anlayabileceği şekilde açıklayabilmek. Belki böylece, bizden sonrakilerin faydalanması için ardımızda birkaç satır bırakmış oluruz.

...

Application: Açıldığında Desktop üzerinde çalışan program tipi. Çoğunlukla GUI'e sahiptir. Bazı Application'lar GUI olmaksızın da çalışabilir, ama bu onların Service olduğu anlamına gelmez.

Service: Açıldığında arka planda çalışan hizmet tabanlı program tipi. Çoğunlukla GUI'e sahip değildir. Bazı Service'ler GUI'e sahip olabilir, ama bu onların Application olduğu anlamına gelmez. Bu tür hybrid Service'ler bünyesinde GUI amaçlı bir Application katmanı bulunabilir.

Process/Task/Instance: Bir Application/Service'e, hafızaya yerleşip çalışmaya başladığı andan itibaren verilen isim. Task Manager'da listelenebilir nitelikte çalışan her Application/Service bir Process olarak adlandırılır. Yazılımcı jargonunda 'Task' ya da 'Instance' olarak bilinir. (Microsoft Edge browser ile 3 farklı websitesi açtığınızı varsayalım. Ekranda gördüğünüz her Tab, aslında aynı programın farklı Instance'ıdır. Task Manager'da aynı process başlığı altında 3 farklı Instance olarak gözükür). Her Process'in en az 1 adet Thread'i mevcuttur. Tek Thread ile çalışanlara 'single-threaded process', birden fazla Thread ile çalışanlara ise 'multi-threaded process' adı verilir. Hafızada karışıklık olmaması için her Process'in bir ID'si bulunur. İşletim sistemi bazında tüm Process'ler isimleriyle değil, ID'leri ile takip edilir.

Thread: Process'in o anda aktif olarak işlemci üstünde çalışan bölümüne verilen isimdir. Bir Process'e ait birçok Thread aynı anda çalışabilir. Aynı Process’e ait olmak şartıyla; Thread'ler birbirleriyle iletişim kurabilir, bir Thread'e başka bir Thread'in kullandığı bellek ve kaynaklara erişim izni verilebilir. (Farklı Process’lere ait Thread’ler bunu yapamaz.) Bir Thread çökerse diğer Thread’ler çalışmaya devam edebilir. Her Thread’in kendisine ait Stack’i vardır. Hafızada karışıklık olmaması için her Thread'in bir ID'si bulunur. İşletim sistemi bazında tüm Thread'ler isimleriyle değil, ID'leri ile takip edilir. Her Thread'e farklı bir öncelik (priority) atanabilir. Böylece, bazı Thread'lerin diğerlerinin önüne geçmesine (ya da arkasında kalmasına) olanak tanınmış olur.

Device Driver: İşletim sisteminin bir parçası olmak üzere yazılan, temsil ettiği donanım ile işletim sistemi arasında çevirmen (translator) görevi görecek şekilde tasarlanan, Application/Service gibi çalışmayan, Task Manager'da istisnalar dışında gözükmeyen, en az 1 adet Thread'e sahip olmasına rağmen birçok Thread'e hizmet verebilecek şekilde tasarlanan düşük seviyeli işletim sistemi eklentileridir. Device Driver Thread'leri, diğer Application/Service Thread'lerinden bağımsız olarak, işletim sisteminin uygun gördüğü hafızanın özel bir alanında çalıştırılır. Device Driver'ların Thread önceliği, Application/Service Thread'lerinin (ve hatta işletim sistemi Service'lerinin) önüne geçebilir. Bu karar, donanımı üreten firma ve Device Driver'ı geliştiren yazılımcılar tarafından verilir. Memory Leak ve Thread yönetimi konusunda çok hassas olan Device Driver'lar, öncelik (priority) konusunda oluşabilecek en ufak sorunu bile gözardı etmemek üzere tasarlanmalıdır. Bu konuda Microsoft'un yayınladığı çok net (ve bir o kadar da katı) uyulması gereken kurallar listesi mevcuttur. Gözden kaçan en ufak hata, çoğunlukla mavi ekranla sonuçlanır.

Çevrimdışı witchdoktor

  • RAAT
  • Normalleşmiş Retroman
  • *
  • İleti: 709
Ynt: Eski bilgisayarların yenilerinden daha hızlı olması...
« Yanıtla #14 : 17 Mart 2018, 09:26:02 »
@matahari

Detaylı açıklaman için teşekkürler. Windows mimarisine yabancı sayılırım. AmigaOS'da 'running' task'lar, priority önceliği çerçevesinde tahsis edilen 'time slice' (quantum?) kadar çalıştırılıp durdurularak sıradaki 'running' task çalışmaya başlatılıyor. Bu mimaride 10 tane çekirdek de olsa, işletim sistemi kendi sorumluluğunda diğer çekirdeklerde farklı uygulamaların çalışmasına izin veremiyor.

Benim merak ettiğim şu idi aslında;

Örneğin Core i7-8700K spec'lerine baktığımızda 6 çekirdek ve 12 'thread' (izlek?) çalıştırabildiğini görüyoruz. Windows, normalde 'thread'leri bu 12 donanımsal izlek'e kendisi otomatik olarak dağıtıyor mu yoksa uygulamanın aktif olarak buna uygun olarak programlanmış olması mı gerekiyor? Farklı uygulamalarının 'thread'leri, paralel olarak bu donanımsal 'thread'lerde çalışmaya devam ediyor mu?