Alıntı (Salih Dinçer):

Haklısın. Bence 'baş' ve 'son' uygun olur. Birisi baştaki düğümü gösterir, diğeri de sondaki.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Uykudan kaçış yok. Beyin uykusuz öğrenemiyor ve iyi işleyemiyor. Daha geçen gün sporun ve uykunun Alzaymır'ı geciktirdiğini de duydum. :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Geçenlerde bir test yapmıştım ve ubyte veri türünde bağlı listenin 60-70 kat yavaş kaldığın hesapladım. Çünkü gösterge cambazlığında veri türünü değiştirmek çok bir şey ifade etmiyor. Ancak dizilerde en az 10 kata varan hız artışı meydana geliyor. Denemek isteyen sırasıyla ubyte, uint ve ulong arasındaki farkı aşağıdaki kodu deneyerek gözleriyle görebilirler.

/*
 linkedListTest.d (27.09.2012)
*/
import std.array, std.conv;
import std.random, std.stdio;

struct DÜĞÜM {
   ubyte veri;
   DÜĞÜM *bağı;

   this(ubyte data, DÜĞÜM *node) { veri = data; bağı = node; }

   string toString() const {
     string result = to!string(veri);

     if(bağı) result ~= ", " ~ to!string(*bağı);

     return result;
   }
}

void sıralıEkle(ubyte veri, ref DÜĞÜM *bağı) {
 DÜĞÜM *önceki, şimdiki = bağı;
 DÜĞÜM *sonraki = new DÜĞÜM(veri, null);

 while(şimdiki != null && şimdiki.veri < veri) {
   önceki  = şimdiki;
   şimdiki = şimdiki.bağı;
 }

 if(önceki == null) bağı = sonraki;
 else önceki.bağı = sonraki;

 sonraki.bağı = şimdiki;
}

void sıralıEkle(ubyte veri, ref ubyte[] liste) {
 ulong k = ikiliArama(veri, liste);

 with( appender!(ubyte[]) ) {
   put(liste[0..k]);
   put(veri);
   put(liste[k..$]);
   liste = data;
 }
}

ulong ikiliArama(ubyte veri, ref ubyte[] liste) {
 ulong test, low;
 ulong high = liste.length;

 while(low + 1 < high) {
   test = (low + high) / 2;
   if(liste[test] > veri) {
     high = test;
   } else {
     low = test;
   }
 }
 return high;
}

import std.datetime;

void main(string[] args) { // 100000 (yüz bin)
 int tekrar = args.length > 1 ? to!int(args[1]) : 10;
 version(test) DÜĞÜM* testList;
 else ubyte[] testArray;
 ubyte[] rakamlar;

 for(; rakamlar.length < tekrar; rakamlar ~=  cast(ubyte)uniform(0, 100)) {
   auto yüzde = cast(real)rakamlar.length / cast(real)tekrar;
   "\r".write("Rakamlar üretiliyor: %", yüzde * 100);
 }
 "\n".writeln("TEST BAŞLADI...");
 auto ts = Clock.currAppTick();
 foreach(rakam; rakamlar) {
   version(test) sıralıEkle(rakam, testList);
   else sıralıEkle(rakam, testArray);
 }
 debug (on) {
   version(test) writefln("Bağlı Liste:\n[%s]", to!string(*testList));
   else writefln("Normal Dizi:\n%s", testArray);
 }
 writeln((Clock.currAppTick() - ts)/1000.0);
}

Notlar:

• Eğer derlerken -version=test parametresini vermezseniz normal bir dizi oluşturur.
• Hata ayıklamak ve geliştirmek için -debug=on ile ekrana listeleri yansıtabilirsiniz.
• İşlemci hızınız çok fazlaysa ./linkedListTest 100000 parametresini büyütebilirsiniz.
• Hesabı, basitçe iki derleme (test) arasındaki değeri oranayalarak yapabilirsiniz.
• En hızlı denemeyi, 100 bin sayı ve ubyte ile yaptığımda, tam 70 kat hızlı olduğunu gördüm...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Hiç merak ettiniz mi; byte veri türü neden int ve long'dan hızlı?

Sonuçta kullandığımız işlemciler 8 bit değil ve hatta 64 bit yazılım kullandığımızda doğal veri türü long olmuyor mu? Yoksa tersi bir konu mu söz konusu: Belki de işlemci, byte'ları kullanırken 4 veya 8 tanesini birleştirerek bir çok yönden tasarruf sağlıyor...

