Użytkownik "Radosław Sokół" <R...@g...one.pl> napisał w
wiadomości news:2010021520045700@grush.one.pl...
> W dniu 2010-02-15 19:36, Latet pisze:
> > Czas kopiowania (w ramach tej samej partycji) folderu składającego się z
> > 18 tys. małych plików (razem 1.2 GB).
>
> Zadanie, którego należy unikać. Kopiowania plików w ramach
> jednego napędu fizycznego w ogóle należy unikać, jeżeli się
> da, a kopiowania małych plików -- jak ognia :)

w kontekście testu, czy w ogóle.

artur(m)

do góry

Użytkownik "Radosław Sokół" <R...@g...one.pl> napisał w
wiadomości news:2010021520045700@grush.one.pl...
>W dniu 2010-02-15 19:36, Latet pisze:
>> Czas kopiowania (w ramach tej samej partycji) folderu składającego się z
>> 18 tys. małych plików (razem 1.2 GB).
>
> Zadanie, którego należy unikać. Kopiowania plików w ramach
> jednego napędu fizycznego w ogóle należy unikać, jeżeli się
> da, a kopiowania małych plików -- jak ognia :) Więc nie wiem,
> jaki sens ma taki benchmark, bo jest nieco oderwany od rze-
> czywistości ;)


Za to jedyny domowej roboty, który można od biedy nazwać obiektywnym. Jeśli
mierzysz transfery z jednego dysku na drugi to nie wiadomo jaki w końcowym
wyniku jest udział poszczególnych napędów i stanu łącza między nimi.

do góry

W dniu 2010-02-16 09:39, Artur(m) pisze:
>> Zadanie, którego należy unikać. Kopiowania plików w ramach
>> jednego napędu fizycznego w ogóle należy unikać, jeżeli się
>> da, a kopiowania małych plików -- jak ognia :)
>
> w kontekście testu, czy w ogóle.

Ogólnie. Oczywiście, jak koniecznie trzeba skopiować pliki,
to trzeba, ale jeżeli jakiś proces obliczeniowy jest zależ-
ny od kopiowania dużej liczby plików, to należy zmienić ar-
chitekturę procesu, a nie skazywać dysku na beznadziejne
machanie głowicami.

Jest to zresztą argument przeciwko dzieleniu dysków na dużą
liczbę partycji -- w pewnym momencie okazuje się, że sporo
czasu może się tracić na przenoszenie danych między party-
cjami -- chyba, że od początku ma się bardzo dobrze określo-
ną strukturę podziału danych między partycje i idealnie do-
brane ich rozmiary :)

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\................... Microsoft MVP ......................../

do góry

W dniu 2010-02-16 14:22, MC pisze:
> Za to jedyny domowej roboty, który można od biedy nazwać obiektywnym.

Ale on mierzy jedynie:

1) w pewnym zakresie czas dostępu dysku,

2) w sporym zakresie optymalizację systemu plików pod kątem
buforowania operacji na metadanych (które jest zazwyczaj
słabe z racji zapobiegania awariom i tworzenia dziennika
zmian).

To samo tyczy się zresztą codziennej pracy: oprogramowanie
powinno działać tak, by nie wykonywać operacji zależnych od
czasu dostępu i szybkości obsługi operacji na metadanych,
bo w przeciwnym przypadku będzie bardzo trudno uzyskać sen-
sowną wydajność.

> Jeśli mierzysz transfery z jednego dysku na drugi to nie wiadomo jaki w
> końcowym wyniku jest udział poszczególnych napędów i stanu łącza między
> nimi.

Zazwyczaj wąskim gardłem są same dyski, a nie interfejsy.
Wystarczy zresztą zrobić kopiowanie do /dev/null lub z
/dev/zero, by wykluczyć większość czynników mogących wpły-
wać na pomiar. Oczywiście w takim przypadku mierzy się je-
dynie transfer sekwencyjny, bez uwzględnienia czasu dostę-
pu.

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\................... Microsoft MVP ......................../

do góry

W dniu 2010-02-15 23:04, Latet pisze:
> A sens... no cóż, chciałem przetestować operację, która będzie w jak
> największym stopniu zależna od czasu dostępu. [...]

Owszem, i to Ci się udało. Jednak w codziennej pracy należy
jak najbardziej unikać operacji zależnych od czasu dostępu.

Z tego zresztą powodu tak promuję pisanie małych i lekkich
aplikacji mimo, że RAM komputerów ma pojemność wystarczają-
cą do przechowywania wielkiego kodu i wielkich zbiorów da-
nych. Owszem, jak aplikacja jest w RAMie to działa szybko,
ale mało kto bierze pod uwagę, że musi się tam *skądś wziąć*.
A weźmie się w efekcie operacji stronicowania, która jest
dostępem silnie losowym -- a więc im mniejsza aplikacja, tym
mniej stronicowania i szybsze jej działanie (o całe rzędy
wielkości, a nie milisekundy), a im oszczędniej generuje
dane w bloku pamięci anonimowej, tym mniej operacji stroni-
cowania do pliku wymiany i podobny wzrost wydajności.

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\................... Microsoft MVP ......................../

