AMD Zen: 32 Çekirdekli EHP APU’su Yolda! (4. sayfa)

quote:

Orijinalden alıntı: Rubisco

Rakip diyeceğin Nvidia var sadece. Intel ağırdan alır / alıyor. Pentium temelli CPU olduklarından, üstüne AVX eklentili SIMD üniteleri olduğundan, HBM tarzı yapıya göre esas işlem yapan altyapıyı / mimariyi değiştirmek çok çok çok daha zor. Şimdilik sadece bellek arabirimini değiştirecekler. CPU kompleksi bellek kontrol yapısını aynı şimdiki iCore mimarisindeki(SB ve sonrası) gibi ring bus ile ulaşıyor. Bu da genelde verimli bi yapı. En azından CPU içinde, çekirdek dışı yapıyı tanımlayan uncore denilen, çekirdekler arası ve diğer çip içi sistem birimlerini birbirine bağlayan yapı için ring bus anlamlı. SB için çekirdek >> L3 cache arasında toplamda 400GB'dan büyük bi BW taşıyabiliyor ringbus. Phi için bu çok daha geniş ve büyük. Normal şartlarda bi noktaya kadar sorun yok. Ama için içine HBM gibi çok büyük BW sunan yapı girdiğinde, sürekli Çip <<--->> HBM arasında veri transferi gerekecek. Masaüstü için 50GB bile ulaşamadığımızı dikkate alalım. Ekran kartlarında , bellek erişiminin %100 net mimari detaylarını bilmiyorum, yani ram çiplerine nasıl dağıttıklarını bilmiyorum (GDDR5 noktadan noktaya bağlantı olduğundan, mesela 512 bit kart için 8x tane 64bit kontrolcü gerekiyor. yazma istemi için komut gönderildiğinde, bu her bi shader grubunun kendine tahsis edilmiş L2'sine mi yazıyor ve o kısma karşılık gelen bellek kontrolcülerine ve bellek çiplerine mi yazılıyor, yoksa bi yazma kuyruğuna eklenip bütün bellek çiplerine mi dağıtıyor gibi tam detaylarını bilmiyorum). Ama Phi gibi bi yapıda olsa bile, ring bus'ın BW'si ile karşılaştırılabilecek seviyede HBM'nin sağladığı BW var. Bu da çipin HBM ile iletişim sırasında sürekli %100 BW kullanımı olamayabileceği anlamına geliyor olabilir. Yada ring bus'ı devasa boyutlarda BW'ye sahip olacak şekilde tasarlıyor olabilirler. AMD'de olan ilk durum, Intel'in yapmak için uğraştığı da ikincisi olabilir.

