SIMD'i Onlar Düşünsün - .Net Core ile Hardware Intrinsics

Bir programlama dili kullanarak yazdığımız kodları (genelde) işlemciler çalıştırıyor. Peki biz işlemcileri ne kadar tanıyoruz? Yeteneklerini ne kadar kullanıyoruz?

Konuların derinlerine inmeyi, bir şeyi kullanmaktan öte nasıl çalıştığını anlamaya çalışmayı çok severim. İtiraf edeyim, bazen mikro optimizasyon da yapıyorum, sınırları zorlamak için ve genellikle hobi projelerimde. Bildiğiniz kumdan yapılan işlemciler hakkında ne zaman bir yazı okusam aklıma programlama dillerinin neden bize bu yetenekleri sunmadığı düşüncesi geliyor. Yakın bir zamanda gördüğüm bu makaleden sonra ben de bu konuda biraz karalamak istedim.

Intel’in işlemci üretimi bayağı geçmişe dayanıyor. Ancak x86 mimarisini başlatan 8086 esas devrimin temelini attı. Özellikle VME ile modern işletim sistemlerinin doğmasını sağladı.

Peki biz kodlama yaparken bu işlemcilerin hangi özelliklerini kullanıyoruz? Şöyle bir düşünelim, herhangi bir programlama dilinin dokümantasyonunu hatırlayın. Değişken tanımlama, döngüler, structlar, (varsa) sınıflar, matematiksel işlemler vs.. Hep aynı konular, birisinde interface varken diğerinde trait oluşturuyoruz. Birisinde async varken diğerinde callback ile çalışıyoruz. Birinde pointer var diğerinde referanslar var. Bazıları belleği bizim için yönetiyor, diğerlerinde referans takip etmek üzere bize büyük iş düşüyor.

Ancak işlemciler bir çoğumuzun bilmediği ya da hiç kullanmadığı çok daha fazlasını yapabilen eklentilere sahipler, tam liste burada. Hem de bildiğim en eskisi olan MMX ile 1996 yılından beri. MMX bir SIMD (Single Instruction, Multiple Data) yani tek komut-çok işlem eklentisi.

Bu eklentiler genelde kendi register‘larına sahipler. Genelde işlemci register’ları işlemcinin çalışma bit genişliği ile aynı olur, 16 bit için 16 bit gibi. Ancak MMX 64 bitlik kendi register’larına sahip. Yani 4 adet 16 bitlik sayı tutabiliyor. İki tane 4 elemanlık dizideki elemanları karşılıklı toplayıp yeni bir dizi oluşturabiliyor.

const a1 = [1, 3, 5, 7]
const a2 = [2, 4, 6, 8]
const a3 = []
for (let i = 0; i < 4; i++) {
    a3.push(a1[i] + a2[i])
}

_{Yukarıdaki kodda bilerek imperatif bir yol izledim, map gibi bir fonksiyon kullansam tam anlatmak istediğimi vurgulayamayacaktım}

Toplama işlemimizi bir döngü içinde yaptık, büyük ihtimalle kodumuz her döngü adımında klasik register’lara (EAX gibi) verileri yükleyecek ve ADD komutu ile verileri toplayacak. Sonuçları da EBX ev ECX kullanarak hesapladığı hedef bellek adresine yazacak. Bildiğiniz bir sürü iş var burada.

