EPIC üzerinde Wikipedia makalesi zaten VLIW ve EPIC ortak birçok tehlikeler sundu.
Eğer bir kimse bu makaledeki kadercilik duygusunu bulamazsa, şunu vurgulayayım:
CPU önbellekleri ve DRAM içeren bir bellek hiyerarşisinden gelen yanıtları yükleme belirleyici bir gecikmeye sahip değildir.
Başka bir deyişle, (*) bellek erişimindeki deterministik gecikmeyle başa çıkmayan herhangi bir donanım tasarımı sadece muhteşem bir başarısızlık olacaktır.
(*) "Başa çıkma" ile, CPU'nun bu kadar sık sık yüzlerce devirde boşta kalmasına izin vermemesini gerektiren makul derecede iyi uygulama performansı elde etmek gerekir (diğer bir deyişle, "uygun maliyetli").
EPIC tarafından kullanılan başa çıkma stratejisinin (yukarıda bağlantı verilen Wikipedia makalesinde bahsedildiği gibi) sorunu çözmediğini unutmayın. Sadece veri bağımlılığını belirleme yükünün derleyiciye düştüğünü söylüyor. Bu iyi; derleyici zaten bu bilgiye sahiptir, bu nedenle derleyicinin uyması kolaydır. Sorun, CPU'nun bir bellek erişimi üzerinde onlarca - yüzlerce döngü boyunca boşta kalmasıdır. Başka bir deyişle, birincil sorumlulukla başa çıkamadığı halde, ikincil bir sorumluluğu dışlar.
Soru şu şekilde ifade edilebilir: "Başarısızlık olması gereken bir donanım platformu göz önüne alındığında, neden (1) (2) derleyici yazarlarının bunu kullanmak için kahramanca bir çaba gösteremedi?"
Umarım yeniden ifade etmem bu sorunun cevabını açıkça ortaya koyar.
Başarısızlığın da ölümcül olan ikinci bir yanı var.
Başa çıkma stratejileri (aynı makalede belirtildiği gibi), yazılım tabanlı ön taramanın, bellek erişimindeki belirleyici olmayan gecikme nedeniyle performans kaybının en azından bir kısmını geri kazanmak için kullanılabileceğini varsayar.
Gerçekte, ön hazırlık yalnızca akış işlemleri gerçekleştiriyorsanız kazançlıdır (ardışık veya yüksek oranda tahmin edilebilir şekilde okuma).
(Kodunuz yerelleştirilmiş bazı bellek alanlarına sık sık erişim sağlıyorsa, önbellekleme yardımcı olacaktır.)
Bununla birlikte, çoğu genel amaçlı yazılımın bol miktarda rasgele bellek erişimi yapması gerekir. Aşağıdaki adımları göz önüne alırsak:
- Adresi hesapla ve sonra
- Değeri okuyun ve sonra
- Bazı hesaplamalarda kullanın
Genel amaçlı yazılımların çoğunda, bu üçünün peş peşe yürütülmesi gerekir. Başka bir deyişle, adresi önceden belirlemek veya bu üç adım arasındaki durakları doldurmak için yapılacak işleri bulmak her zaman mümkün değildir (yazılım mantığının sınırları dahilinde).
Tezgahları doldurmaya yetecek kadar iş bulmanın neden her zaman mümkün olmadığını açıklamaya yardımcı olmak için, işte bunun nasıl görselleştirileceği.
- Diyelim ki, tezgahları etkin bir şekilde gizlemek için, belleğe bağlı olmayan 100 ek talimatı doldurmamız gerekiyor (bu nedenle ek gecikmeden zarar görmeyecek).
- Şimdi, bir programcı olarak, lütfen seçtiğiniz herhangi bir yazılımı bir sökücüye yükleyin. Analiz için rastgele bir işlev seçin.
- Herhangi bir yerde, yalnızca bellek erişimi olmayan 100 komut dizisini (*) tanımlayabilir misiniz?
(*) NOPİşe yarar bir iş çıkarırsak ...
Modern CPU'lar, dinamik bilgiler kullanarak aynı şeylerle başa çıkmaya çalışır - aynı anda her bir talimatın boru hatlarında dolaşırken ilerlemesini izleyerek. Yukarıda bahsettiğim gibi, bu dinamik bilginin bir kısmı deterministik olmayan hafıza gecikmesinden kaynaklanmaktadır, bu nedenle derleyiciler tarafından herhangi bir doğruluk derecesi ile tahmin edilemez. Genel olarak, derleme zamanında bu tezgahları doldurabilecek kararlar almak için yeterli bilgi yoktur.
AProgrammer tarafından verilen cevaba cevap olarak
Bu "derleyici ... paralellik ayıklamak zor" değil.
Hafızanın ve aritmetik komutların modern derleyiciler tarafından yeniden sıralanması, bağımsız ve dolayısıyla eşzamanlı olarak çalıştırılabilir olan işlemleri tanımlamanın bir sorunu olmadığını göstermektedir.
Ana problem, deterministik olmayan bellek gecikmesinin, VLIW / EPIC işlemcisi için kodlanmış ne olursa olsun "komut eşleştirme" nin, bellek erişimi tarafından durdurulduğunu ifade etmesidir.
Durmayan talimatları (sadece kayıt, aritmetik) optimize etmek, durması çok muhtemel talimatların neden olduğu performans sorunlarına yardımcı olmaz (hafızaya erişim).
80-20 optimizasyon kuralını uygulamada başarısızlığa bir örnektir: Zaten hızlı olan şeyleri optimize etmek, yavaş olan şeyler de optimize edilmediği sürece genel performansı anlamlı şekilde iyileştirmez.
Basile Starynkevitch tarafından cevap olarak
"... (her ne ise zor)" değildir, EPIC gecikme süresi yüksek dinamizmin üstesinden gelmek zorunda olan herhangi bir platform için uygun değildir.
Örneğin, bir işlemci aşağıdakilerin hepsine sahipse:
- Doğrudan hafızaya erişim yok;
- Herhangi bir hafıza erişiminin (okuma veya yazma) DMA transferi ile programlanması gerekir;
- Her komut aynı işlem gecikmesine sahiptir;
- Sırayla yürütme;
- Geniş / vectorized yürütme birimleri;
O zaman VLIW / EPIC uygun olacak.
Kişi bu işlemcileri nerede bulur? DSP. Ve bu VLIW'ın geliştiği yer.
Gördüğüm gibi, Itanium'un başarısızlığı (ve Ar-Ge çalışmalarının, kesin kanıtlara rağmen başarısızlığa harcanması) örgütsel bir başarısızlık örneğidir ve derinlemesine çalışılmayı hak eder.
Verildiği takdirde, satıcının hiper-diş, SIMD, vs. gibi diğer girişimleri oldukça başarılı görünmektedir. Itanium'a yapılan yatırımın, mühendislerinin becerileri üzerinde zenginleştirici bir etkiye sahip olması muhtemel olabilir ve bu da gelecek nesil başarılı teknolojiyi oluşturmalarına olanak sağlamış olabilir.