AMD, esas altyapısında değişiklik yapmamış. HBM bi nevi şimdiki GDDR5'lerin yerini almış. Bunun için bellek kontrolcülerinde ne kadarlık farklılık gerekti (yada gerekti mi) vs. detayları belli değil. HBM'ler için tam net latency testi faln yapan da görmedim daha. Bi yerde BW testi yapıp, 390x ile aralarındaki farkın %20 az olduğunu gösteriyordu (gerçekte %33 civarı BW farkı olması lazım. Fury 512GB, 390x 384GB ). ROP hariç herşeyi artınca sanki yetersiz kalmış gibi kabul ediyoruz. HBM'nin, artacak olan ROP'ların getireceği ilave yükleri kaldıramayacağını veya mimarinin buna uymadığını düşünmüş olmalılar. Daha çok ROP rasgele eklenemiyor ve her bi shader Engine 1-16 arası CU, max 4 ROP grubu olacak şekilde organize ediliyor. O zaman Fury'de daha çok ROP olabilmesi için ya Shader ENgine yapısının değişmesi, 1 tane daha fazla Shader Engine içermesi gerekecekti. Fazladan 1 Shader Engine demek +16 ROP demek olacaktı ama +16 CU da demek olacaktı. Yani 4 değil 5 shader engine olacaktı. O zman ilave Geometri / raterizer altyapısı vs. de demek olcaktı. Toplamda 4096 değil 4160 shader, 80 ROP gibi olacaktı. AMD'nin tam CU --> L2 --> Bellek kontrolcü altyapısını bilmiyorum(yukarda bahsettiğim her shader engine'in L2'de kendi payı-kısmı, bunların da aktarıldığı kendi bellk kontrolcüsü olabilir, veya yazma istemleri bi sıraya kuyruğa eklenip bütün bellek çiplerine yazılıyor olabilir). Şu an 290 >> 390x'e kadar olan Hawaii temelindeki 8 bellek kontrolcü yapısını 4 HBM çipine eşleştirmişler. Daha çok Rop için 5. Shader Engine eklenseydi, belki bi uyuşmazlık çıkma ihtimali olabilir. Hani çipin büyümesi vs. dışında, bellek erişim altyapısı yüzünden 8 bellek kontrolcü -->> 4 HBM çipi şeklinde erişim kurulmuş olabilir. Eğer bu varsayım doğru ise, bellek erişimi üstüne yazdığım 2 olasılıktan 1.si doğru olmuş olacak (her Shader Engine'in kendine tahsis edilen L2 alanına veriyi yazması, bellek kontrolcülerin de burdaki veriyi kendi çiplerine yazması. Yani bütün yazma işlemlerinin bi tür global kuyruğa eklenmesi ve bütün çiplere aynı anda yazılması değil. Yani 1. Shader Engine 'den gelen okuma-yazma talepleri mesela 1. ve 2. bellek kontrolcüsüne iletiliyor gibi. Genelde GPU'nun tamamı kabaca aynı anda aynı işin biçok kopyasını çalıştırdığından, 1. Shader Engine ile 4.Shader Engine aynı kodu / okuma yazma talebini işler. Bu sayede de bütün bellek erişimi aynı esas işin okuma yazması gibi olur. Temelde GPU'lar hep bu mantıkla çalışır. 1.Shader Engine'de 1.CU ayrı telden, 2. ayrı telden, 2. Shader Engine'deki Cu'lar farklı işlerle faln uğraşmaz. Nvidia için de bu böyledir ).

Bunlardan ne sonuç çıkıyor, AMD Shader ENgine altyapısını değiştirmek istememiş, sadece teorik limiti olan 16 CU'ya kadar genişletip bırakmış (1-16CU arası olabiliyor Shader Engine). O zaman da ROP tarafından lmiitleniyorsa(Hawaii'deki 2816 shader + 64ROP'a karşın 4096 shader +64ROP), Shader Engine yapısını değiştirmediklerinden ilave ROP eklenememiş. Belki çipin büyümesi belki ilave tasarım gerekmesi v.s yüzünden 5. Shader Engine de eklenmemiş. Böylece ROP açısından limitleniyorsa kesin olrak arge'den kısıp bırakmış oluyorlar.

Eğer 5. Shader Engine eklenebilseydi, bu sefer de bellek kontrolcü ile bağlantı sorunu olacakdıysa, bellek erişim altyapısında daha fazla değişim olması gerekecekti, bi nevi asimetrik erişim gerekebilirdi, yada 970'dekine benzer sorun olabilirdi: 5 tane Shader Engine 'i 8 tane bellek kontrolcüyle eşleştirmek gerekecekti. Bunun için, yukarıda varsaydığımız 1 ShaderEngine --> 2 Bellek kontrolcü gibi bi yaklaşım varsa, uymayacaktı. Belki 5GB lık olabilseydi olurdu o zman. Belki o zman da 5. HBM çipinin konumu açısından sorun çıkacaktı. bunlar da arge isteyen sorunlar.

Alakasız, Nvidia da her bi GPC bir bellek kontrolcü ile ilişkili. Bu yüzden çipi büyütürken, 980 için mesela 4 GPC 4 bellek kontrolcü, sonrasında 5 GPC 5 bellek kontrolcü gibi gidebiliyorlar. Ama 970'deki soruna da yol açıyor bu.

