Sıkıştırma, veri tabanları, veri merkezi iletişimi, yüksek performanslı hesaplama, derin öğrenme ve daha fazlasında depolama maliyetlerini azaltmak ve giriş/çıkış transfer sürelerini hızlandırmak amacıyla yaygın olarak kullanılan bir tekniktir. Ancak, bu verilerin açılması bazen gecikmelere yol açarak değerli hesaplama kaynaklarını tüketebilir ve genel performansı yavaşlatabilir.
Bu zorlukları aşmak için NVIDIA, Blackwell mimarisinde Donanım Sıkıştırma Motoru (DE)nu tanıttı ve bunu nvCOMP kütüphanesi ile birleştirdi. Bu kombinasyon, sıkıştırmanın yazılımdan genel amaçlı hesaplamadan çıkarılmasını sağlarken, Snappy gibi yaygın formatları hızlandırmayı ve benimsemeyi kolaylaştırır.
Bu blog yazısında DE ve nvCOMP’un nasıl çalıştığı, kullanım kılavuzları ve veri yoğun yükler için sağladıkları performans avantajlarını inceleyeceğiz.
Donanım Sıkıştırma Motoru’nun Çalışma Prensibi
Blackwell mimarisindeki DE, Snappy, LZ4 ve Deflate tabanlı akışların sıkıştırma işlemlerini hızlandırmak üzere tasarlanmış sabit işlevli bir donanım bloğudur. Donanımda sıkıştırmayı hallederek, DE değerli akış çoklayıcı (SM) kaynaklarını hesaplama için serbest bırakır; bu sayede veri hareketinde döngü kaybı yaşanmaz.
DE, kopyalama motorunun bir parçası olarak entegre edilmiştir ve host’tan cihaza kopyalama ve ardından yazılımla sıkıştırmayı gerçekleştirmenin gereksinimini ortadan kaldırır. Bunun yerine, sıkıştırılmış veriler doğrudan PCIe veya C2C üzerinden aktarılıp yolculuk sırasında açılabilir; bu sayede Büyük I/O darboğazı azaltılmıştır.
Brut throughput’un ötesinde, DE, veri hareketi ile hesaplamanın gerçek eşzamanlılığını da sağlar. Çoklu akış iş yükleri sıkıştırma işlemlerini SM çekirdekleri ile paralel olarak yapabilir; bu sayede GPU’dan maksimum verim elde edilebilir. Pratikte, büyük veri uygulamaları olan LLM’lerin eğitilmesi, devasa genomik veri kümelerinin analizi veya HPC simülasyonlarının gerçekleştirilmesi gibi veri yoğun uygulamalar, Blackwell GPU’larının bant genişliği ile uyumlu çalışarak I/O’da tıkanma yaşamaz.
nvCOMP’in GPU-Hızlandırılmış Sıkıştırmasının Avantajları
NVIDIA nvCOMP kütüphanesi, GPU-hızlandırmalı sıkıştırma ve açma rutinleri sağlar. Geniş bir standart format yelpazesinin yanı sıra, NVIDIA’nın en iyi GPU performansı için optimize ettiği formatları destekler.
Standart formatlar durumunda CPU’lar ve sabit işlevli donanım, GPU’nun sınırlı paralellik sağlayan yapıları nedeniyle genellikle mimari avantajlara sahiptir. DE, bu sorun için çeşitli iş yükleri için bizim çözümümüzdür. Aşağıdaki bölümlerde nvCOMP’u kullanarak DE’den nasıl yararlanabileceğiniz aktarılacaktır.
DE ve nvCOMP Nasıl Kullanılır?
Geliştiricilerin DE’yi nvCOMP API’leri aracılığıyla kullanmaları önerilir. DE şu anda yalnızca B200, B300, GB200 ve GB300 gibi belirli GPU’larda mevcut olduğundan, nvCOMP kullanmak geliştiricilerin kodlarını taşınabilir hale getirerek DE’nin evrimine ayak uydurmasını sağlar. DE mevcut olduğunda, nvCOMP, kullanıcı kodunda değişiklik olmaksızın onu kullanacaktır. Mevcut değilse, nvCOMP hızlandırılmış SM tabanlı uygulamalarına geri dönecektir.
DE destekli GPU’lar üzerinde bu davranışı sağlamak için birkaç husus göz önünde bulundurulmalıdır. nvCOMP genelde, cihaza erişilebilen her çeşit girdi ve çıktı tamponlarını kullanmanıza olanak tanır. Ancak DE’nin daha katı gereksinimleri vardır. Bu gereksinimleri karşılamayan tamponlar varsa, nvCOMP açmayı SM üzerinde de gerçekleştirecektir. Şekil 1’de izin verilen tahsis türleri ve amaçları açıklanmaktadır.
| cudaMalloc | Standart cihaz sadece tahsisi | Cihaz |
| cudaMallocFromPoolAsync | Daha fazla kullanılabilirlik için havuz tabanlı tahsisler | Kendi/cihaz |
| cuMemCreate | Host/cihaz tahsisi için düşük seviyeli kontrol | Kendi/cihaz |
cudaMalloc tahsisleri, cihazlar arası açma işlemleri için normal şekilde tahsis edilebilir. Host’tan cihaza veya hatta host’tan host’a açma işlemleri cudaMallocFromPoolAsync veya cuMemCreate kullanımında mümkündür ancak tahsislerin doğru bir şekilde yapılandırılması gerekir.
Aşağıdaki bölümler, bu farklı tahsis yöntemlerini nasıl kullanacağınızı gösteren örnekler içerecektir. Her iki durumda da, bu API’lerin standart kullanımına ek olarak cudaMemPoolCreateUsageHwDecompress ve CU_MEM_CREATE_USAGE_HW_DECOMPRESS bayraklarının eklenmesi yalnızca fark edecektir. Her iki örnekte de tahsisler ilk CPU NUMA düğümüne yerleştirilecektir.
cudaMallocFromPoolAsync Kullanımı
Aşağıdaki kod örneği, DE ile uyumlu tahsisler yapmak amacıyla cudaMemPoolCreateUsageHwDecompress bayrağı ile bir sabit bellek havuzu nasıl yaratılacağını gösterir.
cudaMemPoolProps props = {};
props.location.type = cudaMemLocationTypeHostNuma;
props.location.id = 0;
props.allocType = cudaMemAllocationTypePinned;
props.usage = cudaMemPoolCreateUsageHwDecompress;
cudaMemPool_t mem_pool;
CUDA_CHECK(cudaMemPoolCreate(&mem_pool, &props));
char* mem_pool_ptr;
CUDA_CHECK(cudaMallocFromPoolAsync(&mem_pool_ptr, 1024, mem_pool, stream));
cuMemCreate Kullanımı
Bu örnek, cuMemCreate ile sabit bir bellek tahsis etmek için nasıl kullanılacağını gösterir, böylece tampon DE ile uyumlu hale getirilir.
CUdeviceptr mem_create_ptr;
CUmemGenericAllocationHandle allocHandle;
CUmemAllocationProp props = {};
props.location.type = CU_MEM_LOCATION_TYPE_HOST_NUMA;
props.location.id = 0;
props.type = CU_MEM_ALLOCATION_TYPE_PINNED;
props.allocFlags.usage = CU_MEM_CREATE_USAGE_HW_DECOMPRESS;
size_t granularity;
CU_CHECK(cuMemGetAllocationGranularity(&granularity, &props, CU_MEM_ALLOC_GRANULARITY_MINIMUM));
// Tahsis etme işlevini oluştur
CU_CHECK(cuMemCreate(&allocHandle, granularity, &props, 0));
// Sanal adres alanını ayır
CU_CHECK(cuMemAddressReserve(&mem_create_ptr, granularity, 0, 0, 0));
// Fiziksel belleği sanal adrese bağla
CU_CHECK(cuMemMap(mem_create_ptr, granularity, 0, allocHandle, 0));
Tampon Gruplama İçin En İyi Uygulamalar
En iyi performans için açma için kullanılan tampon grubuna (girdi/çıktı/boyutlar) işaret eden işaretçilerin aynı tahsislere kaydedilmiş olması önerilir. Farklı tahsislere ait bir grup tampon sağlamak, host sürücü başlatma gecikmesini artırabilir.
uint8_t* d_decompressed_buffer;
CUDA_CHECK(cudaMalloc(&d_decompressed_buffer, total_decompressed_size));
// Cihaz açma işaretçileri için sabit host dizileri oluştur
uint8_t** h_d_decompressed_ptrs;
CUDA_CHECK(cudaHostAlloc(&h_d_decompressed_ptrs, actual_num_buffers * sizeof(uint8_t*), cudaHostAllocDefault));
// Sabit ana işaretçi dizilerini açma için doldur
size_t decompressed_offset = 0;
for (int i = 0; i < actual_num_buffers; ++i) {
h_d_decompressed_ptrs[i] = d_decompressed_buffer + decompressed_offset;
decompressed_offset += input_sizes[i]
}
DE ile ilişkili senkronizasyon gereksinimleri nedeniyle, nvCOMP’in asenkron API’leri arayan akış ile senkronize olacaktır. Genel olarak, nvCOMP yine de API bitmeden önce dönecektir; bu nedenle, özellikle host’a açıyorsanız sonuçları kullanmadan önce çağıran akışı bir kez daha senkronize etmeniz gerekecektir. Cihaz tarafında erişim için, açma sonucu normal akış sıralamasında erişilebilir.
B200’de, herhangi bir tampon 4 MB’den büyükse, nvCOMP bir SM tabanlı uygulamaya geri dönecektir. Bu sınır gelecekte değişebilir ve aşağıdaki kod ile sorgulanabilir:
int max_supported_size = 0;
res = CudaDriver::cuDeviceGetAttribute(&max_supported_size,
CU_DEVICE_ATTRIBUTE_MEM_DECOMPRESS_MAXIMUM_LENGTH,
device_id);
SM Performansının DE ile Karşılaştırılması
DE, daha hızlı açma işlemi sağlarken, SM’yi başka işler için serbest bırakır. DE, işlem birimleri açısından, SM’lere kıyasla çok daha fazla sayıda icra birimine sahip olmasına rağmen, bazı iş yüklerinde tam olarak SM kaynaklarını doygun hale getirdiğinde SM’nin hızına yaklaşacaktır. Hem SM hem de DE, giriş olarak host sabit verileri kullanarak sıfır kopya açma işlemi yapabilir.
Aşağıdaki şekil, Silesia benchmark’ında LZ4, Deflate ve Snappy algoritmaları için SM ile DE performansını karşılaştıracaktır. Unutmayın ki Snappy, nvCOMP 5.0’daki yeni bir optimizasyon ile geliştirilmiştir ve Deflate ve LZ4 için daha fazla yazılım optimizasyon fırsatı bulunmaktadır.
Performans ölçümü 64 KiB ve 512 KiB parça boyutları için “küçük” ve “büyük” veri kümesi kullanılarak yapılmıştır. Büyük veri kümesi tam Silesia veri kümesidir; küçük veri kümesi ise Silesia.tar dosyasının ilk ~50 MB’ıdır (buradan ulaşılabilir).
Başlayın
Blackwell’deki Donanım Sıkıştırma Motoru, veri yoğun iş yüklerinde en büyük zorluklardan biri olan hızlı ve etkili açma ile başa çıkmayı oldukça kolaylaştırmaktadır. Bu işin özel donanıma kaydırılması, uygulamaların daha hızlı sonuçlar elde etmesini sağlarken GPU hesaplama kaynaklarını başka görevler için serbest bırakır.
Özellikle nvCOMP, entegrasyonu otomatik olarak yöneterek geliştiricilerin kodlarında değişiklik yapmadan bu iyileştirmelerden faydalanmasını sağlar. Bu durum, daha akıcı veri akışları ve daha iyi performansa yol açar.
Bu yeni özelliklerle başlamaya hazır mısınız? Aşağıdaki kaynakları inceleyin:
- nvCOMP ve Donanım Sıkıştırma Motoru hakkında daha fazla bilgi edinin ve bunları mevcut iş akışlarınıza nasıl kolayca entegre edeceğinizi öğrenin.
- nvCOMP API örnekleri ve benchmarklar hakkında daha fazla bilgi edinin.
- nvCOMP’un en son sürümünü indirin ve bu özellikleri kullanmaya başlayın.
