Co to za plik, że z Basha po nim jeździsz? Jakiś tekst, czy binarka?
Plik tekstowy.
Jakie naprawdę operacje na nim chcesz robić (bo że wczytać całość do RAM to już wiemy)
Przepraszam ze nie podałem skryptu, ale nie chciałem podawać skryptu, bo mogę być źle odebrany.
A żeby opisać całość, muszę się trochę rozpisać.
Napisałem sobie skrypt do generowania słownika wyrazów / słów składających się z liczb 0 i 1.
Bedzie mi on potrzebny do wygenerowania sum kontrolnych.
Użyje przed skryptem polecenie
time.
Im szybciej algorytm / suma kontrolna poradzi sobie ze słownikiem, to znaczy ze jest szybszy.
Teoretycznie żeby ładnie ocenić prędkość algorytmu (~1GB/s)
wystarczy wygenerować słownik danych o wielkości np. 1GB.
Z małymi danymi to bez sensu bo algorytmy mogą być porównywalnie szybkie, czyli granica błędu pomiarowego, więc mógłbym źle to zmierzyć.
Udało mi się stworzyć słownik o wielkości 88MB,
potem musiałem wyłączyć komputer, bo przestał prawie reagować, bo skrypt zajął całą pamięć RAM.
Oczywiście mogę
- sobie stworzyć dodatkowe SWAP jako RAM
- podzielić słownik na osobne pliki
- mogę każdy ciąg zapisywać w osobnym pliku,
to idealne rozwiązanie dopóki sam ciąg nie przekroczy ~1GB.
I nie wiem co jeszcze mogę.
- aa mógłbym sobie stworzyć bazę danych, może ona nie będzie wczytywać aż tyle?
ale nie wiem w czym będzie najlepiej
No ale stwierdziłem ze zawsze będę miał z tym problem bawiąc się ogromnymi plikami.
Np. Logi.
- Kiedyś niechcący log internetowy stworzyłem ~50GB.
- Na innym systemie gdzie system wykrywa więcej RAM, log od gry Warframe wczytuje 1 min.
Zwłaszcza ze bawiąc się danymi mogę na tym 1GB nie poprzestać.
Wracając do skryptu basha. Generuje on od najmniejszego ciągu aż do określonego za poleceniem skryptu
czyli
generuje mi słownik o długości znaków 2, czyli coś takiego
1. Nie dałem tutaj tworzenia słownika a-z, ponieważ
dla mnie w tym momencie było rozgryzienie
Jak bardzo kolizyjne są algorytmy jeśli chodzi o długość ciągu danych.
Skoro napisałem wcześniej skrypt podobny do AIDA, który nigdy w 100% nie da pewności ze plik nie został nadpisany.
Ze względu na występujące kolizje z dużymi plikami. To warto sprawdzić który algorytm jest lepszy.
Czyli musiałem stworzyć słownik o coraz dłuższym ciągu i porównać.
2. Dlatego wystarczyłby słownik a-b, ale stwierdziłem że może bash / komputer poradzi sobie jeszcze szybciej
jeśli podam mu to w 0 i 1 ( chociaż nie wiem czy potraktuje to jak bity z których są zbudowane litery )
Gdy tylko próbnie sprawdziłem
który wygenerował wspomniany wcześniej plik o 88MB zajmując RAM ~1GB
Oczywiście zgaduje ze chodzi o otwarcie pliku
- bo plik ma podobna wielkość
- bo wątpię by np. zapamiętanie ciągu 30 znaków ciągu było dla komputera problemem,
gdy ja się tu rozpisuje o wiele bardziej
![Cheesy :D](http://forum.linux.pl/Smileys/default/cheesy.gif)
Zwłaszcza ze wyżej w przykładzie widać ze skrypt generuje bardzo duża ilość wierszy, a to tylko 2 znaki.
No chyba ze są jakieś wzory matematyczne, które zrobią to bez tworzenia słownika ...?
Zeby sprawdzić te kolizyjności musiałbym wygenerować dla niego słownik od najkrótszego wzwyż.
Dla przykładu: MD5 to 128-bitowy skrót. ( a ja nawet do 40 nie doszedłem
![Cheesy :D](http://forum.linux.pl/Smileys/default/cheesy.gif)
)
Teraz nie znajdę, ale widziałem też przykład sposobu graficznego, coś w stylu
https://i.pinimg.com/736x/24/d2/82/24d2829bb665b1f1199a818803ea6a72.jpgO tym tez będę musiał poczytać jak to się robi.
No ale tak czy siak, może kiedyś jak znajdę czas, pobawię się C / C++ , tym wspomnianym mmap,
bo jak nie do tego, to pewnie taki plik przyda mi się do czegoś innego.
A zastanawiając się jakby to mogło działać
- W przykładzie wyżej tylko dopisywałem ciąg do pliku, wiec to nie powinien być problem.
Ale gdybym chciał dopisywać gdzieś na początku lub w środku pliku to przesuwanie danych w dużym pliku mogło by trwać zbyt długo.
Czyli format pliku w każdym, powiedzmy " wierszu " musiałby uwzględnić ewentualny skok ( jak "jump" w asm
![Cheesy :D](http://forum.linux.pl/Smileys/default/cheesy.gif)
)
A później ewentualnie można plik "defragmentować" ( czyli układać jego prawidłową kolejność ).
Chociaż wczytując mala ilość danych z pliku, może to zbędne.
No i tu tez mógłby się pojawić problem ze kiedyś taki powiedzmy jeden " wiersz " pliku może zając 1 GB RAM
No i tego ograniczenia już chyba nie da się zmienić
dd faktycznie fajne
https://unix.stackexchange.com/questions/121794/read-the-middle-of-a-large-fileEdytowaneCo do skryptu sie pomylilem,
moze jednak go podam
#!/bin/bash
echo "Long word: $1"
BASE={0..1}
for WORD1 in `seq 1 $1`; do
#echo $WORD1
OUT="${OUT:+$OUT}$BASE"
#echo $OUT
for WORD2 in $( eval echo $OUT ); do
echo "$WORD2" >> base${1}
done
done
Samo " echo "$WORD2" >> base${1} " nie powoduje wzrostu pamieci RAM, wiec chyba bash za duzo chyba czegos zapamietal.
Ale fakt faktem gdy probuje recznie otworzyc plik, to zużycie RAMU nagle wrasta
EdytowaneZnalazlem takie pytanie odnosnie for (petli)
https://lists.gnu.org/archive/html/bug-bash/2010-09/msg00103.html