AMD HBM'yi Hawaii'ye uydurup biraz genişletip rekabetçi bişey çıkartmak istemiş olmalı. Çok az yeniden dizayn var gibi (yani yüksek seviyeli bakınca, yoksa silikon tarafından bakıncan güç yönetimi vs. bi sürü şeyler de var). Yani buna ayağına sıkmış der miyiz bilemiyorum. Argeden kısıp idare etmeye çalışmışlar, hep yaptıkları gibi. Intel de daha büyük ring bus ile idare etmeye çalışacak onun gibi. Ama, mimari tasarımı bu büyük BW'den yararlanacak şekilde değiştirmeyen zararını görecek gibi. Çünkü Çip <<<--->> Bellek çipleri arasında veri transferleri esasında en çok enerji tüketiminin olduğu yerdi. 800 tane shaderın yapacağı hesap sırasında harcanan enerji ile, elde edilen sonucu Dram'a yazmak kabaca benzer seviyelerde enerji tüketir mesela. Bunu, HBM ile sürekli yüksek miktarda BW kullanımı şeklinde ele alırsak, esasında baya artacak bi güç tüketimi sorunu demek bu.

AMD'Nin bu konunun esası olan sunumda bahsettiği gibi HBM için olan transferler güç bütçetsinin büyük bi kısmını kapsıyor olacak. Bu yüzden hesaplama sisteminde vs. de değişikliklere gidilmesi gerekiyor.

Nvidia Maxwell'de HBM tarzı bi yapı kullanmayı hem düşünmüyordu, hemde tam yapamazdı diye biliyorum. Yani AMD'nin kim ne yapacak diye bakınmasını gerektirecek bi durum yok esasında. Pascal ile mimari dizayn olarak bu yüksek BW 'li belleklere uygun yapı hazırlıyorlar. Bu yüzden yeni HBM tarzı yapı kullanacak mimarisinde perf çıtasını çok çok yükseğe taşıyacaklar.

Xeon Phi'ler, accelerator olarak HPC pazarın %30 küsürlük kısmındalar. Yani AMD'yi çoktan geçmiş konumda. AMD'Nin Intel'in Phi için ne yaptığını direk taktığını zannetmiyorum.

AMD de sonraki nesilde HBM yapısına uygun mimari dizayn yapabilirse idare eder gibi geliyor. Yoksa Nvidia'nın yeni dizaynı ağır gelecek baya.

quote:

Orijinalden alıntı: Rubisco

Önümdeki chrome da açık 30 tab, biraz yüklendi diye kapadığım ff de 146 tab var üstünden geçmem gereken :/

Küçük firmaların farklı etkileri var. Birincisi, bunlar daha önceden bi teknolojiyi arkadan etrafından dolaşılması imkansız seviyede geliştirmiş ve sahiplenmiş lisanslamış olabiliyorlar(veya patent durumu allengirli veya karışık olabiliyor). Büyük firma da doğal olarak o yoldan geçerken tarama yapmalarına rağmen denk gelemeyebiliyorlar. İş bu şekildeyse, küçük firmanın büyük firmada gördüğü kendi tech.'i ilerde ortalığı karıştırabiliyor. Ha heryerde bu böyle belki ama , iş bi noktadan sonra matematiği ve programlama şeklini nasıl kullanabileceğimizi de mi lisanslayacaksınız noktasına doğru ilerlemeye başlıyor. Neyse daha çok karıştıracam, onun için matematik ve belli bi yöntemi nereye kadar lisanslayabilirsin nereye kadar patent başvurusundan olumlu cevap alabilirsin, hangi noktadan sonra büyük firma mesela bi FMA yapısında küçük firmanın geliştirdiği yaklaşımı kullandığında işler direk bi patent ihlalinden daha karışık hal alabiliyor.

Başka bi nokta, Büyük firmalar, belli noktadan sonra innovasyon-yatırım konusunda sıkıntıdalar. Bunlar isterse fazla büyük diyebileceğin seviyede olsunlar. Firma büyüdükçe kurum içi bürokrasinin dozajı da artar, bi tür devlet gibi olurlar. Bu da kararlarda kötüleşme yanılma vs. gibi sorunların artmasına yol açar. Ortamın durumuna göre de daha korumacı yollar seçebilirler. Bu yatırımları da etkiler. Yıllar boyunca olduğu gibi mesela. 3 kuruşa 5 köfte peşinde koşulur, ama 3 kuruştan da tasarruf yapmak için yol aranır. Ama kimse daha lezzetli tarif için , daha iyi pişirme yöntemi için 3.5 kuruş ile devam edelim noktasına gelmez. Küçük firmalarda ise, startup'ından tut belli bi yatırım bulmuş olanına veya bi süredir idare edebilenine kadar, kendi alanında yapmaya çalıştığı şeyler açısından daha çok doğru karar alma şansına sahip olabiliyorlar. Bu, küçük firmanın belli bi alanda yapacağı arge'nin daha verimli şekilde işlemesine de yol açabiliyor. Konuyla alakası, bu tarz küçük firmalar ellerindeki tech'i piyasaya da sunarken, direk kullanım alanı bulunamasa ve firmaya yeterli getirisi olamasa bile büyük firmalar lisanslama şirketi satın alma yoluna gidiyor.

E iyi, M&A lafını duymadığımız yer kalmadı da neye yarıyor? Büyük firma 10milyar yatırım yapmazken, gidip şirket alınımına 20 milyar bayılabiliyor. konuyla alakalı değil ama ilaç vs. firmaları (biyotech vs. ler) argeye 3 kuruş yatırıp, gibip başkasının molekülünü de satın alabiliyor (600 milyon gibi rkamlara), belli bi işi yapabileck yöntem geliştirmiş firmayı 10 milyona da alabiliyor. Yarıiletken vs. açısından bakınca, mesela 2007'de kurulan, büyük firmalardan (intel vs. gibi) 60-100 milyon civarlarında para toplamış olan firmalar üstünde çalıştıkları şeyde zar zor ilerleyip, aradan geçen bunca senede bi nevi duvara toslamış gibi de olabiliyorlar(mesela MEMS resonator vs. ile uğraşan firmalar gibi). Bu tarz firmaların ürettikleri tech her yerde kullanılabilen, sensörlerin vs. içine girebilen, 3 kuruşluk getrisi olurken, bunları kullanıp final ürün üretenler belki binlerce kat gelir elde ediyorlar. Başka başka firmalar, ürettikleri ufak bişeyi lisanslanabilir tuttuğu ve işe yarar olduğu zaman, büyük bi firma tarafından eğer yutulmamış ise, o tech ile başkalarına imkan verip büyüklerin işini riskli hale getirebiliyor.

Server alanına ARM ile girmeye çalışanlara bakalım mesela. Çekirdek temeli ARM'dan, çekirdek dışı birimler arası iletişim detayları-interconnect altyapısı ARM'dan, eklenebilecek hazır accelerator IP'leri dışında sağdan soldan bulunabilecek ve çipe implementente edilebilecek, görece maliyeti düşük bi sürü şey var. Hepsini birleştirdiğinde eşşek gibi çalışıp server işlemcisi yaptık diyenlerin karşısında bi tür serverımsı çipi ile çıkabiliyorlar/çıkmaya çalışacaklar. PR'ını kaslı çiplere rakip olarak geliyoruz deseler de işin içyüzü öyle değil. Konuyla alakalı olan kısmı, adamların bu tarz bi işlemciyi sağdan soldan tech toplayıp yapabiliyor olmaları.

Buna benzer bi sürü detay vs. var.

Direk GPU üstünde imkansız. anca acaip bi işletim sistemi ve gpu altyapımız vs. olr anca o zmanlar. Yani normal sıradan bi program gibi tak tak çalıştır, belli kısımları veya tamamı gpu'da çalışsın. Olmaz. Belki yıllar yıllar sonra.

HSA tarzı altyapının amacı belli bi yapıya göre kolay kodlama sağalamak kabul ama bi programın önce bu altyapıya göre hazırlanması lazım. Photoshop vs. gibi şeyler mesela, önce HSA göz önünde bulundurularak hazırlanması lazım. Sonrasında belli yapılar , bunun iyileştirme aşamalarında görev alacak, belki belli kısımlarını gpu'da çalıştırabilir bulacak. Yani HSA'ya göre yazacaksın kodu, bunun compile kısmında HSAiL için olan çıktısı, HSAiL'yi hedef donanıma göre ilave iyileştirme yapabilecek. E nasıl olcak bu? PCI-e de 3000cycle gecikme olabilirken kodun seri kısmı neyi bekleyecek, ne kadar spekülatif çalışabilecek? Yani donanım altyapısında belli farklılıklar olabilmeli. HSA'ya uyan APU'da bu olur mu? Bazı açılardan çok güzel olur. Ama dünya APU etrafında tam dönmüyor daha. Intel oraya gelince AMD'nin ocağına incir ağacı dikilmiş gibi olacak mı? O da olabilir. Sonuçta ben AMD mühendisinden cpu-gpu coherency'nin anlamsız-gereksiz olduğunu da duydum, önceden coherent altyapıya laf sokan Intel mühendisinden çark etmiş biçimde geleceğin coherent altyapıda olduğunu ve Intel'in bu yolda kesin ilerledğini söyleyen başka Intel mühendisine kadar çok gördüm. Intel altyapı olarak GPU içeren kendi CPU'larının GPGPU içinde kullanılabilmesi açısından iyi yol katetti ve perfleri iyi. Böyle bakınca görece yakın zamanda Intel'in de HSA tarzı bişeylerin peşinde olması bende varım vs. demesi mümkün mü? bilemem, biraz zorlama olur. Çığır açacaz, HSA'daki gibi bi yapımız olacak, düşük latency'li CPU-GPU iletişmimiz var, işi Intel bilmemneye göre yazar ve compile derseniz kendi başına cpu-gpu bölmesi çalıştırması vs. yapacak... Mümkün mü? olmayacka iş değil ama çok şeyi karıştıracak bişey. yakın zamanda beklenmemeli.

normal programı otomatik olarak şurası şurda burası burda diyemezsin. bunun için programın yaptığı işe göre tasarım aşamsında bişeylerin yapılması gerekir. Yani sonradan gel şurası şurda çalışsın diyemezsin. Belki sonrdan 3 kuruşluk iyileştirme adına bişey ypmaya çalışırsın. Ama sonradan mesela %20 ilave perf alabileceksin diyelim, kodu düzgün yazarsan belki 2x belki 5x hızlanma zaten elde edebilmen lazım. iyi yazdığın şeyin, cpu-gpu diye bölme sırasında oluşaacak latency sorunlarına rastlamadığından, daha iyi sonuç verebilmesi lazım. CL, OpenMP gibi yapılar buna izin veriyor ama herhngi bi programın, CPU hedef olsa bile CL' göre yazılmasını beklemek hiç olası değil. Ha sen oturup cpu'da çalışacak bi iş için bile CL ile yazarsın, sonrasında bu GPU'da da çalıştırılabilir olur, veya HSA gibi bi yapıda kısım kısım bölünebilir olur bi yere kadar. ama bunu çoğunluğa yayayamazsın. Ms vs. nin de bu tarz işlerin içine girmeis lazım. CL ile basit bi iş için bile bi sürü initialize etmen gereken ve kodu uzatan şeyler var. Bunlar için otomatik - template tarzı bişeyleri herkesin kullanacağı vs. vs. noktalara getirmen lazım. hbunlar yakın zamanlarda olması imkansız şeyler.

quote:

her ayrı oluşum için programı yeniden yazmak mı gerekecek ?

quote:

Orijinalden alıntı: Rubisco

IBM'in kılını kımıldatmaya dermanı yok. %70'den fazla finansal mühendislikle idare ediyor. Yıllardır hisse gerialımı vs. yapıyor ama bu, etraflıca bahsedemeyeceğim şekilde 2007'lerden beri bütün büyük firmaların sorunu. Büyük innovasyonları, büyük adımları belli büyüklüğün üstündeki firmalar rahat rahat yapamıyorlar. Çünkü riskleri fazla, götürüleri fazla, gelecek belirsiz, idare edenler şirket içi bürokrasiler karışık vs. vs. Nihayetinde tutup gelecek için fırsat yaratacak bilmem kaç milyar ilave yatırım yerine finansal mühendislikle idare etmeyi daha uygun görüyorlar. Geçmişte innovasyon merkezi gibi görülüp, piyasaya da yansıyan IBM bugün bütün umutlarını WAtson'a bağladı. Watson'dan bilmem kaç milyar bekliyorlar ama bu kaç sene boyunca yavş yavaş gelecek. Gelirleri çöktükçe çöküyor IBM'in. Zor tutundukları dallardan biri Power8'in bazı durumlarda iyi iş çıkartması ve yerine göre Intel'e göre daha çok tercih edilmesi (yaygın olamadan ama). Yine IBM'in bazı işler için tutup x86'lı serverlarını tavsiye etmesi vs. Watson 'ın getireceği milyarlar için bilmem kaç sene var. Bu yüzden Cloud-Watson-Power tarafındalar. Masaüstü vs. IBM için kesin öldü, bi dha geri gelemez. Olasılık isteyen varsa, önce Intel ile rekabet edebilecek kdar maliyet-satış fiyatı biçebileceği çip ile gelebilmesi laızm. Şimdiki şartlarda bu imkansız. Power8'i neye göre test ettiğine göre değişiyor ama, verim açısından Fx8350 bile rekabet edebiliyor diyeceğin yerleri bile var yani (kendi işinde kullanıp Intel'den 3x daha iyi diyeni de var, Cern'de belli işe göre test edip dediğim gibi kötü diyeni de var).

quote: her ayrı oluşum için programı yeniden yazmak mı gerekecek ?

Bu zaten yıllarca böyle. Sorunun temeli bu zaten. En bilineni ne Cuda. Cuda da bi program, Photoshop Premier vs. olsun örnek. Bunların adam gibi perf göstermesini istiyorsan Fermi için farklı kodlaman ve ayarlaman, Kepler için farklı, Maxwell için farklı ayarlaman lazım. Elinde bi yaklaşım var. Ya bu yaklaşımı farklı mimarilere göre iyileştireceksin, yada farklı mimariler için farklı tasarım yapacaksın. Tıpkı oyun gibi. render altyapısını belli bi çipe göre yaparsan, farklı çipe göre en iyi sonucu vermez. Zaten olmayan da bu. Dx ile genel kaidelere göre yazarsın. Sonra donanım driverı dx çıktısını alıp hedef platforma göre bazı iyileştirmelerden geçirir, sonra hedef donanıma göre çıktıyı o donanımda çalıştırır. Yani Fermi'de Kepler'de MAxwel'de çalışan şeyler hepten farklı. Ha peki oyunu Fermiye özel olarak, Dx üstünden yazdın. Kepler MAxwell'de de süper çalışacak mı? Çalışmayacak. Dx üstünden yazmış olsan bile bi yerden sonra su koyuverecek, çünkü temelleri farklı. Driver optimize ederek çıktı verirken , esas yapıyı yaklaşımı değiştiremez. E peki nolcak böyle her oyunu her driverda farklı donanıma göre mi optimize edecez ayrı ayrı yazacaz. Aynen öyle. Gerçeğin ta kendisi bu. Ee kim yapıyor bunu? Kimse. Eee nasıl peki düzgün çalışıyor? Adamlar oturuyor, popüler oyunlar için labda günlerce analiz yapılıyor. Bu analizlere göre programcının Dx'den istdiğini, veya programcının GPU firması ile paylaştığı kadarı üstünden belli iyileştirmeler yapılıyor. Bu iyileştirme dendiği zaman binaya dış cephe boya yapılacak, yukardan 3 kova boya dökecekler bina monalisa gibi olacak anlaşılıyor. Tek tek mozaikler halinde işlenecek o. dışardan eleman elinde ince fırça, tek tek ufak mozaik kadar alanı elindeki plana göre boyayacak. İŞte o küçük boyadığı alan, mesela 5x5cm'lik alan, programdaki belli bi kod yapısına karşılık geliyor. atıyorum bi fonksiyon olur, klas olur , özel bi yapı olur. Bu hashlenip kütüphaneye atılır. Oyunlarda shaderlar realtime compile edilip çalışmaz. Önce oyun-sahne yüklenirken compile edilir, sonra o gpu'da çalıştırılabilecek katman GPU'da realtime çalışır. compile sırasında driver shaderlarda veya oyunun yapısında belli kod yapılarını tanırsa (oyundaki kod yapılarını okuyup-hashleyip-kütüphanedekilerle karşılaştırıp), o yapı için olan iyileştirilmiş-değiştirilmiş devamyolunu ayarlıyor bunu çalıştıracan diyor donanıma. Dahası, programcının yazdığından tamamen farklı bişeyin gpu'da çalışmasını sağlayabiliyor. Daha önce de yazdım, Nvidia Driverı illegal CL-GL yapılarını kabul edip, otomatik düzeltip çalıştırabiliyor mesela(illegal = mesela bi overflow oluşacak, olduğu zaman bunun etksi ne ise bunu umursamayıp-etkisini sınırlayıp çalıştırıyor). GPGPU vs. için de aynı şeyler geçerli. Ama GPGPU programı oyun kadar çeşitli olmadığından ve oyunlardan daha yüksek paraya satıldığından, geliştricisi ile daha yakından ve o donanıma-API'ye göre çalışma imkanı daha çok olabiliyor. Sonuçta GPU'yu kullanabilen Photoshop alternatifi tonla program yok mesela.

