yardıma ihtiyacım var! Görev çözülmedi, demirin sınırlamalarıyla karşılaşıyorum

 

Çok miktarda bilgi var (bir metin dosyasında yaklaşık 20 GB).

Bilgi aynı türden dizilerden oluşur, bunlardan yaklaşık bir milyon vardır.

Tüm dizileri tekrar tekrar sıralamak ve bazı hesaplamalar yapmak gerekir.

Akla gelen ilk şey, dosyanın tüm içeriğini okumak, bir dizi yapıyla doldurmak ve onlarla bellekte çalışmaktır.

Ancak orada değildi, bir sonraki yeniden boyutlandırmada MT, "Bellek işleyici: 5610000 bayt bellek ayıramıyor" diye yemin ediyor.

Aynı zamanda, gönderici terminal.exe'nin 3,5 GB RAM kullandığını söylüyor (16 fizikselden). Bunun, işlemin yalnızca 4GB alabilmesinden kaynaklandığını anlıyorum.

başlamadan önce

%2 oku

%6 oku

%12 oku

%15 oku

Herşey...

EA, "Yeterli bellek yok ( 4007 Mb kullanıldı, 88 Mb kullanılabilir, toplam 4095 Mb)!!!" diyor.

Ve bu, gerekli hacmin sadece %15,3'ü (ve gelecekte bunu artırmak istiyorum).


Seçenek numarası 2 - dosyayı her okumak için. İstediğiniz parçayı bulun, bir yapıya kaydedin, sonraki parçayı okuyun, sonucu karşılaştırın, yapının üzerine yazın.

Ve eğer bu dizilerden bir kez geçmek gerekirse, bunu yapardım. Ancak, her seferinde biraz ileri giderek, onları tekrar tekrar gözden geçirmeniz gerekir.

Bu nedenle, birçok kez okumak zorunda kalacaksınız ve bu:

  • çok yavaş
  • vidada delik açmak
Sonuçlar için birkaç gün beklemeye hazır olduğumdan emin değilim...

Bilgi miktarı da üzücü... Bir RAM diske (aslında belleğe) aktarılan 10 Gig olurdu ve istediğim kadar okurdum. Evet?

Ve artık yeterince hayal gücüm yok.

Bu dizileri, çok, çok parça elde edilecek şekilde yeniden oluşturmaya çalışın, ancak her biri yalnızca şu anda gerekli olan bilgileri mi içeriyor?

Hala verileri sıkıştırmak için (I ve benzeri, mümkün olan her yerde char ile yüzer)? Ancak bu, maksimum %10-20 daha verecek ve hacmi bir büyüklük sırasına göre azaltmam gerekiyor ..

Ne düşündüğünüzü söyleyin arkadaşlar. Benden sonra paslanmayacak)

 

komposter :

Ne düşündüğünüzü söyleyin arkadaşlar. Benden sonra paslanmayacak)

Seçenekler olarak...

1. önbelleğinizi yapın. bu durumda, bellekte kalanları yöneteceksiniz. algoritmayı biliyorsunuz, böylece önbelleği verimli hale getirebilirsiniz.

2. dosya için eşlemeyi kullanın. Windows ihtiyacı olanı önbelleğe alır, vida takılmaz.

 
TheXpert :

Seçenekler olarak...

1. önbelleğinizi yapın. bu durumda, bellekte kalanları yöneteceksiniz. algoritmayı biliyorsunuz, böylece önbelleği verimli hale getirebilirsiniz.

2. dosya için eşlemeyi kullanın. Windows ihtiyacı olanı önbelleğe alır, vida takılmaz.

1. Bu önbellek... Ya da ne demek istediğini anlamıyorum. Gerekli parçaların sürekli okunmasıyla varyantım?

2. Biraz daha detay verebilir misiniz? Haritalama ne verecek ve ona hangi taraftan yaklaşmalı?

 
Haritalama hakkında girmeye başlıyorum. Şimdi hala mana çalışıyorum ve madenlere doğru ilerliyorum)
 

