Programın başında çöp toplayıcıyı direk devre dışı bırakabiliyormuyuz ? Bırakabiliyorsak bunun maliyeti pahalımıdır yada şöyle sorayım çöp toplayıcıyı devre dışı bıraktığımızda programın çalışma esnasında bize hız yönünden birşey kazandırırmı ?

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

tamda tahmin ettiğim gibi.. Ancak programımızda iyi bir bellek yönetimi ile çöp toplayıcının iptali sanırım C# den C/C++ a geçiş gibi birşeyler olsa gerek ancak bunun için elbette gerçek anlamda çöp toplayıcının iptal edilmesi gerekir . Korkum şuki Aslında program çalışırken çöp toplayıcı hafızada yerini alıyor ise ve biz bunu sadece komutlar yardımı ile donduruyor isek sanırım bu beklediğim bir hız kazanımı sağlamayacaktır Kaldıki eğer D aynı zamanda sistem programlama dili olarakta anılacaksa bence bu konu önemli diye düşünmekteyim..

bu arada belki başka konuya geçiş olacak ancak D de son durum nedir ilerlemeler hakkında bir gelişme varmı son zamanlarda ?? özellikle bayağı bir geri kalmış çöp toplayıcıda bir düzenleme oluyormu ?
tekrar teşekkürler :)

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

Çöp toplayıcı belirsiz zamanlarda belirsiz süreliğine işleyebildiği için programda tutukluğa neden olabilir. O yüzden, devre dışı bırakmak da kendi istediğimiz zamanlarda işletmek de algısal olarak hız kazancı sağlayabilir.

Bazı programlar ise bir kere çalışıp sonlanmak içindirler. Örneğin, ls gibi araç programların çöp toplanmasına hiç ihtiyaçları olmayabilir. Bu gibi programlarda çöp toplayıcı baştan iptal edilebilir ama bunun hissedilir bir yarar sağlayıp sağlamayacağı baştan bilinemez. Neyse ki denemek tek satır ve bedava. :)

Çöp toplayıcıyı iptal etmenin hız açısından zararı, programın kullandığı belleğin giderek artması ve diske yazılmasının gerekmesi olabilir. Bunları da denemeden bilmek olanaksız. :-/

Ali

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

Alıntı (cos00kun):

Henüz mümkün değil çünkü hem Phobos hem de druntime çöp toplayıcıdan yararlanıyor. (Örneğin, temel olanaklardan olan dizileri çöp toplayıcıdan ayırmak olanaksız.) O yüzden, eğer gerçekten bir sorun varsa ya kendi kütüphanelerimizi kullanacağız ya da çöp toplayıcının az kullanımını kabul edeceğiz.

Alıntı:

Neden öyle düşünüyorsun? Evet, programın yüklenmesine milisaniye düzeyinde yük getirirken her çöp toplama işlemi programına göre saniyeler bile sürebilir. O yüzden bence yine de büyük kazanç sağlar. Ama hep söylenmesi gerektiği gibi, programın gerçekten böyle bir sorunu olup olmadığına bakmak gerek.

Alıntı:

Kesinlikle.

Alıntı:

Çöp toplayıcı konusunda Sociomantic'in multithreaded toplayıcısı D1'den D'ye geçiriliyordu; son gelişmelerden haberim yok ama bir gelişme olsaydı duyardım.

Dernek bazı insanlara para ödemeye başladı; bir kaç tane de maaşlı eleman tutmayı düşünüyor ama bunu benden duymuş olmayın çünkü henüz genele duyurulduğunu sanmıyorum.

2.072 çıkmak üzere:

http://dlang.org/changelog/2.072.0.html

Kayda değer değişiklikleri çıkınca (ve daha çok bilince :) ) konuşuruz.

Ali

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

Peki Ali bey şahsi olarak siz D dili ile Windows gibi bir işletim sistemi mesela Lindows (elbette Assambly v.s. ile yazılan bölümleri hariç ) yazılabilirmi ve bu performanslı olabilirmi ?
Gerçi forumlardaki cevap stilinizi düşünerek "Yazılmaması için bir sebep yok" dediğinizi duyar gibiyim :) ancak bir kıyas yapacak olursak; bu D ile yazılacak bu işletim sistemine göre çöp toplayıcısız bir C / C++ diliyle yazılacak Lindows a göre gerçek anlamda bir performans kaybı yaratmazmı D deki çöp toplayıcının çokta gelişmemiş olduğunu farzedersek ?
Açıkçası çöp toplayıcı sizinde söylediğiniz gibi birçok programcının bellek yönetiminden daha hızlı kod üretir ancak yinede çok profesyonel bir üretim için yada çok bağımsız alt seviye bir dil içinde biraz hız kaybettirir diye düşünmekteyim Yinede uzman olan sizlersiniz elbet ukalalık etmeyeyim :)
mutlu günler...

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

Alıntı (cos00kun):

D ile gelen çöp toplayıcı kullanılmazsa evet, yazılabilir ve performanslı olur.

Alıntı:

Diyorum çünkü performansın işletim sistemi kadar önemli olduğu ortamlarda D kullanıldığını biliyorum. (Sociomantic, Remedy, Weka, vs.)

Alıntı:

Weka gibi bazı firmalar çöp toplayıcıyı kritik yerlerde hiç kullanmıyorlar. Örneğin, C ve C++'ta olduğu gibi kendi belleklerini yöneten veri yapıları kullanıyorlar. Kritik olmayan yerlerde ise çöp toplayıcıdan hiç kaçınmıyorlar. Örneğin, kullanıcının sistem ayarlarında yaptığı değişikliklerin işlenmesi sırasında çöp toplayıcı kullanılabilir ve kullanılıyor.

Kritik olan yerlerde de "şu işlem 10 milisaniyeden uzun sürmemeli" gibi katı kurallar olunca süre ölçümlerine bakarak oralardaki çöp toplayıcı kullanımı kaldırılıyor.

Özetle, söylediklerinde haklısın ama bunlar D'nin sistem programlamada kullanılmasına engel olmuyor. Bunun yanında, kullanan firmalar D'nin kazandırdıklarını öve öve bitiremiyorlar. Bunun için DConf'lardaki özellikle Sociomantic, Remedy, Weka, vs. firmalarının konuşmacılarını öneririm.

Tabii, işin doğrusu, D de zemzemle yıkanmış değil (bu deyim hâlâ kullanılıyor mu? :) ) ama D'nin derleme zamanı olanakları gibi bazı olanaklarının ne kadar yararlı olduğunu anlatamam. Örneğin Wekacıların D'den şikayetleri de var ama hepsi de C ve C++ programcıları oldukları halde kesinlikle D'nin büyük bir kazanç olduğunu düşünüyorlar.

Ali

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

Alıntı:

 cos00kun:
D dili ile Windows gibi bir işletim sistemi mesela Lindows (elbette Assambly v.s. ile yazılan bölümleri hariç ) yazılabilirmi ve bu performanslı olabilirmi ?

çöp toplayıcıyı kullanmazsak evet den kastınız çöp toplayıcıyı program başında durdrurmaktan bahsediyosunuz değilmi ? bildiğim kadarıyla ve sizinde söylediğiniz kadarıyla tamamen devre dışı bırakmanın imkanı yoktu.

Bu arada zemzem suyuyla yıkanmamış v.s. tabirler en azından benim gibi yaşı 40 geçmiş insanlar için hala kullanılıyor merak etmeyin :)
değerli bilgiler için teşekkürler ....

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

Alıntı (cos00kun):

Doğru. Çöp toplayıcıdan bellek ayıran olanakların kullanılmamasından bahsediyorum. Örneğin, D'nin kendi dizileri kullanılamaz (eleman ekleme gibi işlemlerinden bahsediyorum; yoksa diziler yine de kullanılabilir). Gerçek hayattan alınmış bir örnek göstereyim. Aşağıdaki setGuid'in iki yüklemesi var. İkincisi, UUID türünden string'e dönüştürüp birincisini çağırıyor.

import std.uuid : UUID;

private string currentGuid;

void setGuid(string guid) {
   currentGuid = guid;
}

unittest {
   setGuid("42");
   assert(currentGuid == "42");
}

void setGuid(UUID guid) {
   import std.conv : to;
   setGuid(guid.to!string);    // <-- to BELLEK AYIRIR
}

unittest {
   const ubyte[16] bytes = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 ];
   setGuid(UUID(bytes));
   assert(currentGuid == "01020304-0506-0708-090a-0b0c0d0e0f10");
}

void main() {
}

Oradaki setGuid'in bellek ayırmasına hiç gerek olmadığını farkedip ikinci setGuid'i şöyle değiştirdik:

import std.uuid : UUID;

private string currentGuid;

void setGuid(string guid) @nogc nothrow {    /* <-- @nogc (ve nothrow) ekledik
                                             *     (Aslında önceki kodda da ekleyebilirdik; unutulmuştu.) */
   currentGuid = guid;
}

// Değişiklik yok:
unittest {
   setGuid("42");
   assert(currentGuid == "42");
}

void setGuid(UUID guid) @nogc nothrow {    // <-- İşlemleri değiştirerek @nogc (ve nothrow) ekleyebildik
   // UUID'nin ne uzunlukta string gerektirdiğini derleme zamanında hesaplıyoruz:
   enum size_t guidStringLength = () {
       return UUID.init.toString.length;
   }();

   // O kadarlık yer ayırıyoruz (static olduğundan her seferinde ayrılmıyor):
   static char[guidStringLength] guidBuffer;

   // std.uuid'nin verilen ara belleğe yazma olanağı varmış; kullanıyoruz:
   guid.toString(guidBuffer[]);

   // Değişken şimdi bu static belleği gösteriyor:
   setGuid(cast(string)guidBuffer);
}

// Değişiklik yok:
unittest {
   const ubyte[16] bytes = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 ];
   setGuid(UUID(bytes));
   assert(currentGuid == "01020304-0506-0708-090a-0b0c0d0e0f10");
}

void main() {
}

Ali

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

Selamlar,

Sizlerden daha az tecrübeli bir programcı olarak birşeyler eklemeye çalışacağım.

Büyük programlarda referans sayımı kullanan akıllı göstericiler ve çöp toplayıcı olmadan geliştirme gerçekten imkansız oluyor. Özellikle C dili ile yazılan projelerde bu sıkıntı çok baş gösteriyor ve bir noktadan sonra günleriniz valgrind gibi "memory leak" arayan programlarla geçiyor.

Aslında gerçekten hızın gerektiği ve "big data" gibi data ile uğraşan programlarda çöp toplayıcı bir dezavantaj değil avantaj oluyor. Sociamantic firması ile görüşmelerimde bu dili çok sevdiklerinden değil gömülü çöp toplayıcılı bir dile ihtiyaçları olduğu için şeçtiklerini söylemişlerdi.

Bunun sebebi biz ne zaman bir "allocation" ve "deallocation" yapsak PCI üzerinden memory'e gitmemiz gerekiyor. Ramlerin donanımsal yapılarından dolayı "deallaction" özellikle çok fazla zaman alıyor. Biz referans sayımı veya kendimiz "deallocation" işlemini yönettiğimizde her "free" veya "delete" çağırıldığında bu maliyete sebeb oluyoruz. Yani bir sakız almak için sürekli bakkala gitme masrafı ödüyoruz.

Fakat çöp toplayıcılar "işaretle ve süpür" mantığında çalıştıkları için belirli bir sürede biriken çöpü toptan siliyorlar. BUnu yaparken kullandıkları "Breath First Search" gibi algoritmaların maliyeti yukarda belirtiğim donanım maliyetleri yanında çok küçük kalıyor. Artık bakkala gittiğimizde 1 haftalık sakız ihtiyaçımızı almış oluyoruz.

Çöp toplayıcıların en büyük sorunu bahsettiğiniz gibi bu donma süresi oluyor bunlada iyi çöp toplayıcı uygulamaları başa çıkabiliyor.

Saygılarımla
Erdemdem

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

Çok güzel ve bilgilindirici bir mesaj attınız bence bunun için teşekkürler... sadece yazdıklaırnızda ufak bir paradox var aslında... çöp toplayıcı büyük programlarda gerekli oluyor lafı :-) oyun programlarken de sanki düşman oluyor gibi.. bence sanki çok profesyonel yazılımlar için çöp toplayıcı pahalı ama az profesyonel programcı yada programlar için ucuz maaliyetli bir yöntem gibi... öyle olmasaydı sanırım tüm oyun programları c/c++ yerine c# ile yazılırdı diye düşünüyorum.. tartışmaya açık bi konu gibi ama benim aklım ancak bu kadarına yetiyor .. saygılar sevgiler...

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