Bi geri gelirsem, farklı donanıma göre aynı programın farklı iyileştirmeleri patch şeklinde veya yeni versiyonda gelebiliyor. İyileştirme ile, yeni donanıma göre yeniden bi yapı-algo vs. oluışturup daha yeni versiyon da gelebiliyor.

Ee işin içinden çıkılmaz bi yöne ilerlioz sanki? yıllardır böyle zaten. Cuda-Nvidia daha öndeydi, herkes Cudaya göre ve az değişen donanıma göre yazardı. Kepler geldiğinde yeni donanımda eski programı kullanmaya kalkanların canı sıkıldı. Donanmda GPGPU için problemli olan yanlar da vardı çünkü. Yani kabaca Fermi ile aynı sayıda iş yapabliyor gibi oluyor Kepler. Ee peki Keplere göre herşeyi yeniden yazsak ilerleme olmaz mıydı? Olurdu-oldu da ama 2x ile %20 arasındaki fark gibi. 580 vs. 780 arasında çok fark olmasını bekleyip dudak bükmek gibi.

Yani bu işin temelinde var bu çatallanma olayı. Tek ortamdan tek kod yaz, birden çok platformda takr takr çalışsın verimli olsn, olmuyor işte.

Eee HSA'da nası olacak. Birincisi cillop gibi olmayacak. ikincisi, tutup kafana göre yazmayacaksın zaten. HSA guideları programın mesela native C'ye göre perf farkı olmasını engelleyip, aynı zmanda taşınabilirliğini arttırma amacı güdecek. Eee C vs. zatne bu amacı gütmüyor mu? Başta belki öyleydi, belki şimdi hala öyledir. Ama bi kod yazayım, ARM'da süper Intel x86'da süper olsun asla diymezsin. Araya compilerlar ve bunların iyileştirmeleri vs. girer. Sonra göreceğin bazı şeyler sonrasında kodu şöyle böyle değiştireyim dersin, hedef platformdan daha yüksek perf alırsın. Ama bu seferde taşınabilirliği azalmaya gitmeye, başka platformda verimi gitmeye başlar.

Yani tam olarak işin içinden çıkışı yok.