do góry

Użytkownik "Radosław Sokół" <R...@g...one.pl> napisał w
wiadomości news:2010021907560300@grush.one.pl...
>W dniu 2010-02-16 14:22, MC pisze:
>> Za to jedyny domowej roboty, który można od biedy nazwać obiektywnym.
>
> Ale on mierzy jedynie:
>
> 1) w pewnym zakresie czas dostępu dysku,
>
> 2) w sporym zakresie optymalizację systemu plików pod kątem
> buforowania operacji na metadanych (które jest zazwyczaj
> słabe z racji zapobiegania awariom i tworzenia dziennika
> zmian).

Zgoda. Dlatego napisałem "od biedy".
>
>> Jeśli mierzysz transfery z jednego dysku na drugi to nie wiadomo jaki w
>> końcowym wyniku jest udział poszczególnych napędów i stanu łącza między
>> nimi.
>
> Zazwyczaj wąskim gardłem są same dyski, a nie interfejsy.

I to przeszkadza zmierzyć dysk szybszy za pomocą wolniejszego.

do góry

>> A sens... no cóż, chciałem przetestować operację, która będzie w jak
>> największym stopniu zależna od czasu dostępu. [...]
>
> Owszem, i to Ci się udało. Jednak w codziennej pracy należy
> jak najbardziej unikać operacji zależnych od czasu dostępu.

Jasne i własnie dlatego chciałem przetestować dysk pod tym kątem, ponieważ takie
operacje, choćbym ich nie wiem jak unikał, i tak się zdarzają, wszak nie mam
wpływu na sposób działania wielu aplikacji...

latet

do góry

W dniu 19.02.2010 14:41, Latet pisze:
>> Owszem, i to Ci się udało. Jednak w codziennej pracy należy
>> jak najbardziej unikać operacji zależnych od czasu dostępu.
>
> Jasne i własnie dlatego chciałem przetestować dysk pod tym kątem,
> ponieważ takie operacje, choćbym ich nie wiem jak unikał, i tak się
> zdarzają, wszak nie mam wpływu na sposób działania wielu aplikacji...

Ale masz wpływ na ich wybór -- możesz bojkotować aplikacje,
które są napisane nieoszczędnie i niepotrzebnie działają
wolniej, niż by mogły :)

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"
>>> Owszem, i to Ci się udało. Jednak w codziennej pracy należy
>>> jak najbardziej unikać operacji zależnych od czasu dostępu.
>> Jasne i własnie dlatego chciałem przetestować dysk pod tym kątem,
>> ponieważ takie operacje, choćbym ich nie wiem jak unikał, i tak się
>> zdarzają, wszak nie mam wpływu na sposób działania wielu aplikacji...
>Ale masz wpływ na ich wybór -- możesz bojkotować aplikacje,
>które są napisane nieoszczędnie i niepotrzebnie działają
>wolniej, niż by mogły :)

Radek, jesteś niepoprawnym idealistą. W rzeczywistości często okazuje
się, że masz do wyboru aplikację jedną z... jednej. Bo akurat musisz
zrobić coś, do czego masz po prostu jedną aplikację na rynku. Albo masz
aplikacje trzy, ale jedna tylko daje ci możliwość wymiany danych
z innymi ze względu na stopień popularności. Albo akurat taki masz
standard korporacyjny. Albo...
W ogólności masz rację, ale w szczególności ta rada jest trochę typu
"weźmy krowę sferyczną".

--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb
`b K...@e...eu.org d'
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'

do góry

W dniu 13.07.2010 09:38, Mariusz Kruk pisze:
> Radek, jesteś niepoprawnym idealistą. W rzeczywistości często okazuje
> się, że masz do wyboru aplikację jedną z... jednej. Bo akurat musisz

Nie "często" ale w "specjalizowanych zastosowaniach". Typowy
domowy użytkownik - a takich ma mnóstwo - może przebierać w
programach realizujących te same funkcje. Nie podoba się wol-
ne i wielkie Nero? Można użyć innych programów nagrywających
CD/DVD. I tak dalej...

Owszem, w pewnym momencie dochodzimy do wyborów typu "czy
wolny i toporny OpenOffice.org, czy sprawny, ale 'zły' i
komercyjny Microsoft Office". To trudne wybory i niestety
dzisiaj bardzo trudno o coś trzeciego.

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry