EC2 kullanırken çekirdekler ve çekirdekler

Sıklıkla "orta veri" projeleri olarak adlandırılabilecek projeler üzerinde çalışarak, kodumu (çoğunlukla Python'da modelleme ve tahmin için) 4 ila 32 çekirdek arasındaki herhangi bir yerde tek bir sistemde paralelleştirebildim. Şimdi EC2'deki kümelere (muhtemelen StarCluster / IPython ile, ancak diğer önerilere de açık) ölçeklenmeye bakıyorum ve bir örnek üzerinde bir küme üzerindeki örneklere karşı çekirdekler arasında dağıtımı nasıl uzlaştırılacağına şaştım.

Örnekler arasında ve her örnekte çekirdekler arasında paralel olmak bile pratik mi? Öyleyse, herkes her biri birkaç çekirdekli birçok örneği çalıştırmanın artıları ve eksilerini hızlı bir şekilde özetleyebilir mi? Örneklerin örnek başına çekirdeklere doğru oranını seçmek için genel bir kural var mı?

Bant genişliği ve RAM, projelerimde önemsiz konulardır, ancak bunların darboğazlar ve yeniden ayarlamalar olduğunu fark etmek kolaydır. Tahmin ediyorum ki, tekrarlanan testler olmadan doğru çekirdek karışımını örneklerle karşılaştırmak çok daha zor ve projelerim her testin tüm koşullara uygulanması için çok farklı. Şimdiden teşekkürler ve bunu düzgün bir şekilde google'da başarısız olduysam, başka bir yerde doğru cevaba yönlendirmekten çekinmeyin!

IPython kullanırken, neredeyse endişelenmenize gerek yok (verimlilik kaybı / daha fazla iletişim yükü pahasına). StarCluster'daki paralel IPython eklentisi varsayılan olarak her düğümdeki fiziksel çekirdek başına bir motor çalıştırır (bunun yapılandırılabilir olduğuna eminim, ancak nerede olduğundan emin değilim). DirectView api (map_sync, Apply_sync, ...) veya% px sihirli komutlarını kullanarak tüm motorlarda istediğinizi çalıştırın. IPython'u zaten bir makinede paralel olarak kullanıyorsanız, bunu bir kümede kullanmak farklı değildir.

Belirli sorularınızın bazılarını ele almak:

"bir örnek üzerinde bir kümedeki örneklere karşı çekirdekler arasında çalışma dağıtımı nasıl uzlaştırılır" - Çekirdek başına bir motor (en azından) elde edersiniz; çalışma otomatik olarak tüm çekirdeklere ve tüm örneklere dağıtılır.

"Örnekler arasında ve her örnekte çekirdekler arasında paralellik yapmak pratik mi?" - Evet :) Çalıştırdığınız kod utanç verici bir şekilde paralel ise (birden çok veri setinde aynı algo), belirli bir motorun çalıştığı yerde çoğunlukla yok sayabilirsiniz. Çekirdek, motorlar arasında çok fazla iletişim gerektiriyorsa, elbette, motorları öncelikle aynı fiziksel makinedeki diğer motorlarla iletişim kuracak şekilde yapılandırmanız gerekir; ancak bu tür bir sorun IPython için ideal değil.

"Eğer öyleyse, herkes her biri birkaç çekirdeği olan birçok örneği çalıştırmanın artılarını ve eksilerini hızlı bir şekilde verebilir mi? Birkaç çekirdeği olan birkaç örneği mi? Örneklerin örnek başına çekirdeklere doğru oranını seçmek için bir kural var mı? " - Hesaplamaya bağlı en büyük c3 örneklerini ve bellek bant genişliğine bağlı sorunlar için en küçük c3 örneklerini kullanın; iletiye bağlı sorunlar için, en büyük örnekleri de kullanın, ancak her bölüm bir fiziksel makinede çalışacak ve ileti iletilerinin çoğu aynı bölüm içinde olacak şekilde sorunu bölümlere ayırmaya çalışın. N dörtlü c3 örneklerinde 2N çift c3'e göre önemli ölçüde daha yavaş çalışacak sorunlar nadirdir (yapay bir örnek, çok sayıda görüntüde birden çok basit filtre çalıştırıyor olabilir; burada tüm filtreler için tüm filtreler yerine tüm filtrelerden geçersiniz aynı resim).

Genel bir kural, zorunlu olana kadar dağıtmamaktır. Genellikle belirli bir kapasiteye sahip N sunucuya sahip olmak, bu kapasitenin yarısı olan 2N sunucudan daha verimlidir. Daha fazla veri erişimi yerel olacaktır ve bu nedenle ağda yavaş ve bellekte hızlı olacaktır.

Belirli bir noktada, bir makinenin ölçeklendirilmesi ekonomik olmaz, çünkü ek kaynak maliyeti doğrusal olarak daha fazla ölçeklenir. Ancak bu nokta hala şaşırtıcı derecede yüksek.

Özellikle Amazon'da, spot piyasa örneklerini kullanıyorsanız, her örnek türünün ekonomisi çok değişebilir. Varsayılan fiyatlandırma az ya da çok, örnek türünden bağımsız olarak aynı miktarda kaynak maliyetinin çok farklı olabileceği anlamına gelir; büyük örnekler küçük olanlardan daha ucuz olabilir veya N küçük örnekler eşdeğer kaynaklara sahip bir büyük makineden çok daha ucuz olabilir.

Burada büyük bir husus, bir makineden birden fazla makineye geçtiğinizde hesaplama paradigmasının oldukça değişebileceğidir. İletişim yükünün neden olduğu ödünleşimler sizi örneğin ölçeklendirmek için veriye paralel bir paradigma benimsemeye zorlayabilir. Bu, farklı araç ve algoritma seçimi anlamına gelir. Örneğin, SGD bellekte ve Python'da MapReduce'dakinden oldukça farklı görünüyor. Bu yüzden paralelleştirmeden önce bunu dikkate almanız gerekir.

Güvenilirlik için, tek bir düğüm ve dağıtılmamış paradigmalar işe yarasa bile, çalışmayı bir küme boyunca dağıtmayı seçebilirsiniz. Tek bir düğüm başarısız olursa, tüm hesaplamayı kaybedersiniz; dağıtılmış bir hesaplama, kaybedilen hesaplamanın yalnızca bir bölümünü kurtarabilir ve tamamlayabilir.

Tüm veri setimi bellekte tutabilen ve ölçeklendirebilen en küçük örneği seçebileceğiniz her şey eşit kabul edildi (maliyet, CPU perf, vb.). Bu şekilde

• ağ iletişimi nedeniyle gereksiz gecikmelere neden olmadığınızdan emin olun ve
• işlemleriniz için kullanılabilir bellek bant genişliğini en üst düzeye çıkarma eğilimindesiniz.

Modelinizin bazı meta parametrelerini optimize etmek için bir tür çapraz doğrulama şeması çalıştırdığınızı varsayarsak , her çekirdeğe test etmek için bir değer atayın ve uygun gördüğünüz kadar az turda tüm parametre alanını kapsamak için gereken sayıda örneği seçin.

Verileriniz bir sistemin belleğine uymuyorsa, elbette örnekler arasında dağıtmanız gerekir. Daha sonra, bellek gecikmesini (birçok durumda daha iyi) ağ gecikmesi (daha az örnekle daha iyi) ile dengeleme meselesidir, ancak EC2'nin doğası göz önüne alındığında, genellikle birkaç yağ örneğiyle çalışmayı tercih edersiniz.