August 25, 2012

Ben daha bir şey düşünmedim ama konferansı kısa tutmanın daha yararlı olduğunu anlamıştık. Sohbete fazla zaman kalmadı.

Ali

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

August 26, 2012

Aslında düşündüğüm planlı olanların dışında bir konferans ancak mümkün olması zor gibi gözüküyor

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

September 09, 2012

bu başlığı başından sonuna heyecanla okudum. bilgisayar bilimlerinde alaylı biri olmama rağmen daha önce hakkında okuduğum ve bir kaç deneyim yaşadığım bir konu olduğu için paylaşayım, bazı sorulara da elimden geldiğinde cevap aramaya çalışayım:

Tanenbaum'un modern operating systems adlı kitabıyla tanışmam, Linus Torvalds'ın kitabını okumam sayesinde oldu. Tanenbaum Minix adlı işletim sisteminin yazarıdır ve kitabını Minix üzerinden anlatmaktadır. Linus ise Linux işletim sistemini yazarken bu kitaptan faydalanmış ancak litabında Minix hakkında yaptığı sert eleştirilerde fazlaca cömert davranmıştır.

Tanenbaum özellikle process management kısmında assembly kullanmak zorunda kaldığını söylüyor. Görevler arası geçiş olabildiğine hızlı olmalı, eğer olamıyorsa tüm sistemi yavaşlatıyor. Bu bağlamda işletim sistemi yazmak konusunda C bile hız konusunda yetersiz kalır. Sonuç olarak process management kütüphanesi D içinde (ve diğer tüm dillerde) internal olarak yazılmadığı taktirde assembly kullanmak şart oluyor.

Bios, işletim sistemi yüklemek için ilk tetiklemeyi yaptığında ortada Bios kesmelerinden başka çağıracak fonksiyon olmadığı için standart kütüphanenin baştan aşağı yazılması gerekiyor. Standart kütüphane ekrana bir harf basmaktan dosya işlemlerine kadar binlerce fonksiyon içeriyor. Dosya açmak için tabi ki bir de dosya sisteminin önceden yazılması işi var. Bir nevi işletim sistemi yazma işlemi ile standart kütüphane yazma işlemi bot bağı gibi birbirine girmiştir (bootstrapping ifadesi bu yüzden kullanılır).

Standart kütüphaneden (nostdlib) ve işletim sistemi kesmelerinden hariç tutularak yazılan tüm programlar zaten birbirine benzer. Bu bağlamda, evet yalnızca D'de değil, tüm dillerde (derlenebilen) işletim sistemi yazmak teorik olarak mümkündür (yazılanlara göre pratik olarak da mümkün) ancak işi derlendiğinde hızlı kod üreten ikiliye bırakmak şimdiki teknoloji ile en iyi yoldur. Tabi ki bu ikili de C ve Assembly. C++ kullanmayı dahi önermeyenler var. Evet bazen sınıflardan nesne üretirken geçen zamana bile tahammül yoktur işletim sistemlerinde.

belki de araştırmayı şöyle yönlendirmek gerekebilir. Standart kütüphane kullanmadan döngüler, degisken ve dizi atamaları D'de ne kadar sürede gerçekleşiyor ve aynı işi yapan C programı için gereken toplam hesap süresi ne kadardır? Eğer D derleyicisi C 'dekine yakın kalitede bir kod üretmişse, C 'ye alternatif olarak yerini alabilir ancak yine assembly kullanmak gerekecek :)

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

September 09, 2012

Merhaba Ali Bey,

Yazmayı ihmal ettiğim şeylere de değinmişsiniz, faydalı olmuş. Şu noktayı düzeltebilirim: Nesne üretilecekse üretilecektir. Evet böyle. Ancak C ve Assembly'de terminolojik olarak nesne üretmek kavramından bahsedemeyiz. (Evet her dilde object orientation taklit edilebilir. C 'de de durum böyledir.) Benim söylemek istediğim, new ve delete operatörlerinin malloc ve free 'den fazlasını yaptığıdır. İşletim sistemi programcısının çoğu zaman istediği şey bir struct'ın (örneğin filesystem'de) belleğe alınması. Öyle ki, bu struct'un üzerine yazılacağı belleğin miktarının yeterli olduğu bile varsayılabilir (tehlikeli olsa da işletim sistemini yazan asıl patrondur).

Test etmedim ancak new, malloc'tan fazla iş yapıyor. Bunun en büyük delillerinden biri yeterli bellek kontrolü için hata denetim mekanizması içermesi ve gerektiğinde bir bad_alloc exception fırlatması. Fazladan 20 ms bir gecikme işletim sisteminin yavaşlaması demektir. Önemsiz olmakla birlikte performans optimizasyonlarında göz önüne alınmaya değer bir durumdur.

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

September 10, 2012

C dilini, Assembly dilinin evcilleştirilmiş hali gibi görmek gerekir. C hem yüksek seviyeli bir dildir, hem de, derleyici tarafından üretilen makine kodunu da ciddi şekilde düşünmek gerektirdiğinden düşük seviyeli bir dildir de (onu yüksek ve düşük seviyeli yapan özellikler sadece bunlar değil). Yani derleyicisini iyi tanıyan bir programcı başka bir dilde, örneğin C'de, assembly diline yakın bir performansa kavuşabilir.

MenuetOS 'u hiç denemedim. Daha sonra incelerim tabi ki. Ama yanlış yolda olduklarını kimse söyleyemez çünkü Linus Torvalds "onu C diliyle yazıyordum ama dışardan bakan biri yazdıklarıma C demez çünkü büyük oranda assembly kullanıyordum" diyor kitabında. Minix için de bunlar kısmen geçerlidir.

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

September 09, 2012

Değerli bilgiler için teşekkürler.

Alıntı (jbytecode):

>

C++ kullanmayı dahi önermeyenler var. Evet bazen sınıflardan nesne üretirken geçen zamana bile tahammül yoktur işletim sistemlerinde.

Nesne üretmek gerekmişse o nesne üretilecek demektir. C++'ın nesne üretirken C'den (veya assembly'den) daha yavaş kalmasını gerektirecek hiçbir sorunu yoktur. Temel C++, sonuçta C'nin hamallık işlemlerini otomatik hale getiren bir dildir. (Aslında şablon olanağı nedeniyle C++ bazı işlemlerde C'den daha hızlıdır.)

Benim bildiğim kadarıyla, C++'ın işletim sistemi gibi ortamlara uygun olmamasının en büyük nedeni, çokşekilliliğin geleneksel olarak vtbl göstergesi ile sağlanıyor olması. Her türün vtbl göstergesi tek olunca ve programın belirli bir noktasında bulununca virtual işlev çağrıları mikro işlemcinin ara belleğinin tekrar tekrar yeniden yazılmasına neden oluyor.

Alıntı:

>

belki de araştırmayı şöyle yönlendirmek gerekebilir. Standart kütüphane kullanmadan döngüler, degisken ve dizi atamaları D'de ne kadar sürede gerçekleşiyor ve aynı işi yapan C programı için gereken toplam hesap süresi ne kadardır?

Evet, en doğru soru o. Ek soru: D'nin veya C++'ın C'nin ürettiğinden daha yavaş kod üretmesine neden olan dertleri var mı?

Yanıt, kullanılması şart olmayan çöp toplayıcı için bile açık değildir: Evet, dmd'nin kullandığı yavaş çöp toplayıcı arada sırada programı durdurup temizlik işleri yapıyor olsa bile o işlemleri toptan gerçekleştirdiği için bir kazanç da sağlıyor. Bu bedelin mi yoksa kazancın mı daha fazla olduğu denenerek bulunabilir.

Ali

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

September 10, 2012

Hakan Hocam,

Peki MenuetOS hakkında ne düşünüyorsunuz? Çünkü tamamen assembly ile yazılmış bir işletim sistemi. Bilmiyorum hiç test ettiniz mi? Ama ortalama bir sistemi destekliyor ve Linux gibi boot (sanırım GRUB ile yükleme) yapılabiliyor.

Benim görüşüm ise C'den daha hızlı olabileceği yönünde. Öyleyse yüksek seviyeli dillere, işletim sistemlerinin içinde çalışacak yazılımları üretmeyi bırakmalıyız. Tabi bir OS'un ne kadar çetrefilli olduğunu belirttiğinizi düşününce tıpkı Linux Kernel'da olduğu gibi C'den de yardım almak akıllıca olmalı...:)

Dip Not: Fuzuli konusunda müsait bir vakitte yine yazacağım inşaallah.

Sevgiler, saygılar...

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

September 10, 2012

Şu Adreste : http://wiki.osdev.org/C%2B%2B

delete ve new operatörlerinin stdlib kullanılmadığı durumda kendimiz yazmak isteyeceğimizi ve bu durumda en basit formun da aşağıdaki gibi olması gerektiğini söylüyor.

// size_t depends on your implementation, the easiest would probably be:
// typedef __SIZE_TYPE__ size_t;

void *operator new(size_t size)
{
   return malloc(size);
}

void *operator new[](size_t size)
{
   return malloc(size);
}

void operator delete(void *p)
{
   free(p);
}

void operator delete[](void *p)
{
   free(p);
}

yukarıdakiler wrapper fonksiyondur. Tabi ki yalnızca wrapper olduklarından ciddi performans kaybı yaşamayız. Yalnızca fazladan fonksiyon çağırım süresi var.

Yazar, bellek ayırdıktan sonra sıfırlama ihtiyacı olabileceğini de söylüyor. Evet yukarıdaki koda bu da güzelce eklenebilir.

new ve delete yukarıdaki gibi sadeleştirilirse (+ sıfırlama) söylediğiniz bir çok şeyde sizle hemfikirim demektir. ama orijinal new ve delete implementation bence işletim sistemi kernelinin hassas kısımlarında sakınca yaratır

ayrıca şu adreste new ve delete'nin optimal yazılmadığı, genel amaçlı olduğu yazıyor:
http://stackoverflow.com/questions/7149461/why-would-one-replace-default-new-and-delete-operators
Alıntı:

>

The new and delete operators work reasonably well for everybody, but optimally for nobody. This behavior arises from the fact that they are designed for general purpose use only. They have to accommodate allocation patterns ranging from the dynamic allocation of a few blocks that exist for the duration of the program to constant allocation and deallocation of a large number of short-lived objects. Eventually, the operator new and operator delete that ship with compilers take a middle-of-the-road strategy.

If you have a good understanding of your program's dynamic memory usage patterns, you can often find that custom versions of operator new and operator delete outperform (faster in performance, or require less memory up to 50%)the default ones. Of course, unless you are sure of what you are doing it is not a good idea to do this(don't even try this if you don't understand the intricacies involved).

:)

güzel bir sohbet oldu değil mi Ali bey? bu altbaşlıkta biriken entry'ler baştan aşağı okunduğunda bir çok bilgiyi hatırlatacak bize.

paylaşım için çok teşekkürler, keyif aldım

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

September 10, 2012

Hocalarım peki madem new operatörünün benzerini yapabiliyoruz; peki C++'da bir karşılaştırma yapabilir miyiz?

Örneğin 1000 nesne için...

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

September 10, 2012

Ali hocam çok zarif bir şekilde konuyu D'ye ve de GC'ye getirmiş. Hele şu günlerde SDL ile programlama yaptığım için D'de yazılımış bu oyun (üstelik 3 ayda yapmışlar!) çok ilgimi çekti. Sanırım OpenGL ile yapmış olmalılar ama Windows'da programladığına göre DirectX kullanmış olabilir mi?

Gerçi konu bu değil başka yerde tartışabiliriz. Ancak GC'deki ve derlemeler arasındaki bu farklar (FPS'ler ve gecikmeler) işin ne kadar ciddi olduğunu gösteriyor. Neyse ki benim gibi amatör programcıların GC'den müzdarip olabilmesi için daha çok fırın ekmek yemesi lazım...:)

Alıntı (Benjamin Thaut):

>

But now that I'm done I will update to 2.060 soon.
Peki hocam 2.060'da durum nedir? Bir ara Ali hocam, DMD güncellendiğinde bir yazılımdan bahsetmişti ama onun bellek kullanımının düştüğünden pek emin değilim. Tabi test şartlarını bilmediğim için kendi denemelerim gerçekçi olmamış olabilir. Ama 2.059 ile son sürüm arasında derleme boyutu dışında hiç bir fark göremedim. Ama daha geç derlediğini söyleyebilirim.
Alıntı (acehreli):
(Yazı koyu gri üzerine daha az koyu gri ile yazılmış! İnanılır gibi değil! :))
Bence hoş olmuş, gözleri yormuyor. Belki ekran ışıklandırmasında bir sorun olabilir.

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