Bu aralar performansa çok taktığım için fark ettiğim bir ayrıntı.

auto dizi=[1,2,3,4];
auto b = *dizi.ptr;
auto c = dizi[0];

Burada ptr alma işlemimiz direk indekse erişmekten çok daha hızlı :)

Zekeriya

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

Bakalım neler oluyor...:)

void main() {
 ubyte[] dizi=[4, 5, 6 ];
 ubyte a = *dizi.ptr; // mov	BL,[RDX]
 ubyte b = dizi[0];   // mov	CL,[RDX]

 assert(a == b);      // cmp	BL,CL
}

Alıntı:

Alıntı:

Alıntı:

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

Gördüldüğü gibi aslında her ikisi de [RDX] denen yazmaçtan adresi alıyor. Bu da belki de "RoDataindeX" gibi bir şey olmalı? Tek farkı dizinin herhangi bir elemanına erişmeye kalktığımızda tıpkı assert()'de olduğu gibi bir denetleme mekanizmasına tabi tutulduğunu görüyoruz...

Biliyorsunuz; biz dizin değeri olarak en son 2 yazabilirdik. Ama senin örneğindeki adette elemana sahip olduğunu düşünseydik 3 de yazabilirdik. Derlerken hata vermezdi ama çalıştırdığımızda "Range violation" hatası alırdık...:)

İşte bu denetleme farkından dolayı yavaşlar. Aslında bir fark daha var, o da a'nın RDX'i çok dolambaçlı bir şekilde elde etmesi!

İlginç değil mi? Gerçi bu değer b için de kullanılıyor ya...

mov    RCX,RAX
:  :  :
mov    -8[RBP],RCX
mov    RDX,-8[RBP]
:  :  :
mov    BL,[RDX] // a = *dizi.ptr;

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

Belki de yanılıyorum; belleğin -8[RBP]'deki a değişkenine dizi.ptr'yi aslında üst satırda eşitliyor olmalı. BL ve CL yazmaçlarının kullanılmasının sebebi ubyte türündeki bir değeri karşılaştırma isteğimiz olabilir...

Ama neden [RCX]'i tıpkı [RDX] kullandığı gibi kullanmamış? İlginç!

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

Hatta çok daha ilginci, dizi.ptr taaa [RAX]'dan geliyor ve ne hikmetse RAX yazmaçı aynı zamanda dizinin uzunluğu için kullanılıyor. Bunlar her halde 64bit veri türünde genel (R... A-D...X) yazmaçlar. Belki başka derleyici de bunu daha akıllıca yapıyordur!

Çünkü bizim dizi.length'e ihtiyacımız yok ki, onu 3 rakamını koyduğu gibi doğrudan koyabilirdi. Bence bu kodlar çok aptalca çünkü RDX değişmediği halde bunu tekrar a değişkeni diye nitelendirdiğim -8[RBP]'den alıyor. Oysa _D4aptr8__assertFiZv alt yordamında RDX kullanılmıyo rki!

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

Hocam aklıma bir şey daha geldi. (Kodları incelemeye şimdi başlayacağım)

Acaba şu da etkilemiş olmasın. dizi[2] dediğimizde o veriyi kopyalamasından dolayı sorun çıkıyor olmasın? Ayrı bir d dosyası içerisinde bununla ilgili test yaptım hız olarak hiç fark çıkmadı. Ama VM içerisindeki kodlarda testimi yaptığımda ise kodlar aşağıdaki şekilde olunca ciddi bir hız farkı oluyor.

op_inc: asm{ call adresal; }
	datatypes[*registers[*cur.veriler.ptr].ptr].inc( registers[*cur.veriler.ptr] );

//Yavaş Olan kod
//	datatypes[registers[cur.veriler[0]][0]].inc( registers[cur.veriler[0]] );
	mixin(next);

Zekeriya

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

Hocam asm kodlarında bir tuhaflık mı var?

O çok görmeye alıştığım EAX EBX yerine RAX gelmiş :)

Zekeriya

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

Tuhaflığın sebebi 64 bit ortamda çalıştığım için olabilir ama tek tuhaflık bu değil. DMD dışında diğer derleyicilere de bakmamız lazım...:)

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

Evet tahmin ettiğim gibiymiş hatta karşıma daha fazla push komutu çıktı. Sanırım RSI'nın ortasında S harfi bir tür 64 bit stack olmalı. Çünkü dizi için bellekte yer ayrılan alt yordama geçemeden evvel 'mov RSI,3' yerine 32 bit'de sadece push 3 kullanılmış. Sanırm alt yordamda da (extrn _d_arrayliteralTX) pop yapılsa gerek. Kodu takip edemedim, çünkü external imiş...

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

Alıntı:

Kesinlikle 64 bit olmasından dolayı :)

Zekeriya

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