Search Results for: uml

Java Yavaş mı? : Java’nın Performansı Üzerine – V (Binnur ve Yaşar’ın Yorumları)

Java ,

Bir önceki yazıda, bu günlüğü takip eden C++ severlerin, C++’ın performans ölçümleriyle ilgili olarak yaptığı itirazlar üzerine, benim ve C++ uzmanı bir arkadaşımın yaptığı yeni ölçümleri yayınlamıştım. Bu son yazıya bilgin ve yetkin arkadaşım Binnur da yorumda bulundu. Bu seriden daha önce yayınlanmış bir başka yazıya yine bilgin ve yetkin bir başka arkadaşım Yaşar da yorumuyla katkıda bulunmuştu. Ben bu yorumları bu yazıda bir araya getirip size topluca sunmak istedim.

 

Binnur’un Java Yavaş mı? : Java’nın Performansı Üzerine – IV yazısına yorumları:

İlk yorumu:

1. Java kodunun başarımını jmh ile ölçmek daha doğru olurdu. Güzel bir haber: jmh, jdk 9’un içinden hazır çıkacak.
2. -O3 seçeneği ile derleyici kodu en iyiler ancak artık hata ayıklayamazsınız. Kullanılan en iyileme teknikleri durağan tekniklerdir. Derleyici kodun ancak durağan analizini yapabilir ve hızlandırmak için yapabilecekleri bu nedenle kısıtlıdır. Ancak java’da en iyileme kararları yürütme zamanında dinamik olarak verilir. JIT derleyici metodun tek şekilli, iki şekilli ya da çok şekilli olmasına göre değişik en iyileme tekniklerini uygulayabilir. Örneğin tek şekilli bir metodu inline edebilir. Bir metoduntek şekilli, iki şekilli ya da çok şekilli olması yürütme zamanında uygulamanın aldığı şekle göre zamanla değişen bir durumdur. C++’da derleyici virtual tanımlı metodun tek şekilli mi, iki şekilli mi yoksa çok şekilli mi olduğunu bilemez. Bu nedenle virtual tanımlı bir metodu her zaman virtual table üzerinden bağlamak zorundadır. Açıkçası bunu c++ geliştiricisi de bilemez, hatta kaliteli bir nesneye dayalı tasarımda bilmemelidir de. Bu JIT derleyicinin yapabildiklerine ilişkin basit bir örnek. Daha başka bir çok dinamik en iyileme tekniği bulunuyor.

Benim “Ben C++’ın da run-timeda performansını arttırıcı, senin dynamic iyileme (optimization) yapan yapıların geliştirildiğini okumuştum bir yerlerde. Senin bilgi var mıdır? Paylaşabilir misin?” şeklindeki sorum üzerine ikinci yorumu:

1. Profile guided optimization
https://msdn.microsoft.com/en-us/library/e7k32f4k.aspx
2. Burada Java’da yazılmış bir uygulamanın, C++’da yazılmış bir uygulama kadar hızlı koşabildiğini ve bazen de şartlar oluşursa daha hızlı koşabildiğini bilmek gerekir. Kötü bir algoritma seçimini, yanlış bir mimari kararı hangi dilde kodlarsanız kodlayın yavaştır.
3. Tüm popüler diller (Java, C#, Objective C gibi) altta LLVM kullanır: http://llvm.org
Debug jvm edinebilirseniz, LLVM IR’leri konsoldan okuyabilir ve neler olup bittiğini izleyebilirsiniz.
4. C++ tarafında derleyici olarak clang ve intel compiler’ın performansına bakabilirsiniz. Muhtemelen hem VS hem de gcc’den daha iyi sonuç verecektir. C++’da hızlandırma için daha çok eğer algoritma elverişli ise paralelleştirme çözümlerine bakmak gerekir: OpenMP, Cilk, CUDA, OpenCL.

Binnur’un daha önce yayınlamış olduğum Java’nın Performansı: Java Yavaş mı? başlıklı yazıya yaptığı yorumlar:

İlk yorumu:

Selam Akın,
Performans ile ilgili olarak C++ ve Java karşılaştırmanda, tam tersini düşünüyorum. Deneyimsiz C++ ve Java geliştiricisinin yazdığı iki uygulama için, Java uygulamasının daha yüksek başarımla çalışması beklenmelidir. C++11 soyutlama konusunda çok yol aldı. Üstelik seçimlik bir çöp toplayıcımız var. C++’ın dil olarak en üstün tarafı Template ve STL ile sağlanan üretken programlama. Her ikisinin de ortak problemi Heap. Birinde bellekten yer almak yavaş (c++), diğerinde temizlemesi. Java’nın en güçlü yönü, Java dilinin kendisi değil, uygulamaların üzerinde çalıştığı JVM. C++ derleyicisi en fazla durağan en iyileme yapıyor (-O3), Jvm ise devingen en iyileme yapıyor. Dolayısı ile yapabildikleri çok daha fazla.

İkinci yorumu:

Burada ironik bir durum var: JVM, C/C++’da yazılmıştır. Java başarımını bir ölçüde C’ye ve deneyimli C geliştiricilerine borçlu

Şimdi de Yaşar’ın yazdıklarına geçelim. Yaşar’ın bu seriden  Java Yavaş mı? : Java’nın Performansı Üzerine – II başlıklı yazıya yaptığı yorum.

Yazdığınız çok doğru. Ufak iki şey yumurtlayasım geldi ama:

1. “Yorumlanan” deyince, doğru, ama yorumlama bir ara seviyede oluyor. Yani, “bytecode” dediğimiz, aslında var olmayan bir makinanın (bir ara yaptılardı sanki ama) komutları (instruction) çalıştırılıyor. Yani, direkt olarak kaynak kod yorumlanmıyor. Çok bir şey farkedeceğinden değil; ancak tamamen yorumlanarak çalışan dillerde, bir derleme adımı olmuyor. Javada ise, işimize de gelen bir derleme adımı var ki, bizi belli açılardan vaktiyle hizaya sokuyor.
Yorum yazıya doğru gidiyor ama, şunu da belirtmek lazım: Dilin yorumlanması veya derlenmesi, bir gerçeklenme problemi. Mesela, Javascript’in tanımında “yorumlanan” lafı geçiyor. Ancak mesela V8 önce derlemeyi tercih ediyor.
2. “Java yavaş mı” sorusunun cevabı, biraz “hadeleyn” civarında. Gerçekten de bu sözlerin doğruluk payı taşıdığı zamanlar, geçen yüzyıldaydı.
Saf Java koduna karşı, saf C kodu durumunda, verdiğiniz örnekler durumu gösteriyor.
İlginçlik, enteresan donanımlarda çıkıyor ortaya. Mesela, GPU kullanımı meselesi var. Paralel veri parçaları üzerinde hesaplama ağırlıklı işler için, GPU, CPU’yu dövüyor. (Bitcoin mining ile uğraşan var mı?) Öyle bir mesele için, JVM içinde bir şey yapmak mümkün olmayabiliyor. Elbette bu tip şeyler için de Java projeleri var. Ancak nihayetinde birinin o “native code”u yazması gerekiyor bir noktada.
Java’nın bugün ulaştığı bu yüksek verimlilik de, yıllar içinde hem derleme optimizasyonları (JIT derlemeden bahsediyorum) hem de muhtelif platformlardaki JVM’lerin daha kaliteli ve altta yatan donanımı daha iyi kullanmasının eseri.
Bunu, zamanında C kodu içine assembler yazılması durumuna benzetiyorum. Linux’un ilk kernel kodlarında, bunlar bol miktarda vardı. Esas sebep, derleme için kullanılan (o zaman tek opsiyon) GCC’nin, o kadar da iyi optimizasyon yapamamasıydı. Modern GCC versiyonlarında, optimizasyonlar o kadar kudretli hale geldi ki, elle GCC’nin ürettiği koddan daha hızlı kod üretmek neredeyse imkansız hale geldi. Kernel kodundaki pek çok assembler kısmı da bu sebepten sökülüp atıldı.
Şimdi aynı vaziyet, Java için gerçekleşiyor. Yani, çok da şaşılacak bir durum yok aslında.

Binnur Kurt veYaşar Safkan’ın yazdıklarına bloglarından ve twitter hesaplarından ulaşabilirsiniz:

Okumak güzeldir. Bileni okumak daha güzeldir.

Bol okumalar 🙂

Toplam görüntülenme sayısı: 898

“Java ile Nesne Merkezli Programlama” Dersi Sunumları Güncellendi

Java

Sevgili Java severler 🙂

Java Dersleri sayfasından ulaşılan “Java ile Nesne Merkezli Programlama” sunumlarının ilk 8 bölümü güncellendi. Eskiden Scribd.com’da olmalarından dolayı erişim problemi oluyordu, dosyaların yerlerini değiştirdim, artık böyle bir problem olmayacak.

Sunumlarım ne kadar faydalı olursa benim için o kadar keyifli bir durum olur. Bu yüzden sunumlarda bulduğunuz, yanlış, eksik, anlatım bozukluğu vb. sıkıntıları bana bildirirseniz sevinirim, isminizi de ilgili sayfalarda listelerim 🙂 Nihayetinde hatasız iş, insanların yapabileceği bir şey değil.

İyi okumalar.

 

Toplam görüntülenme sayısı: 1466

Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti – XI: Sıra dışı durumları ifade etmek için Exception nesneleri oluşturmamak.

Java, Yazılım Mühendisliği , ,

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve ilk dokuz maddeyi daha önce ele almıştık. Şimdi de onuncu ve son maddeyi inceleyelim:

Sıra dışı durumları ifade etmek için Exception nesneleri oluşturmamak. (No Exception objects to represent exceptional situations.)

Nesne-merkezli programların en temel özelliği, her şeyi nesne olarak ifade etmektir. Eğer derdimiz her şeyi nesnelerle ifade etmek ise, sıra dışı durumları da nesneler ile  göstermeliyiz. Zaten sıra dışı durumlar iş mantığının bir parçasıdır, dolayısıyla iş modelimizi sıra dışı durumlara özgü nesnelerle zenginleştirmeliyiz. Sıra dışı durumları görmezden gelmek ya da int ya da String vb. tiplerle, return değeri olarak ifade etmek nesneden uzaklaşmaktır, hem anlam problemine yol açar hem de daha karmaşık koda sebebiyet verir. Nesne yerine int ya da String vb. tipler kullandığınızda bu değerlerin bir envanterini yapmanız ve herkesin bu envanteri sıklıkla kullanması gereklidir. Bu da enerji kaybıdır ve hataya da yakındır. Öte taraftan böyle bir durumda bu değerleri metotlarınızdan döndürmek ve kodunuzun içinde dolaştırmak yine sizin sorumluluğunuzda olacaktır.

Dil olarak Java kullandığımızda, sıra dışı durumları da java.lang.Exception sınıfının nesneleri olarak kurgulamalıyız. Yeterliyse kullandığımız APIlerdekiException sınıfının ya da alt sınıflarının nesneleriyle, değilse kendi yaratacağımız Exception nesneleriyle, iş mantığındaki sıra dışı durumları yakalayıp, sistemin çalışmasının devam etmesini sağlamalı ve kullanıcıya bilgi verme, loglama vb. ihtiyaçları gidermeliyiz.

Fırlattığınız sıra dışı durum nesneleri, metotların arayüzlerinin yani anlamlarının bir parçasıdır, dolayısıyla, sıra dışı durumları kodlamadan önce yani tasarım sırasında ortaya koymalıyız. Açıkçası analistler tarafından iş ve ihtiyaç analizi sırasında, süreçlerdeki normal akışlardan sapmalar olarak yakalanmayan alternatif ve sıra dışı durumların, tasarım sırasında gündeme gelmesi mümkünse de aslolan bu durumların analizde belirlenip, süreçlerin bir parçası olarak ifade edilmesidir. Aksi taktirde eksik ve kullanışsız yazılımlar üretmek kaçınılmazdır. Bu konuda daha önce yazdığım ve kendi tecrübeme dayanan duruma bakabilirsiniz.  

Modern dillerdeki sıra dışı durum mekanizmaları, bu durumların nesne olarak ifade edilmesi yanında, çalışma zamanında böyle bir durum oluştuğunda fırlatılan sıra dışı durum nesnesinin çalışma ortamında uygun bir kod parçası (handler) tarafından yakalanmasını da sağlarlar. Diller bu amaçla kendi içlerinde bir yükseltme (escalation) mekanizmasına sahiptirler. Bu noktada önemli olan yazılım projesinde bu durumların taa analizden itibaren ıskalanmamasıdır.

Bu amaçla aşağıdaki gibi kod yerine

public interface UserDao{

	public User getUser(String tckn) throw Exception;

	public User saveUser(User user) throw Exception;
	
}

böyle bir kodu tercih etmeliyiz:

public interface UserDao{

 public User getUser(String tckn) throw NoSuchUserException;
 public User saveUser(User user) throw DuplicatedUserException;
	
}

Sıra dışı durumları, analistiniz ıskalarsa siz tasarım sırasında, orada da ıskalanırsa, kodlarken bulun ve sorun olarak ortaya koyun.

Toplam görüntülenme sayısı: 996

UML’i Nasıl Öğrenebiliriz?

Yazılım Modelleme, Yazılım Mühendisliği

Bugünlerde UML’den bahsediyorken nasıl öğrenileceğinden bahsetmezsem ayıp olur diye düşündüm ve bu yazıya başladım.

En iyi UML kitaplarından birisi, Martin Fowler’ın UML Distilled‘dir. 2003 yılında 3. sürümünü yapmış bu kitap dilimize de “Rafine UML” olarak çevrildi ve ben de zamanında satın aldım çeviriyi. Malesef pek çok çeviri kitap gibi ne İngilizce ne de yazılım modellemesi konusunda yetkin birisi tarafından çevrilmiş. Bu konuda bu yazıya da bakabilirsiniz. Dolayısıyla bu kitaptan yararlanmak isteyenler için öncelikle Ingilizce aslını tavsiye ederim.

UML Distilled, 200’den az sayfada UML 1.x’in her diyagramını, o diyagramları oluşturmak için gerekli çalışmalarla birlikte son derece anlaşılır bir şekilde sunmakta. Kitap, UML’in 2.x sürümlerini kapsamasa da hala bence UML ögrenmek için, bildiklerim arasında, bir numaraları kaynaktır. Bu kitap yazılım geliştirme sırasında modelleme amacıyla UML’in nasıl uygulanacağını çok güzel ve kısa bir şekilde anlatır.

Giriş seviyesinde UML 2.0’i ele alan “Learning UML 2.0” ise O’Reilly’nin hem anlaşılır hem de pratik kitaplarından bir diğeri.

UML konusundaki bir başka güzel kitap da Meilir Page-Jones‘ın “Fundamentals of Object-Oriented Design in UML“dir. 2000 yılında piyasaya çıkmış olan bu kitap nesne-merkezli tasarımı nefis bir şekilde anlatırken UML’i de okuyucusuna öğretmektedir. Zaten Page-Jones eskiden bu yana çok teknik ve derin tasarım kitapları yazmaktadır. Bu kitap da nesne-merkezli paradigmanın en temel kavramalrından olan encapsulation, cohesion ve coupling kavramlarını akademik ve pratik olarak açıklamaktadır.

UML kullanarak yazılım geliştirme konusunda bir başka güzel yazar ise ABD’den benim de hocam olan Hasan Gomaa‘dır. Kendisinin “Designing Concurrent, Distributed, and Real-Time Applications with UML” isimli kitabını ben yıllarca elimden düşürmedim. Zaten kitabı da GMU’da verdiği “Software Modeling and Architectural Design” isimli ders sayesinde almıştım. Hasan hoca bu kitabın yeni sürümünü “Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures” ismiyle 2011 yılında çıkardı. Bu kitabını okuttuğu dersinin ikinci kaynağı da yukarıda bahsettiğim UML Distilled’dir. Hasan hoca bir akademisyen olmasına rağmen kitapları son derece pratik ve uygulanabilir bir şekilde yazılmıştır.

Scott Ambler’ın “Elements of UML 2.0 Style” kitabı da küçük ama hoş bir kitaptır. Daha etkin UML kullanımmak amacıyla okuyabilirsiniz.

Türkçe olarak UML üzerine yazılmış tek bir kitap biliyorum: UML ile Nesne Tabanlı Çözümleme ve Tasarım. Yazarı Bora Güngören olan bu kitap, dilimizdeki nadir güzel yazılım kitaplarından birisi. Kitap adından da anlaşılacağı gibi aslen UML üzerine değil; nesne tabanlı çözüleme (analiz) ve tasarımı ele alırken tabi olarak UML’i kullanıyor. Kitap da zaten temelde kullanım şekli (use case) tabanlı analiz, yazılım mimarisi tasarımı ve fonksiyonel tasarıma odaklanmış durumda. Kitap 2009 yılında basılmış ama yazarının yeni baskısı üzerine çalıştığını biliyorum.

Bahsettiğim kitapların içeriğinden de anlayacağınız gibi, UML’i tek başına notasyon olarak öğrenmeye çalışmak çok da anlamlı değildir. UML ancak yazılım geliştirme sürecinin farklı noktalarında anlam kazanır. Bu yüzden her ne kadar “The Unified Modeling Language Reference Manual” ya da “The Unified Modeling Language User Guide” vb. isimli kitaplar olsa da kitapların ciddi bir kısmı bir UML referans kitabından öte analiz ve tasarım kitaplarıdır.

Bu kitapların büyük çoğunluğunu internette online olarak da bulabilirsiniz.

Bol modelli ve UML’li projeler dilerim.

Toplam görüntülenme sayısı: 2823

1 2 3 4 5 >»