Yeni Kayıt
Konudaki Resimler
|
Hızlı 
Bildirim
İşte HP'nin ARM işlemcili yeni sunucusu
Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
CAMPER Erkek Pix Ayakkabı : Amazon.com.tr: Moda
https://www.amazon.com.tr/dp/B08BCQ7XJB
6 sa. önce paylaşıldı
Daha Fazla 
Bu Konudaki Kullanıcılar:
Daha Az 
2 Misafir - 2 Masaüstü
Giriş
Mesaj
-
-
Çok müthiş bir şey işte bu. -
"toplamda 288 adet EnergyCore işlemci çekirdeğini üzerinde barındırıyor. Konfigürasyon anlamında baktığımızda her kart üzerinde dört, her kutuda 18 işlemci ve 4U sunucu farında ise dört adet kutu yer alacak."
yukarıda ifadede hatalı yazılmış bi durum var.
her kutuda 18 işlemci denmiş, işlemci değil 18 kart olacak bu da her kutuda 72 işlemci eder. 4 kutuda 288 işlemci olur. -
Kuruyemişçiye mi geldik hacı 288 çekirdek fln ? :D -
Abarttıkça abartıyorlar, intelin amd nin öğrenmesinin yıllar sürdüğü, yaptıkları hatalardan ders almalarının yıllrca sürdüğü ortamda, ARM daha yeni aynı hataları yapıyor. Belki 20 yıl sürmez ama 5sene 10 sene sürsün, daha çok zmanı var.
Intel, HP'yi kullandığı AMD işlemcileri toplamda %5i geçmemesi konusunda tehdit ederken, varsayalım ki bu arm cluster süper performans veriyor, Intel HP'ye aaa ne güzel devam et mi diyecek?
Teknik olarak bi ton ıvır zıvırı var da, yazılım vs. açısından inanılmaz ötesi destek lazım. Başkalarının Linux/Jit/VM demesi ile işler yürümüyor. Benim hep dediğim gibi, esas amacın yer ve enerji tasarrufu olduğu, lightweight webserver tarzı işlerde anca işe yarayabilir. Ha ama bu aynı şartlarda aynı zmanda single core / thread performansının da önemli olduğunu gösterir. Burda da büyük bi fatcore, Xeon yada Opteron veya benzeri başka bişeyin yine üstünlüğünü koruma şansının daha çok olduğu anlamına gelir. Çıktı kapasitesinin daha az önemli olduğu, az sayıda threadin ihtiyaç duyulduğu durumlar da gerçek hayat uygulamalarında sıkça karşılaşılabiliyor. Bi istemciye çok daha kısa sürede cevap vermek, düşük performanslı ama çok çekirdekli sistemin rahatça altından kalkamayacağı birşey. Kaldı ki sistem ne tek başına multicore cluster, nede multi node cluster(multicore multiprocessor multinode gibi bişey serverın tamamı). Yani ne Sparc T serisi gibi Niagara benzeri yapıda mesela cpu içinde 4 modul 16 core var, ne de AMD BD gibi OoO + CMP + SMT gibi (AMD'de hepsi cpu içinde).
Ilave olarak bazıları varolan bi ton şeyle uyumlu olduğunu söylese de, yine de gökten inmiş bi platformdan farkı yok. Yukarıda dediğim gibi eğer light threaded durumlar söz konusu ise, benzeri programları x86 yaklaşımı kesinlikle her durumda daha hızlı çalıştırır, mesela hiçbi durumda Nehalem'in yada Opteronun yanına bile yaklaşamaz. Ha iş pararlel olarak çalıştırmaya gelirse, yani ki burda 2 yol ayrımı var: 1.Yapılacak iş çok ağır değildir, bu hafif işi paralel mimariye yayarak hızlandırmak istersiniz ki bu tamamen yazılımın desteğine muhtaçtır. TLP (thread level parallelizm) ile yapılacak işi node/processor/core arasında uygun şekilde dağıtmaya çalışmak demektir. Mesela sıkıştırma işlemiş yapıcaz, thread 1 diskten oku, thread 2 sıkıştır, thread 3 diske yaz gibi. İşin en uzun olan kısmı thread2/sıkıştırmanın olduğu kısım, buraya daha fazla kaynak ayırmaya çalışmak lazım ki bütün bunları yaparken doğal olarak bazı kısıtlamalar çıkıyor. Kesinlikle çok çok daha iyi yazılım desteği lazım çünkü işlenicek komutların sistemde çalıştırılabilecek en küçük parçalara kadar ayırıp bunu paralel işlemeye çalışmak yazılımın nasıl çalıştığını veri bağımlılıklarının loopların faln miktarına şekline bağlı. Sonuçta burda yapmaya çalıştığımız şey, işletim sistemi tarafından başlatılan 1 tek thread'in sistemde daha küçük parçalara ayırılıp işlenmesi olarak için Donanımın kullanılması demek Kİ dünyada böyle birşey yok. Zaten öyle birşey olsa, single-thread uygulamanın performansı doğal olarak (çalıştırılan kısımlar izin verdiği ölçüde) yükselirdi.
2. Yapılacak iş ağırdır, multithreaded yaklaşım vardır, daha çok paralelliğe destek verebilir, mesela Render gibi. Burda da yazılımdaki kodların ne kadar paralleştirilebieceği daha çok önem taşır. Çünkü bütün bu serverı tek bi amaçla çalışan sistem gibi görürsek, Her Unitedeki 18 kartı birer sanalCPU(18 CPU), her karttaki 4'er gerçekCPU'yu da birer core (Her sanalCPU'da 4er Core), Her gerçekCPU'daki Corelarda birer mini-thread-Core gibi bakmak lazım (ki konseptin temeli bu). Bütün bunların belirli bi tek işe, mesela Web server gibi farklı ve alakasız istemlerin bulunduğu değil de, render gibi belli bi amaca yönelik çalıştığını düşünürsek, bu sefer yine dedğim gibi kodun olabildiğince suyu çıkana kadar uğraşılıp en yüksek oranda paralel hale getirilmesi gerekir. Bu da inanılmaz bir effor demek ki, kimse buna yaklaşmaz.
Varolan AMD BD için kimse o kadar kılını kımıldatmıyor, daha özel bi şekilde varolan kodu değiştirmeye gitmiyor, yani BD nin komutları daha verimli çalıştırmasını sağlayacak şekilde yazılımda değişime gitmiyor, ARM için niye uğraşsınlar.
Yukarıda yazdığım yerler dışında hemen hiç pazar bulamayacaktır.
-
Watt/performans başarısı bu serverların geleceğini şekillendirir. -
quote:
Orijinalden alıntı: Rubisco
Abarttıkça abartıyorlar, intelin amd nin öğrenmesinin yıllar sürdüğü, yaptıkları hatalardan ders almalarının yıllrca sürdüğü ortamda, ARM daha yeni aynı hataları yapıyor. Belki 20 yıl sürmez ama 5sene 10 sene sürsün, daha çok zmanı var.Intel, HPyi kullandığı AMD işlemcileri toplamda %5i geçmemesi konusunda tehdit ederken, varsayalım ki bu arm cluster süper performans veriyor, Intel HPye aaa ne güzel devam et mi diyecek?Teknik olarak bi ton ıvır zıvırı var da, yazılım vs. açısından inanılmaz ötesi destek lazım. Başkalarının Linux/Jit/VM demesi ile işler yürümüyor. Benim hep dediğim gibi, esas amacın yer ve enerji tasarrufu olduğu, lightweight webserver tarzı işlerde anca işe yarayabilir. Ha ama bu aynı şartlarda aynı zmanda single core / thread performansının da önemli olduğunu gösterir. Burda da büyük bi fatcore, Xeon yada Opteron veya benzeri başka bişeyin yine üstünlüğünü koruma şansının daha çok olduğu anlamına gelir. Çıktı kapasitesinin daha az önemli olduğu, az sayıda threadin ihtiyaç duyulduğu durumlar da gerçek hayat uygulamalarında sıkça karşılaşılabiliyor. Bi istemciye çok daha kısa sürede cevap vermek, düşük performanslı ama çok çekirdekli sistemin rahatça altından kalkamayacağı birşey.
Risc ve CISC teknik olarak farkı , CISC ile assembly yazmak daha kolay ve geriye yönelik uyumluluk çok kuvvetli.
Geri kalan herşey halledilebilir.
Sayfa:
1
Ip işlemleri
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
