sonraki »

[Levent (Lvnt)]

Üreticiler işlemcilerini geliştirdikçe işlemciler aynı mhz/ghz için daha fazla performans vermeye başladılar. 486 hem cache sebebiyle hemde daha hızlı yapıları sebebiyle aynı mhz'de 386'dan daha hızlı. Pentium'da aynı mhz'de 486'dan 2 kat hızlı. Yani 100 mhz bir pentium 100mhz bir 486'ya göre işleri yarı sürede bitiriyor. Vesaire...

Bu işin sakat tarafları varmı? Çoğu zaman değil ama var. Uyumluluk sorunları olabiliyor (http://www.vogons.org/viewtopic.php?f=46&t=50501). Ya da program geliştirme/optimizasyon sırasında işlemcinin hızlı tarafına denk gelip gelmemek sonucunda hızlandırdım derken yavaşlamalar ortaya çıkabiliyor. Progressive optimizasyon zorlaşıyor. (Bu da benim ilgimi çeken kısmı)

Programı optimize ederken progressive gidebilmek yani hız artışı elde edilen değişikliklerin birbirini iptal etmemesi için şu ana kadar 486 sınıfı bir bilgisayar kullanmam gerekti. Pentium kullanamadım örneğin çünkü pentium'da birbirine paralel iki integer işlemci var. U ve V pipeline. Kod sıralaması uygun olursa (ilk başta assembler değil compiler kullandığımız için DENK GELİRSE desek daha doğru) v pipeline devreye giriyor ve kod aniden iki kat hızlı çalışmaya başlıyor. Ben de ne yaptım da hızlandı bu şimdi diye dağılıyorum.

486 yerine pentium kullanabilmek için bir şekilde V pipeline iptal etmek gerekiyor. Böylece kod yavaş çalışacak ama compile'ler arasında ani hız sıçrama düşmeleri olmayacak.

Başka bir konu başlığında (http://www.commodore.gen.tr/forum/index.php?topic=13549.msg175741#new) cache disable meselesi konuşulunca (o da benzer şekilde tutarlı ama yavaş hafıza erişimi sağlıyor) yine bir bakayım dedim. Pentium ve sonrasındaki işlemcilerin L2, L1 cache'lerini ve V pipeline'lerini kod ile istenildiği zaman disable etme işini uzun zamandır ara ara araştırıyordum. Bir şekilde aklımda kalmış, yapılıyor ama nasıl? İşlemci datasheetlerini bile taradım, aslında oradaymış ama neye bakmam gerektiğini bilmediğim için atlamışım. Bugüne kadar birşey bulamamıştım. Ama bugün buldum:

Cache disable:
http://assembly.happycodings.com/code33.html
http://www.vogons.org/viewtopic.php?f=46&t=41298
http://www.vogons.org/viewtopic.php?f=9&t=33696

Cache ve V pipeline disable:
http://www.vogons.org/viewtopic.php?f=24&t=38613 (pentium p54c test register tr12 parametreleri'nin olduğu kısımda yazıyor. Stmul121.zip de burada)

Daha hiçbirşey denemedim tabii ki. Şu ders işleri bir bitsin başına geçebileceğim. Bu sayede hem 486'nın 66/100 mhz hız sınırlaması ortadan kalkacak hem de bilgisayar açıp kapatmadan istenildiği zaman bilgisayar hızlandırılıp yavaşlatılabilecek (teoride... windows altında olmuyor, gerçek dos modu olması lazım)

Eski oyunlarda uyumluluk sorunları vb denk gelenler denemeler yapmak isteyebilir, yukarıdaki son linkte stmul121.zip var. Onunla sadece pentium değil diğer bir sürü işlemcilerin özellikleriyle oynanabiliyormuş.

[spunky]

[BioMenace]

@Levent (Lvnt),

Bu konuya senin gibi teknik açından olmasa da çıktıları nedeniyle fayda amaçlı kafa yoruyorum. Youtube'da bir kaç video izledim:

1. https://youtu.be/fcAqRbFFQPU
2. https://youtu.be/4oKZqB-y0mE

İlk videoda AMD-K6-III işlemci ile bir bilgisayar kurup 386, 486, Pentium ve High End Pentium olmak üzere 4 farklı mod ile farklı dönem MSDOS oyunlarının nasıl oynanabileceği gösteriliyor.

İkinci videoda ise benzer işlem Pentium 133 MMX bir işlemci ile yapılıyor.

Burada esas yapılan işin işlemci hızını düşürmek olduğunu belirtmiştim. Bu sanırım benim gibi yalnızca oyunlar ile ilgilenen MSDOS'cuları mutlu ediyor. Siz programlama amacıyla ilgileniyorsanız tecrübelerinizi duymak isterim.

Bu arada anlatıldığı üzere işlemci hızının ayarlanabildiği konfigürasyon parçalarının zamanla epey değer kazanacağı malum. Şimdiden buna uygun yatırımlar yapmak lazım.

[Levent (Lvnt)]

Mesele ortak aslında. Oyunlarda da bir program parçasını test ederken de bazen yüksek hız için yapılan numaralar sıkıntı oluşturabiliyor. Çabucak bu özellikleri açıp kapatabilmek kullanıcıya çok zaman kazandırıyor. Bir nevi 386'lardaki turbo tuşu gibi, hakim olduğu hız bandı çok daha geniş.

Bana gelirsek, 10yıl ya da biraz daha fazla zaman önce herhalde inanılmaz çok boş zamanım vardı ki saatlerimi program yazma ve denemeler başında geçirirdim. Bir fonksiyonu kurcalarken tekrar tekrar compile edip işini nasıl yapıyor, doğru mu, hız nasıl değişti, takılma varmı vb bakardım.

Burada kontrol edilemeyen faktörler cache'ler ve işlemcinin hızlandırıcı özellikleri. Programın gideceği yolu bir nevi ana yola paralel otoban gibi benzetme yaparsak programın ne zaman otobana çıkacağını ve hızlı çalışacağını assembly kullanmadan her seferinde tutturmak pek mümkün değil.

Benim tecrübe ettiğim en ağır program parçaları 3d texture mapping. Herşey çok hızlı olmalı, cache'lerden pipeline'lerden sonuna kadar faydalanmalı. Cache pipeline vb disable edip denemeler yapmak ve adım adım en uygun algoritmayı tespit ettikten sonra (yani yeter bundan fazlasıyla uğraşamayacağım artık dedikten sonra) assembly optimizasyona geçip program parçasını cache ve pipeline'leri en iyi kullanacak hale getirmek gerek. (Bu işlere yardımcı olmak  için intel'in v-tune vb programları var bu arada)

Sıkıştırma/açma program parçaları da aynı şekilde cache/pipeline'lerden çok etkileniyor. Birebir uğraşmadım ama ses mix işleme vb de benzer şekilde hassas sanırım.

Bir ara lafı geçmişti clip ve 3gfx programlarını göndermiştim. Bunlar tabii son ürüne çok uzak şeyler, ama denemeler yapmamı kolaylaştırıyor. Clip win32 altında 32-bit texture map yapar, matematik işlemci kullanır, matematik işlemci kullanmayacak şekilde baştan yazmak lazım. 3dgfx 386/486 için ekran kartı hızını kabaca test için yazmıştım, çizgi çizme ve ekran doldurma ile test yapar.
http://www.commodore.gen.tr/forum/index.php?topic=13169.msg154280#msg154280

Daha gerçek işler olarak utah-glx'in nvidia tnt driverinde düzeltmelerim vb var, dri yokken nvidia kartlarda 3d hızlandırmak için onu kullanıyorduk. hexen 2 hammer of tyrion'un macosx'e port edilmesinde de bir miktar emeğim vardır (esas işi yapan özkan sezer, üstüme kalmasın