February 24, 2013

Alıntı:

>

Oradaki değişkenler her zaman için yaşayacaklar mı? Eğer değişkenleri çıkartmak gerekmeyecekse en kolayı bir dizi kullanmak olabilir. Diziye ekledikçe dizi büyür.

Yaşaması gerekiyor. Dili mümkün olduğunca dinamik yapmak istiyorum. Ama performanstan ödün vermeden bunu yapmak mümkün değil gibi.

Alıntı:

>

Senin yöntemin diziden daha yavaş kalabilir çünkü malloc'u tek int için çağırıyorsun. (Ek olarak, malloc daha sonradan kullanacığı temizlik bilgisini de yazdığı için istenenden daha fazla yer ayırır.) Dizi ise bellek ayırma bedelini bir çok elemana dağıtarak işler. Çok sayıda eleman için tek yer ayırır.

Test sonuçlarında her nedense daha hızlı çıktı. Malloc temizlik bilgisini yazıyor mu? GC içindeki örneği incelediğimde çöp toplayıcıya mallocla oluşturulan değişkenin adresini atmak gerekiyor.

Zekeriya

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

February 24, 2013

Hocam stack dizisini kaldırdım ve şu en son kodunu attığım malloc yapısını uyguladım ve bir önceki sisteme göre 5 ile 6 kat arası hız artışı oldu ama şu anki hızı hala yavaş :( RhS 1.0 da 500ms sürüyor 2.0 da ise şu an 83ms.

//list~=op(VARIABLE, "print");			// 42264 ms
//list~=op(NEXT);				// 3746 ms
//list~=op(LOAD1, "talha");			// 5431 ms
//list~=op(INC);					// 10044 ms
//list~=op(GOTO, z+2);				// 8122 ms
//list~=op(LOAD1, 5);				// 3845 ms
//list~=op(IS_EQUAL);				// 70000 ms => LOAD1 + IS_EQUAL
//list~=op(LOADPARAM);			// 119952 ms
//list~=op(CALL);					// 60964 ms => VARIABLE + CALL
//list~=op(DEFINE, "yaz");			// 46360 ms
//list~=op(LOAD1, 3);				// 3759 ms
//list~=op(PLUS);					// 84900 ms => LOAD1+ PLUS

Operandların 1 milyon kere çalışması ne kadar vakit aldığını test ettim ve karşılarına yazdım. Bu operandlarda yavaşlamaya sebep olan şeyler giderildiği takdirde belki de php'den daha hızlı bir dil olabilir

Zekeriya

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

February 24, 2013

Test konusunda şöyle bir önerim var:

Eğer her bir 'operant'ı (işleç çarkını) defalarca çalıştırırsan, belki işlemci önbelleğine girmesinden dolayı aldatıcı bir sonuç elde etmene sebep olabilir. Bunun yerine rasgele seçilmiş 100 tanesini (sanki bir yazılım parçası gibi) bir diziye yerleştirdikten sonra çalıştır. Sonra sonucu 10 bin defa üretip ortalamasını al.

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

February 24, 2013

Alıntı (zekeriyadurmus):

>

Salih hocam, Ali hocam bu çöp toplayıcılar başıma bela oldu :)

Sorunun çöp toplayıcı ile ilgili olduğundan emin misin?

Alıntı:

>

Aşağıdaki gibi diziye atınca sıkıntı olmuyor. Dizi varlığını devam ettiriyor.

Dizi varlığını neden sonlandırsın ki zaten.

Alıntı:

>
> this(bool val = true){ tmpbool~=val; this.typ = DT.BOOL; this.val = &tmpbool[$-1];}
> ```


**Ek:** Yanlış anlamışım: ~~Yani diziyi bir yandan büyütüyorsun ama bir yandan bir önceki son elemanın adresini yeni son elemana atıyorsun. Dizi kendisi için daha büyük bellek ayırıp elemanları oraya kopyaladıkça senin elemanlar daha önceden kullanılmış olan ama artık yetersiz kaldığı için dizinin kullanmadığı bellekteki elemanları gösteriyorlar.
~~
O eski bellek alanını gösteren elemanlar bulunduğu sürece eski bellek alanları da çöp toplayıcı tarafından canlı tutulmaya devam ediyor.

Alıntı:
>
> GC yi kapatıp direk val adresini atınca ise değişken hafızadan siliniyor :(
>
>

this(bool val = true){ GC.removeRange(&val); GC.disable();this.typ = DT.BOOL; this.val = &val;}

val yerel bir değişken? Çöp toplayıcı yalnızca dinamik bellekle ilgilenir. O yüzden removeRange'in doğru olduğunu sanmıyorum.

Aynı nedenden, this.val'e geçici bir değişkenin adresini vermen de yanlış olmuş. Acaba parametre 'ref bool' mu olmalı. Tabii o zaman bile çağrılan yerdeki bool'un uzun süre yaşayacağını garanti etmen gerekiyor. Örneğin o da yerel bir değişken olamaz.

Ali

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

February 24, 2013

Alıntı (zekeriyadurmus):

>

Ref bool olduğu zaman OP(123) gibi bir değer gönderemiyorum.

İyi ki öyle. :)

Alıntı:

>

sonuçta 123 değeri hafızada bir yerde duruyor. Oluşturulmuş 1 kere silinmesin hafızadan. Hep dursun.

O zaman dinamik bellekte bir yerde durması şart. Program yığıtı (stack) dinamik bellekten kat kat hızlıdır ama o değişkenler geçicidir.

Alıntı:

>

Sanırım bu işlemler için hafıza yönetimiyle ilgili bir sınıf yazmak gerekecek. Kendi çöp toplayıcım, veri yapımı oluşturmalıyım.

Oradaki değişkenler her zaman için yaşayacaklar mı? Eğer değişkenleri çıkartmak gerekmeyecekse en kolayı bir dizi kullanmak olabilir. Diziye ekledikçe dizi büyür.

Senin yöntemin diziden daha yavaş kalabilir çünkü malloc'u tek int için çağırıyorsun. (Ek olarak, malloc daha sonradan kullanacığı temizlik bilgisini de yazdığı için istenenden daha fazla yer ayırır.) Dizi ise bellek ayırma bedelini bir çok elemana dağıtarak işler. Çok sayıda eleman için tek yer ayırır.

Ali

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

February 25, 2013

Alıntı:

>

Eğer her bir 'operant'ı (işleç çarkını) defalarca çalıştırırsan, belki işlemci önbelleğine girmesinden dolayı aldatıcı bir sonuç elde etmene sebep olabilir. Bunun yerine rasgele seçilmiş 100 tanesini (sanki bir yazılım parçası gibi) bir diziye yerleştirdikten sonra çalıştır. Sonra sonucu 10 bin defa üretip ortalamasını al.

Evet öyle bir durum var ama her işlecin sonuç olarak max bir çalışma süresi olmalı.

Sadece var(false) tanımlaması 43760 ms sürüyor. Hiç işlem yapılmadığına ise yani op_next operandı 3746 ms sürüyor.

Malloc'a alternatif olarak kullanabileceğimiz bir yöntem var mı acaba?

Zekeriya

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

February 25, 2013

Kendi malloc() işlevini yazmak...:)

Endişelenme, mutlaka yapılmışı bir yerlerde vardır. Hatta dur GitHub'a bakalım; işte: https://github.com/msandt3/MALLOC

Sanırım burada kilit nokta bir bağlı liste (linked list) oluşturmak:

struct metadata {
 short in_use;
 short size;
 metadata* next;
 metadata* prev;
}

İşte bunu çeşitli işlevler ile kurup kontrol altına alıyor. Kurarken içerikleri boş ve herhalde bir şekilde adresleri döndürülüyor. Bu konular beni aşıyor ama bir gün girmek isterim. Belki big/little-endian bilgisine bile ihtiyaç olmayacak kadar basittir.

Özetle, bu projeyi D'ye çevirebileceğimizi düşünüyorum...

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

February 25, 2013

Salih hocam yapıda bazı değişiklikler yaptım daha önceki belirtmiş olduğum hız değerlerinden daha hızlı bir yapı elde edebildim. Ama hala istediğim hız bu değil. Hala bir şeyleri yanlış yaptığımı biliyorum :( Ve register benzeri bir yapı yaptım.

Yeni hız değerleri

//				list~=op(LOAD, 0, 1);//4909
//				list~=op(VARIABLE,0, "print");		// 41264 ms
//				list~=op(NEXT);						// 2642 ms
//				list~=op(LOAD,0, "talha");			// 5054 ms
//				list~=op(INC, 0);					// 9430 ms
//				list~=op(GOTO, z+2);				// 6983 ms
//				list~=op(LOAD, 0, 5);				// 4999 ms
//				list~=op(IS_EQUAL,2,0,1);			// 56307 ms => LOAD1 + IS_EQUAL
//				list~=op(LOADPARAM, 0);				// 4732 ms
//				list~=op(CALL, 0);					// 20226 ms
//				list~=op(DEFINE,0, "yaz");			// 35822 ms
//				list~=op(TIMES, 3, 0, 1);			// 46959 ms

Zekeriya

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

February 25, 2013

Alıntı:

>

Kendi malloc() işlevini yazmak...

Pek gözüm kesmiyor açıkçası :) Veri yönetimi hakkında hiç bilgi sahibi değilim. Bunları iyice öğrenmem gerek mükemmel olmasa da mükemmele yakın bir kod yazmak gerek :)

Zekeriya

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

February 25, 2013

Bu test sonuçlarını hangi kodlar ile elde ediyorsun? Bir örneğini depoya koyarsan, yarı yarıya indirmeye çalışırım...:)

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