_{http://mirror.as43289.net/kernel/people/geoff/cell/ps3-linux-docs/CellProgrammingTutorial/BasicsOfSIMDProgramming.html}

SIMD kullanarak bu işi tek bir komuta indirebiliyoruz.

Tabii ne gerek var diyebilirsiniz, bu konuda kimseyi ikna edebileceğimi sanmıyorum çünkü günlük geliştirmelerimizde büyük oranda bu seviyede optimizasyona ihtiyacımız olmuyor. Genelde oyun geliştiricileri (uzun yıllardır bu işleri de GPU devraldı), görüntü işleme, karışık matematiksel işlemler gibi işlerle uğraşanlar zaten biliyordur.

_{https://xkcd.com/303/}

Tam burada önemli bir noktaya değinmek lazım. Günümüzde derleyiciler çok akıllandı. Recursive fonksiyonlarda Tail Call Optimizasyonu‘nu otomatik yapanlar, veri komşuluğunu ve önbellek kullanım oranını arttırmak için kod sıralamamızı yeniden düzenleyenler bulunmakta. Genelde uygulanan optimizasyonlar için şu listeye bakabilirsiniz. Bu yazıda değindiğim SIMD çağrılarının sizin için otomatik yapılmadığını garanti edemem, belki onu da yapanlar vardır. Özellikle C#, Java gibi yönetilen (managed) dillerden şüpheleniyorum. Tam zamanında derleme (JIT Compilation) statik kod üretimine göre büyük avantajlara sahip, ellerindeki çalışma zamanı verileri bu optimizasyonu yapmalarını sağlayabilir.

Şunu da eklemek lazım, her işlemci bu eklentilerin her birini desteklemiyor. Dolayısı ile bu özellikleri biraz zorlayarak da olsa kullanabildiğimiz dillerde platform kontrolü yapmamız gerekiyor. Genellikle bu derece optimize edilen fonksiyonlar bir kontrol yapıp ortam uygun değilse SIMD kullanmak yerine klasik x86 komutlarını çağırıyorlar. Yani bir if kontrolü başarısız olursa yukarıdaki gibi bir döngü çalışıyor.

Belki de bu sorun çoklu platform destekleyen dillerin SIMD kullanımını standart kütüphanelere eklememe sebepleri olabilir.

Dotnet Core ve SIMD

Daha fazla uzatmadan konumuza gelelim. .Net Core 3.0 ile bu özellikleri nasıl kullanabilceğimizi görelim. Aslında .Net ve SIMD konusu pek yeni sayılmaz, 2014 yılında devrimsel RyuJIT derleyicisi ile bu yeteneği eklemişlerdi.

// Dizi yerine Vector

Vector<float> values = GetValues();
Vector<float> increment = GetIncrement();

// İki vektörü SIMD ile topluyoruz

Vector<float> result = values + increment;

.Net ile gelen SIMD yenilikleri mümkün olduğunda donanım özelliklerini kullanırken işlemci desteği olmayan ortamlarda çalışabilecek kodları da içeriyor (Software Fallback).

.Net Core 3.0 ile eklenenler ise yazılım desteği içermiyor, bir fallback olmadığı için çağıracağımız komutların işlemci tarafından desteklendiğini bizim kontrol etmemiz gerekiyor. Tabii çalışma ortamı tamamen bizim kontrolümüzdeyse ve zaten bu özellikleri içerdiğinden eminsek kontrol etmeden de kullanabiliriz.

İlk adımımız System.Runtime.Intrinsics altından ortamımıza uygun olanı eklemek, ben x86 üzerinde çalışan bir Mac kullanıyorum, yani System.Runtime.Intrinsics.X86 namespace ekliyorum.

Platforma özel namespace’ler altında işlemci eklentileri komut setleri (Instruction Set Architecture - ISA) şeklinde gruplanmış durumda. Her sınıf da IsSupported property’si ile desteklenme durumunu kontrol edebilmemizi sağlıyor. Bu sınıfların altında da X64 isimli subclass bulunduğunu görebilirsiniz. Yani sınıflar varsayılan olarak 32 bit işlemciler için yazılmışken 64 bit işlemciler için ayrı sınıf kullanmak gerekiyor. 64 bit işlemciler 32 bit işlemleri geri uyumluluk adına destekliyor ancak 64 bit ile çalışmanın performansa etkisi olacaktır.

_{https://www.statista.com/statistics/265033/proportion-of-operating-systems-used-on-the-online-gaming-platform-steam/}

_{Kullanıcıların donanım özelliklerini takip eden Steam platformunun verilerine bakarsak çok büyük oranda 64 bit sistemlerin kullanıldığını görebiliriz.}

Bu durumda 64 bit SSE2 için System.Runtime.Intrinsics.X86.Sse2.X64 sınıfını kullanmamız gerekiyor. Ortam desteğini de System.Runtime.Intrinsics.X86.Sse2.X64.IsSupported statik değişkeni ile kontrol edebiliriz.

Örnek Yapalım

En basit örnek bir dizi elemanlarını toplamak, gerçek dünya kullanımları hayal gücümüze bağlı.

static int Sum (ReadOnlySpan<int> source) {
    var result = 0;

    for (var i = 0; i < source.Length; i++) {
        result += source[i];
    }

    return result;
}

_{Benchmark projesi ile uğraşmak yerine hazır yapılmışları paylaşacağım.}

Modern işlemciler tek bir thread üzerinde bile olsa Instruction Pipelining sayesinde tek bir cycle içinde birden fazla işlem yapabiliyorlar.

Bu işi JIT derleyici de yapabilir, ama garantiye almak için kendimiz yapabiliriz. Loop Unrolling denilen bu yaklaşım ile işlemleri 4’erli gruplar ile yaparak Instruction Pipelining optimizasyonu yapmış oluyoruz.

static unsafe int SumUnrolled (ReadOnlySpan<int> source) {
    var result = 0;
    var i = 0;
    var lastBlockIndex = source.Length - (source.Length % 4);

    // Pin source so we can elide the bounds checks
    fixed (int * pSource = source) {
        while (i < lastBlockIndex) {
            result += pSource[i + 0];
            result += pSource[i + 1];
            result += pSource[i + 2];
            result += pSource[i + 3];

            i += 4;
        }

        while (i < source.Length) {
            result += pSource[i];
            i += 1;
        }
    }

    return result;
}

Küçük dizilerde biraz daha yavaş çalışan yeni kod 16 ve daha fazla kayıt olduğunda yavaş yavaş daha iyi sonuçlar üretiyor.

Vektörü Görelim

Yaklaşımı comment’ler ile açıklamaya çalıştım.

static int SumVectorT (ReadOnlySpan<int> source) {
    var result = 0;
    var vresult = Vector<int>.Zero;
    var i = 0;

    // vektör kaç adet int alabiliyor?
    // vektöre gruplu sığdırdığımız son eleman kim?
    var lastBlockIndex = source.Length - (source.Length % Vector<int>.Count);

    // gruplu halde vektörlere yerleştiriyoruz
    while (i < lastBlockIndex) {
        vresult += new Vector<int> (source.Slice (i));
        i += Vector<int>.Count;
    }

    // vektör gruplarını topluyoruz
    for (var j = 0; j < Vector<int>.Count; j++) {
        result += vresult[j];
    }

    // geri kalan elemanları da ekliyoruz
    while (i < source.Length) {
        result += source[i];
        i += 1;
    }

    return result;
}

Sonuçlar aşağıdaki gibi:

Yukarıdaki kodda 16 baytlık vektörler kullanılıyor. Bir de Vector128 ile görelim.

static unsafe int SumVectorizedSse2 (ReadOnlySpan<int> source) {
    int result;

    fixed (int * pSource = source) {
        var vresult = Vector128<int>.Zero;

        var i = 0;
        var lastBlockIndex = source.Length - (source.Length % 4);

        while (i < lastBlockIndex) {
            vresult = Sse2.Add (vresult, Sse2.LoadVector128 (pSource + i));
            i += 4;
        }

        // eğer SSE3 destekleniyorsa daha da hızlı versiyonu kullanalım
        if (Ssse3.IsSupported) {
            vresult = Ssse3.HorizontalAdd (vresult, vresult);
            vresult = Ssse3.HorizontalAdd (vresult, vresult);
        } else {
            vresult = Sse2.Add (vresult, Sse2.Shuffle (vresult, 0x4E));
            vresult = Sse2.Add (vresult, Sse2.Shuffle (vresult, 0xB1));
        }
        result = vresult.ToScalar ();

        while (i < source.Length) {
            result += pSource[i];
            i += 1;
        }
    }

    return result;
}

Bu sefer çok iyi sonuçlar aldık, SSE3 destekli sistemlerde neredeyse 6 kat daha hızlı!

Amacım biraz merakları gıdıklamak, aklımızın ucunda neler yapabileceğimize dair bir iz bırakmak. İnternette bu konuda çok daha detaylı bilgilere ulaşabilirsiniz, ben kesinlikle işlemci mimarisinde bir uzman olduğumu iddia etmiyorum, öğrenilecek çok şey var!

Tanner Gooding’e yazısı ve sonuçları kullanmama izin verdiği için teşekkürler.

Mutlu kodlamalar.