Yani tek cycle'lık 64 bitlik bir komut ile veriyi 8'er 8'er işleyecek ve de bu byte'larda hız artış demek olacak. Bence burada hızlıca geçilmemesi ve tartışılması gereken ilginç bir konu daha var...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Şurada (http://developer.amd.com/Resources/documentation/articles/pages/ImplementingAMDcache-optimalcodingtechniques.aspx) AMD işlemciler için bir takım kodları gördüm. Ayrıca AMD64 Architecture Programmer’s Manual (http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf)'in ikinci cildinde (sayfa 179), önbellekleme ile ilgili ayrıntılar var. Aslında işin özü, aşağıdaki resimdeki anlatılmış:

http://static.duartes.org/img/blogPosts/L1CacheExample.png
Kaynak: http://duartes.org/gustavo/blog/post/intel-cpu-caches

Anladığım kadarıyla genelde 32 bitlik bir adres hattı (işlemci içinde) var. Veri aynı hat üzerinden mi aktarılıyor bilmiyorum ama 24 biti tanımlama (tag) bitleri olarak kullanıyorlar. Cache structures dedikleri bir yapı var ve her satır genelde şöyle: [ tag ], [ data block ], [ flag ] bits. Data blocks dedikleri veri kümeleri 32 mi 64 bit mi emin değilim. Yukarıda bağlantısını verdiğim PDF'de 7.6.5 Cache and Processor Topology diye bir bölüm (sayfa 186) var orada 8 parçaya bölünmüş 0-63'lük bir yapı gördüm. Belki de uç uca eklenmiş bir sürü bit (satırın kapasitesi kadar) vardır.

Tabi Ali hocam başka bir şeyden bahsetmiş. Yani küçük verilerin önbelleklenme olasılığı fazla demiş. Bu belirsizlik gibi görünüyor ve neyi önbelleklendiğini bilmemiz gerekiyor. O yüzden ikilemde kalmamak için önbelleği eleyebileceğimiz bir test ortamına ihtiyacımız olabilir.

Sevgiler, saygılar...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Ama önce universal tester'a ihtiyaç var. Biraz düşüneyim ve basit bir şeyler geliştireyim. Yarın yeni bir başlık ile sonuçları aktaracağım inşaallah...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Yani bütün türlerde dizinin bağlı listeden daha hızlı olduğunu gözlemliyoruz ama bu hız farkı byte'ta daha büyük oluyor, değil mi?

Bu konunun temelinde verinin işlemcinin ara belleğine sığması konusu vardı. byte dizileri int dizilerinden dört kat, long dizilerinden de sekiz kat daha az yer kapladıklarından onların işlemcinin ara belleğindeyken işlenmelerinin olasılığı daha yüksek oluyor. Bence nedeni o.

Aynı nedenden, sanal belleğin diske yazılıp okunma olasılıkları da byte için daha az olacaktır.

Bir de işlemcinin SIMD komutları (birden fazla veri üzerinde tek işlem) konusu var ama bundan emin değilim. dmd bunları bir kaç sürüm önce desteklemeye başlamıştı. byte ve diğer türler arasında ayrım yapılıp yapılmadığına bakmak gerek.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Ön belleğin etkisini ortadan kaldırdığımızı varsayalım. Tekrar denediğimizde byte'ın işlenmesinin int'ten daha hızlı çıktığını mı göreceğiz yoksa aynı mı olacaklar? Konu o mu? Onun için derleyicinin oluşturduğu koda da bakabiliriz. Hangi yazmaçlar kullanılmış, vs.

İşlemci yazmaçlarını ve onların işlem hızlarını da belgelemiştir.

Ama kabul: Eğer veri byte türüne sığıyorsa byte yeğlenmelidir çünkü daha az bellek tutar. Az belleğin daha hızlı olduğunu da işlemci ara bellekleri etkisiyle biliyoruz.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Denedim, beklemediğim sonuçlar çıktı! Ya bir hata yapıyorum ya da değişken türleri arasında hiç bir performans farkı yok...:(

Özetle bu başlığın ikinci konusu olan veri türleri arasındaki farkın nedeni başka bir şey olmalı. Çünkü universal tester (http://ddili.org/forum/thread/992) böyle bir fark yok diyor...:D

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]