Kahrolası...

32-битные архитектуры (Intel 386, ARM 9) не могут создавать отображения длиной более 4 Гб

Aynı yumurtalar, sadece yan tarafta. Okuma hızlanabilir, ancak bu sorunu küresel olarak çözmez.

 

Başka bir düşünce, her şeyi bir DB'ye (MySQL?) taşımak ve onunla çalışmaktır. Teorik olarak, veritabanları bu tür hacimler ve sürekli kürekleme için uyarlanmıştır.

Uzmanlar var mı? Kim ne diyecek?

 

1) Algoritmayı bir şekilde değiştirmek mümkün müdür? İşlenecek bir blok (2GB) yüklemek için sonucu kaydedin (kısaca), boş hafıza, sonraki bloğu yükleyin ...

ve sonunda, tüm sonuçları tekrar işleyin.

2) Çok fazla bellek çalışması, karmalara, B ağaçlarına (ve bunların modifikasyonlarına) dayalı kararlarla ilişkilendirildiğinde, veritabanına yükleniyor.

 
ALXIMIKS :

1) Algoritmayı bir şekilde değiştirmek mümkün müdür? İşlenecek bir blok (2GB) yüklemek için sonucu kaydedin (kısaca), boş hafıza, sonraki bloğu yükleyin ...

ve sonunda, tüm sonuçları tekrar işleyin.

2) Çok fazla bellek çalışması, karmalara, B ağaçlarına (ve bunların modifikasyonlarına) dayalı kararlarla ilişkilendirildiğinde, veritabanına yükleniyor.

1. Bunun hakkında yazdım - yapabilirsiniz, ancak sorun şu ki, verileri birçok kez işlemeniz gerekiyor. Çok yavaş olacak.

2. Yarın kendim google'da arayacağım, kısa bir açıklama için minnettar olacağım.

 
komposter :

1. Bunun hakkında yazdım - yapabilirsiniz, ancak sorun şu ki, verileri birçok kez işlemeniz gerekiyor. Çok yavaş olacak.

2. Yarın kendim google'da arayacağım, kısa bir açıklama için minnettar olacağım.

Benzer bir sorunu tartıştıkları siteyi ve bunu C++ ile çözme seçeneklerini hatırladım.

Отсортировать строки в файле размером 3GB | FulcrumWeb
Отсортировать строки в файле размером 3GB | FulcrumWeb
  • www.fulcrumweb.com.ua
Необходимо написать алгоритм, который бы смог отсортировать строки в файле большого размера (от 2-х до 4-х Gigabytes). Результатом выполнения должен быть другой файл. За хорошую реализацию гарантированный приз – флешка для хранения таких файлов и, возможно, предложение работы в нашей компании.
 
Tabii ki üzgünüm, ama ya 64 bit denerseniz veya MT yalnızca 32'ye dönerse
Böyle yüksek derecede matematiksel bir şeyin 64 bitte dönmesi gerektiğini saf bir şekilde düşündüm.
uçağın aerodinamiğini hesaplamak için aynı programları alın, bu nedenle prensipte 32x'te çalışmazlar
Arabanın 32 kat daha hızlı hareket ettiği ana argümanını biliyorum, ancak bu gerçekten bir donanım sorunu IMHO
 

1. Doğal olarak x64 sistemi kullanın.

2. Amazon EC2 bulutunda daha güçlü bir makine kiralayın ve üzerinde hesaplamalar yapın.

3. Sıkıştırılmış verileri kullanın, anında bellekte sıkıştırın. Gerçek veriler, akışlara bölündüğünde daha iyi sıkıştırılır (işaret/mantis/üs); 12 bitlik kayan nokta kullanabilirsiniz (doğruluk pahasına).

4. EA dışında büyük verilerle çalışabilecek bir hesaplama yapın (Matlab/R/vb).

Neden: