Forum: D Programlama Dili RSS
D ile işletim sistemi
Sayfa:  önceki  1  2  3  4 
Avatar
Salih Dinçer #46
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 7617
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...
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
jbytecode #47
Üye Tem 2012 tarihinden beri · 12 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
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.
acehreli (Moderatör) #48
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4527 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 7617
Öncelikle, umarım C++ veya D'nin işletim sistemi dili olduklarında direttiğim düşünülmüyordur. Eğer uygun değillerse bunun nedenlerini doğru tesbit etmemiz gerekir.

jbytecode:
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.)

"Nesne" terimini yine yanlış kullanıyorum sanırım. Ben C yapılarının nesnelerine de nesne diyorum. Onların assembly dilinde de belleğin bir noktasında oluşturulmuş ve bir kaç veri yazılmış bölgeden farkları yoktur.

C++ bu konuda hiçbir ek bedel getirmez. C++'ta yapılar da sınıflar da hiçbir ek bedel getirmeden C kadar alt düzey kod üretmek için kullanılabilirler ve kullanılırlar da.

new ve delete operatörlerinin malloc ve free 'den fazlasını yaptığıdır.

Kesinlikle. Nasıl assembly ve C'de bellek ayrıldıktan sonra bir de oradaki baytlara bazı değerler yazılması gerekiyorsa (yani "kurulmaları" gerekiyorsa), C++'ın new'ü de aynısı yapar: bellek ayırır ve baytlara ilk değerleri verir (veya programcı istememişse vermez).

İşletim sistemi programcısının çoğu zaman istediği şey bir struct'ın (örneğin filesystem'de) belleğe alınması.

C++'ın güzelliği orada işte. :) Programcı bitlere istediği gibi hükmeder.

new, malloc'tan fazla iş yapıyor.

new, C'nin iki adımlık külfetini teke indirmiştir: yer ayır ve üyelere değer ata. (Ama programcı istemezse değer atanmaz.)

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ı.

Onun için de standart new(nothrow) var: Hata atma bedeli de ödenmez.

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.

Kesinlikle. C++'ın uygun olmadığı tarafları var(dır) ama benim bildiğim kadarıyla yukarıdakiler değil.

Ali
jbytecode #49
Üye Tem 2012 tarihinden beri · 12 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Ş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-r…
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 mesaj jbytecode tarafından değiştirildi; zaman: 2012-09-10, 07:00.
Avatar
Salih Dinçer #50
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
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...
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
acehreli (Moderatör) #51
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4527 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj #49
jbytecode:
en basit formun da aşağıdaki gibi olması gerektiğini söylüyor.

Zaten C++'ın standart new(nothrow)'unun da bir POD tür için aynen öyle olması beklenir. Derleyicinin araya gerekmeyen veya istenmeyen işlemler yerleştirmesi düşünülemez.

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

Eğer derleyici bu işlevlerin tanımlarını görüyorsa çağırım süresi bile yoktur.

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.

C++ o sıfırlamayı POD'ler için bile istendiğinde otomatik olarak yapar. D'de de varsayılan davranıştır ama '=void' söz dizimi ile onun bedeli de ödenmeyebilir. (Hiç önerilmez çünkü rasgele bayt değerleri özellikle çöp toplayıcılı bir ortamde çok tehlikelidir.)

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

Düşününce öyle gibi ama C++'ın POD kavramını düşününce o sakıncaların ne oldukları hâlâ açık değil. Üstelik C++ bize new ve delete'i her tür için ayrı ayrı tanımlama olanağı verdiğine göre çekirdek yazarları o olanaktan tabii ki yararlanacaklardır.

new ve delete'nin optimal yazılmadığı, genel amaçlı olduğu yazıyor:

Her kütüphane yazarının içine düştüğü bir durum o. :) Bir kullanıcıya yaransak diğerini üzeriz. İşte C++'ın güzelliği burada: her kullanıcı davranışı kendi istediği gibi değiştirebiliyor. Hatta nothrow örneğinde olduğu gibi, kendi özel belirteçlerimizi tanımlayarak farklı new yüklemeleri de tanımlayabiliyoruz.

keyif aldım

Umarım hepimiz. :) Teşekkürler.

Ali

Not: Konu C++'a kaydığı için onun üzerinde kaldık. Yoksa D de aynı derecede alt düzeydir. Şu bölüm ilginç olabilir:

  http://ddili.org/ders/d/bellek_yonetimi.html

İlgili olarak, D'nin çöp toplayıcısından bağımsız oyun programı yazmış olan birisi bu işin sıkıntılarını açıklayan bir yazı duyurmuştu. Yazının bağlantısı şuradaki tartışmasının içinde geçiyor:

  http://forum.dlang.org/thread/k27bh7$t7f$1@digitalmars.com

(Yazı koyu gri üzerine daha az koyu gri ile yazılmış! İnanılır gibi değil! :))
Avatar
Salih Dinçer #52
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
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...:)

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.
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.
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
acehreli (Moderatör) #53
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4527 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Salih Dinçer:
GC'deki ve derlemeler arasındaki bu farklar (FPS'ler ve gecikmeler) işin ne kadar ciddi olduğunu gösteriyor.

gdc ile dmd arasında bu program açısından görülen farkın büyüklüğü, dmd'deki yavaşlıkların D ile doğrudan ilgili olmadıklarını da gösteriyor. Bu da hep söyleniyor zaten: dmd'nin şu andaki amacı hızdan çok doğruluk.

Peki hocam 2.060'da durum nedir?

GC konusunda bir fark olduğunu hatırlamıyorum. GSoC D projeleri arasından şu GC'yi geliştirme konusundaydı:

  https://github.com/Tuna-Fish/druntime/tree/gc_poolwise_bit…

O bağlantı şu konunun ikinci mesajında geçiyor:

  http://forum.dlang.org/thread/icthpqzrlhmyccqxnskt@forum.d…

Ali
Avatar
Salih Dinçer #54
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Bir kaç binlik testler yaptım ama her ikisi arasında hiç bir fark göremedim. Yani bir tanesi 'static' üyeli, temsilci üreten bir sınıf olmasına rağmen alıştığımız sınıf ve 'new operator'ü ile aynı tick (uygulamanın başladığı andan itibaren) değeri üretiliyor. Benim yapabileceğim bu kadar, ustalar daha iyi değerlendirecektir...
import std.datetime, std.stdio;
 
immutable çarpan = 100;
alias int delegate (int a) tem;
 
class Temsilci {
  static tem katla (int x) {
    return (int a) { return a*x;};
  }
}
 
class Öğretmen {
  int x;
  this (int x) {
    this.x = x;
  }
  int notVer(int a) {
    return a*x;
  }
}
 
void main() {
  auto ts = Clock.currAppTick();
/*
  Temsilci temsilci[1_000 * çarpan];
  auto d = temsilci[0].katla(5); 
  writeln(d(3));
/*/
  Öğretmen[1_000 * çarpan] öğretmen = new Öğretmen(3);
  öğretmen[0].notVer(5).writeln();
//*/
  ts.writeln();
}
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
acehreli (Moderatör) #55
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4527 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Performans karşılaştırması için yazılmış deneme programları yanıltıcı olabilirler. Örneğin, gerçekten tek Öğretmen nesnesini paylaşan çok sayıda sınıf nesnesi mi istedin?

En iyisi Benjamin Thaut'un yaptığı gibi gerçek programları karşılaştırmaktır. (Aslında o konunun hepsini okumadım. Belki onun bulgularının nedenleri de açıklanmıştır. Belki bazı kodları farklı yazsa o kadar performans farkı görmeyecektir, vs.)

Ali
Doğrulama Kodu: VeriCode Lütfen resimde gördüğünüz doğrulama kodunu girin:
İfadeler: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Özel Karakterler:
Sayfa:  önceki  1  2  3  4 
Bağlı değilsiniz. · Şifremi unuttum · ÜYELİK
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Şu an: 2017-11-22, 05:03:26 (UTC -08:00)