CL için ve AMD'nin eski-yeni donanımları için de bu böyle. CL ile 6970'e VLIW'e göre başka, GCN 7970 için başka yaklaşım sergilemen gerekir. Eski VLIW mimarilerde iyi çalışmayan bi sürü yaklaşım var mesela. O zman bi noktadan sonra o mimarileri kullanmamak lazım(e zaten kimse GPGPU için 6970 kullanmaz bu devirde)? Geriye AMD'nin bi tek şimdiki mimarisi, kartları kalıyor. Hepsinin de temeli hemen hemen aynı. Nvidia, Fermi-Kepler-Maxwell hepsi birbirinden farklı. Hala Fermi tabanlı Tesla kullanan süperbilgisayarlar faln var. Yani? Yanisi çözüm değil. O sistemde çalışanlar, o sistemin iyisi neyse ona göre yazıyorlar. Adam ordan kalkıp MAxwell GPU içeren bi clustera geçince, önceki bildiklerini öğrendikleri ile Maxwell'in getirdiklerini ve yeni sistemin farklarına göre yeniden yapılandırmak ve iyileştirerek yazmak zorunda kalacak. AMD tarafı şimdilik GCN'lerin hepsi aynı olduğundan sorun yok. Gerçi AMD'yi kullanan da yok, o açıdan ayrıca sorun yok ://

AMD yeni mimari ile geldi diyelim. Şimdiki GCN'e göre olan cluster dolu ortalık, vatandaş buna uyum sağlamış. Yeni mimari geriye dönük-kapsayıcı bi yapıda olamazsa, olamadığı her adımda perf düşüşü olacak. Yukarda bahsettiğim Nvidia'lık durumlar başına gelecek.

Xeon Phi'lerde, normal x86'yı al gel çalıştır diyor, o da dalga geçiyor tabi. Bi dual xeon'a göre hazırlanmış yapıyı optimize edersen Phi'ye göre, o zman belki 2x 5x 10x gibi değerler alabiliyorsun. İyi değil mi? iyi, ama kuru kuruya dual xeon için olanı aldın buraya göre yeniden derledin compile ettin, elinde hazır 10x perf verecek cillop gibi çıktın olmuyor. Hiç müdahele etmeden , hata da almadan derleyebilirsen (parallel studio faln ile), aradaki fark 5x'in çok altında kalıyor.

Yani?

Yanisi yok, karman çorman bi durum bi açıdan bakınca.

quote:

Orijinalden alıntı: Rubisco

Numba'ya bakın. Yada Yeni Java'ya.

Numba HSA destekli compiled Python gibi bişey. Matlab-Arrayfire niyetine, ama doğal olarak birz daha esnek.

quote:

Orijinalden alıntı: Rubisco

ÖNce yaklaşım - algo.

Prime analizi yapmak için mesela bi döngü açıp tek tek bütün sayılara böldürüp bakmak mesela en ilkel yaklaşım. Bunu en hızlı CPU'da, istersern multi thread ve direk donanım dili üstünden yaz, istersen GPU'ya paralel olacak bi yol bulup kas. Başlangıçtaki yaklaşımın sorunlu olduğundan , yaklaşımı değiştirmek yerine farklı yollara başvurmak ve bunların içinde zaman kaybetmek yanlış yol. tutup sieve etseydin, mesela 100 milyon prime'ı 2 3sn de bulurken, öbür en ilkel yaklaşım ile dünya kadar zman gerekiyor.

Yani önemli olan en başta yaklaşım -> algo'yu uygun tutabilmek. Yeterince gelimiş bi yaklaşımı sonrasında çok çekirdek vs. den yararlanacak hale getirmeye çalışmk vs. vs.

Intel'in de başkalarının da çeşitli paralel kütüphaneleri faln var.

İş eğer GPU'da çalıştırmaya uyarlanabilrise öncelikle hazır matlab-arrayfire vs. gibi yaklaşımlara bakılabilir.

http://www.hsafoundation.com/hsa-for-math-science/

https://www.continuum.io/blog/developer/programming-amd-apus-numba

burda HSA+Numba vs. NumPy var. Numba halihazırda NumPy'den daha hızlı. HSA ile yeterince bi ilave hızlanma oluyor yani. CudaPy'a göre de sanki daha kolay derli toplu gbi. Birilerinin işine yarıyabilir yani. APU olmadan harici kart vs. ile ne kadar oluyor hiç firkim yok. Vakit bulup kurcalmaak lazım.

Daha pro forumlarda faln işine göre yardımcı olack çıkar yani. stackoverflow'a faln yazarsan mutlaka cevap alırsın sanırm.