From: serdarkoylu@fisek.com.tr
Date: Mon 29 Aug 2005 - 17:16:15 EEST
Selamlar..
Bu biraz mimarisel öngörü. PIC veya 805x gibi bir işlemcimiz olsa, bir
defada bir veya iki biti test edebilse, bu hız kaybını önlerdi. Ama,
elimizdeki CPU'lar böyle değil. x86, en düşük "byte" ile çalışır.
Veri yolları ise 32 Bite optimizedir. Alignment vs. derken, byte'larla
çalışmada belirgin bir performans kaybı sözkonusu olur.
char a, b;
int c, d;
olsun. x86 özelinde, ( c == d ) işlemi, ( a == b ) işleminden daha
hızlıdır. Dahası birde işin içine bitler girerse, derleyici önce o
bit deseninden bir int veya char elde etmek üzere "<<", ">>", "&"
işlemlerine başvuracak daha bir iyice hız kaybı olacak.
Eğer öncelik hızdaysa, her birini int olarak tutmak en hızlı sonucu
verir. Hız/bellek optimum çözüm, her birini bir bayt tutmak olabilir.
Ama bir bayt'a 4 değer koyarsanız, yerden çok kazanmanıza rağmen,
performanstan çok ciddi kayıp yaşarsınız.
Elbette, bu iş bu kadar iki cümlelik bir şey değil. 1 Byte veri tipi
kullanımında alignment vs. yönünden zararlı çıkarken, paralelizasyon
artacağı için aynı anda U+V pipeları daha iyi çalışacak, performans
kazancı olacak. Ama işlenecek data MB'lar boyunda olunca, cache fill, vs.
süresi şu bu.. O yüzden tek söyleyebileceğimiz, bit bazında olunca
bir hayli daha yavaş olacağı...
Saygı ve sevgiler..
On August 29, 2:39 pm Ergin ALTINTAS <ealtintas@gmail.com> wrote:
> Bence hem hız hem de yer kazancı sağlanabilir. Fakat kullanım
> kolaylığı azalacaktır. Elinizdeki 1000 adet 2 şer bitlik DNA kodunu
> bir bayt içerisine 4 tane DNA kodu girecek şekilde düzenleyin.
> Üzerinde tarama yapılacak olan kodu da aynı şekilde düzenleyin. En
> büyük sorun elinizdeki kodları 4 ün katları olarak düzenlemeniz
> gekemesi. 1000 DNA için 250 byte yeterli oluyor. Fakat eğer 1001 adet
> DNA nız var ise sondaki DNA yı ayrı bir byte içinde tutmalısınız.
> Daha
> sonra standart srtcmp() fonksiyonu veya benzeri bir fonks. ile
> karşılaştırmanızı yapabilirsiniz. Bu adım toplam karşılaştırma
> iÅŸinin
> 4 te birine denk gelecektir. Bir sonraki karşılaştırma adımında,
> elinizdeki anahtar (ARANAN) DNA kodlarını temsil eden tüm baytları 2
> bit sağa kaydırmanız gerekecek. Sonra tekrar strcmp() yapacaksınız.
> Sonra tekrar 2 bit kayıdıracak ve vb.. toplam 3 kaydırma
> yaptığınızda.
> Tüm karşılaştırmalarınız tamamlanmış olur. Karşılaştırmlarınızı bit
> bazında değil de bayt bazında yaptığınız için hem hızdan hem de
> yerden
> kazanırsınız. Ancak strcmp() komutu tek bit (veya iki bit) farklı
> olduğunda tüm byte ın farklı olduğunu varsayar. Dolayısıyla
> hassasiyetinizden kaybedersiniz. Yani bir DNA kodunun farklı olması
> aynı bayt içindeki diğer 3 DNA kodunun da farklı olması şeklinde
> yorumlanacaktır. Eğer bu hassasiyet sizin için yeterli ise DNA
> kodlarınızı bir bayta 4 tane sığacak şekilde düzenleyebilirsiniz.
> EÄŸer
> bu hassasiyet sizin için yeterli değilse. DNA kodularınızı bir bayta 4
> tane girecek şekilde düzenlemek size zaman kazandırmaz, tersine
> işlemler umutun da dediği gibi çevirmelerden dolayı daha yavaş
> olacaktır, fakat sadece yerden %75 kazanabilirsiniz.
>
> On 8/29/05, Bora Güngören <bora@boragungoren.com> wrote:
> >
> > Merhaba,
> >
> > Elimizde 8 milyar bit lik alan olsun. Ben bunu 1 milyar char yada
> > 4 milyar adet 2 bitlik bit alanı ile saklayabilirim. Ve "bellekte"
> > tamamen aynı şekilde organize olurlar. Yani aynı alanı kaplarlar
> > :-)
> > Belleğe yüklenmesi, işlenmesi, bit karşılaştırma için yazılmış
> > API'lerin (char*) yani char dizisi işleyeceğini düşünürsek, "işlem
> > hızı" tarafında char kullanımı daha hızlı bile olabilir. Bunu daha
> > detaylı açıklayan mesajlar yazılmıştı.
> >
> > "Veri madenciliği" amacı ile kurulacak olan algoritmalar (vaktiyle
> > yazmışlığım var) ağırlıklı olarak bellekte çalışacaktır ve
> > sistemin
> > darboğazını oluşturacaktır. Bu nedenle veri tabanı yönetim sistemi
> > seçimi bile (duruma göre) önemsiz olabilir.
> >
> > Bora Güngören.
_______________________________________________
Linux-programlama mailing list
Linux-programlama@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama