W dniu 2012-02-15 22:15, Marcin Biegan pisze:
> On 2012-02-15 21:08, bartekltg wrote:
>> Ale ma się terabajt czegoś bardziej podręcznego bez angażowania
>> klastra.
>
> albo 5TB :) i 6GB/s bandwidth:
> http://www.sabrepc.com/p-2521-fusion-io-fs6-802-640-
cs-0001-512tb-iodrive-octal-multi-level-cell.aspx

Testowałem fusion io, ale jakaś wersję sprzed roku z małą pojemnością. W
tamtym czasie OCZ biło ich i ceną i prędkością... Zresztą ostatnio
dostałem ofertę na dyski fusionIO od TK i ta cena :) Fakt że produkt
finalny też nie jest tani, ale tam dysk o pojemności 128GB jest 4x
droższy od 960GB z OCZ :P Na polskie warunki cena przekreśla wszystko.

pozdrawiam,
Przemek O.

do góry

W dniu 2012-02-15 22:47, Edek pisze:
> Dnia Wed, 15 Feb 2012 22:29:04 +0100 bartekltg napisał:
>
>> W dniu 2012-02-15 22:15, Marcin Biegan pisze:
>>> On 2012-02-15 21:08, bartekltg wrote:
>>>> Ale ma się terabajt czegoś bardziej podręcznego bez angażowania
>>>> klastra.
>>>
>>> albo 5TB :) i 6GB/s bandwidth:
>>> http://www.sabrepc.com/p-2521-fusion-io-fs6-802-640-
cs-0001-512tb-
> iodrive-octal-multi-level-cell.aspx
>>
>>
>> Zbieram szczękę z podłogi...
>>
>> "You Save: $10,556.00"
>>
>> dobrze, że nie mam szczęki;)
>>
>>
>> Hmm. 5 razy większy, 6 razy szybszy, i 30 razy droższy.
>> Technologia liniowa;)
>
> Pozwolę sobie przypomnieć tego posta za 5 lat ;)

Bo wtedy każdy będzie mieć takiego pendrive
czy spodziewasz się załamania owego linowego
(na skali logarytmicznej) prawa? ;)

pzdr
bartekltg

do góry

bartekltg <b...@g...com> napisał(a):

> W dniu 2012-02-15 21:26, f...@g...pl pisze:
>
> > bylo fajnie zaznaczone ze storage na wspolczesnych kompach jest
> > struktura hierarchiczną o pieciu a nawet siedmu stopniach, najnizej
> > jest dysk twardy a najwyzej (tu byc moze mala niespodzianka):
> > rejestry
>
> Ale co w tym dziwnego. PrzecieĹź to od zawsze
> 'jest na wykładach'
> http://wazniak.mimuw.edu.pl/index.php?title=MN06#Hie
rarchia_pami.C4.99ci
> Ĺťadne zaskoczenie, Ĺźadna tajemnica;)
>
>
> > bylo pokazywane ze rejestry maja ok 6 razy wieksza przepustowosc niz
> > najlepszy cache (uzasadniane bylo jakos tym ze adresowanie rejestru
> > wymaga kilka bitow a cache wiele razy wiecej itp) - i ze korzystnie
> > jest miec
>
> Bardzo rozsądne wytłumaczenie tłumaczenie.
> Hmm, coś nie mogę znaleść porównania prędkośći
> mov rejest rejestr
> mov rejestr pamiec
> mov pamiec rejestr
>
> http://www.intel.com/content/dam/doc/manual/64-ia-32
-architectures-software-
dev
> eloper-instruction-set-reference-manual-325383.pdf
> ale te półtora tysiąca stron mogło to gdzieś ukryć;)
>
> > ich duzo (mz przydalo by sie przynajmniej 16 a jeszcze lepiej i z 64
> > czemu nie) tak by przynajmniej fastcalle moc robic bez problemu -
> > tymczasem x86 ma biedne pare i dla mnie jest to niewytlumaczalne (tj
> > niezrozumiale ale jakos nie moge sie doszukac wytlumaczenia)
>
> Jeśli doża liczba rejestrów jest potrzebne 'aby szybko
> robić fastcall' to napraqwdę jest to najmniejszy problem:)
>
> Rejestrów nie jest tak mało
>
> 16 bitór miały 6+2
> 32 bity mają 6+2
> 64 bity mają 14+2
>
> wygląda więc, że cie posłuchali i zwiększyli ich ilość;)
>
> No i do tego mamy jeszcze sporo rejestrĂłw 'dodatkowych'
> koprocesora/MMX (8 po 80/64 bitĂłw)
> i 16 XMM (po 128bitĂłw) przynajmniej na x64.
>
> Ręcznie bym tego nie ogarnął;)
>
> > obok innych ciekawych informacji bylo nt tego ze kosci ramu sa 50
> > nanosekundowe (a byla to ksiazka chyba gdzies tak z 2003 czyli dosyc
> > stara) i nietrafienie w cache kosztuje wlasnie te 50 ns - wiec tu
> > przynajmniej nie jest tak zle bo ta liczba (czyli totalne
> > nietrafienie) dla mnie urastala juz do legendy :/
>
> Widzisz ten link na samej górze. Był na tej grupie jakieś 5 razy.
>
> Jest tam tabelka:
>
> Algorytm ijk ikj bikj(16) bikj(32) DGEMM ATLAS DGEMM
> Czas (s) 320.49 24.28 8.68 30.45 25.72 2.58
> Mflop/s 10.06 132.67 371.11 105.79 125.24 1248.53
>
> Te algorytmy robią to samo. Praktycznie tak samo (tyle samo mnożeń!
> bardziej skomplikowane algorytmy robią nawet więcej dodatkowych rzeczy)
> Główna różnica to 'inna kolejność działań'.
>
> Algorytm naiwny olewający sprawę cache jest ponad 100 razy gorszy.
>
> Przeanalizuj różnicę między "ijk" a "ikj". Trywialna zamiana,
> a przyspieszenie o kilkanaście razy.
>
> [na różnych precesorach wyniki są oczywisćie różne. choćby
> algorytmy blokowe mają optimum dla różnych rozmiarów bloku,
> ale prawidłowość pozostaje
> T_naiwny >> T_{z pomysłem} > T_specjalistyczny ]
>
> Oczywiście, trzeba wiedzieć, gdzie to jest istotne.
> Tu mielimy wielokrotnie dany obszar, więc zysk jest duży.
> Gdzie indziej może nie być. W przeszukiwaniu binarnym bazy
> danych nie będzie;)
>
>
mniej chodzi o zaskoczenie czy tajemnice (choc chyba rejestry
maja swoje powody by byc szybsze ) co po prostu o zwykla istotnosc
tego faktu


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Wed, 15 Feb 2012 23:06:19 +0100 bartekltg napisał:

> W dniu 2012-02-15 22:47, Edek pisze:
>> Dnia Wed, 15 Feb 2012 22:29:04 +0100 bartekltg napisał:
>>
>>> W dniu 2012-02-15 22:15, Marcin Biegan pisze:
>>>> On 2012-02-15 21:08, bartekltg wrote:
>>>>> Ale ma się terabajt czegoś bardziej podręcznego bez angażowania
>>>>> klastra.
>>>>
>>>> albo 5TB :) i 6GB/s bandwidth:
>>>> http://www.sabrepc.com/p-2521-fusion-io-fs6-802-640-
cs-0001-512tb-
>> iodrive-octal-multi-level-cell.aspx
>>>
>>>
>>> Zbieram szczękę z podłogi...
>>>
>>> "You Save: $10,556.00"
>>>
>>> dobrze, że nie mam szczęki;)
>>>
>>>
>>> Hmm. 5 razy większy, 6 razy szybszy, i 30 razy droższy.
>>> Technologia liniowa;)
>>
>> Pozwolę sobie przypomnieć tego posta za 5 lat ;)
>
> Bo wtedy każdy będzie mieć takiego pendrive

Chyba już jest interfejs eksportujący PCIEx poza kompa (Thunderbolt).

czy spodziewasz się
> załamania owego linowego (na skali logarytmicznej) prawa? ;)

Zależy od punktu widzenia, zmienna czasu zakrzywi przestrzeń... ;)
W ogóle szybkość SSD zależy od punktu widzenia, jak cie nie stać
to są awaryjne, wcale nie szybsze, małe i drogie, a jak cie stać
to nagle mają megaIOPSy.

Edek

do góry

W dniu 2012-02-15 23:38, Edek pisze:

>>>> Hmm. 5 razy większy, 6 razy szybszy, i 30 razy droższy.
>>>> Technologia liniowa;)
>>>
>>> Pozwolę sobie przypomnieć tego posta za 5 lat ;)
>>
>> Bo wtedy każdy będzie mieć takiego pendrive
>
> Chyba już jest interfejs eksportujący PCIEx poza kompa (Thunderbolt).

Coraz większe częstotliwości, kabelki z miedzianego drutu
zmieniają sie w falowody... czekam na upowszechnienie się
interfejsów światłowodowych:)

> czy spodziewasz się
>> załamania owego linowego (na skali logarytmicznej) prawa? ;)

> Zależy od punktu widzenia, zmienna czasu zakrzywi przestrzeń... ;)
> W ogóle szybkość SSD zależy od punktu widzenia, jak cie nie stać
> to są awaryjne, wcale nie szybsze, małe i drogie, a jak cie stać
> to nagle mają megaIOPSy.

Do domu to jednak poczekam aż stanieją. Mieszkanie
też trzeba kupić;)

pzdr
bartekltg

do góry

W dniu 2012-02-15 23:31, f...@g...pl pisze:

> mniej chodzi o zaskoczenie czy tajemnice (choc chyba rejestry

A mnie właśnie chodzi o to, ze to żadne zaskoczenie,
bo o tym 'jest w szkole'.

> maja swoje powody by byc szybsze ) co po prostu o zwykla istotnosc
> tego faktu

Rejestr to nie jest jakiś obszar pamięci, tylko jakby
łapka procesora. Procesor zawsze wie, gdzie ma łapki.

I jak mu każesz zrobić moc eax ebx to wie, ze ma przełozyć
z drugiej łapki do pierwszej.

Jak dostanie mov eax [ebx] to musi siegnąć do pamięci
pod odpowiedni adres (sprawdzajac, czy jest on na biurku,
czyli za cache, czy jednak trzeba wzywać kuriera z RAMu)
i dopiero sięgnąć jednoą lapką tam, gdzie wskazuje druga
i pobrać. I pobrać z dużego i zabałagonionego biurka.


pzdr
bartekltg

do góry

Dnia Thu, 16 Feb 2012 00:11:55 +0100 bartekltg napisał:

> W dniu 2012-02-15 23:38, Edek pisze:
>

>
>> czy spodziewasz się
>>> załamania owego linowego (na skali logarytmicznej) prawa? ;)
>
>> Zależy od punktu widzenia, zmienna czasu zakrzywi przestrzeń... ;)
>> W ogóle szybkość SSD zależy od punktu widzenia, jak cie nie stać to są
>> awaryjne, wcale nie szybsze, małe i drogie, a jak cie stać to nagle
>> mają megaIOPSy.
>
> Do domu to jednak poczekam aż stanieją. Mieszkanie też trzeba kupić;)

Czy ja wiem, ja już nie potrafię pracować na kompie bez SSD. Może nie
taki, o jakich mowa powyżej, ale przyzwoity 128G daje radę.

Edek

do góry

W dniu 2012-02-16 00:50, Edek pisze:
> Dnia Thu, 16 Feb 2012 00:11:55 +0100 bartekltg napisał:
>
>> W dniu 2012-02-15 23:38, Edek pisze:
>>
>
>>
>>> czy spodziewasz się
>>>> załamania owego linowego (na skali logarytmicznej) prawa? ;)
>>
>>> Zależy od punktu widzenia, zmienna czasu zakrzywi przestrzeń... ;)
>>> W ogóle szybkość SSD zależy od punktu widzenia, jak cie nie stać to są
>>> awaryjne, wcale nie szybsze, małe i drogie, a jak cie stać to nagle
>>> mają megaIOPSy.
>>
>> Do domu to jednak poczekam aż stanieją. Mieszkanie też trzeba kupić;)
>
> Czy ja wiem, ja już nie potrafię pracować na kompie bez SSD. Może nie
> taki, o jakich mowa powyżej, ale przyzwoity 128G daje radę.

A co ja tam włożę, waciki? ;)

A na serio?
System? -pewnie coś da, zwłaszcza bootowanie.

Swap. Ok. Z drugiej strony, właśnie idzie do mnie paczka z 8GB RAMu
aby łączna mocą 12 problem wyeliminować przy 'domowych zabawach'.

Coś jeszcze? Programy? Chyba nie ma sensu wszystkich.

W sumie zostanie ~100GB na fajny bufor.


Zrobiłem sobie testy jakimś prostym programikiem.
Zapis-odczyć ciagły ok 100MB/s
Losowo Kawałkami po 0.5MB - 50MB/s
Losowo kawałkami po 4kb 0.5MB/s

Dwustukrotny spadek wydajności ładnie.

Nadal jednak miałbym wątpliwości. A Szkotem nie jestem;)
No i mam 'tylko' SATA300


pzdr
bartekltg

do góry

Dnia Thu, 16 Feb 2012 17:17:49 +0100 bartekltg napisał:

> W dniu 2012-02-16 00:50, Edek pisze:
>> Dnia Thu, 16 Feb 2012 00:11:55 +0100 bartekltg napisał:
>>
>>> W dniu 2012-02-15 23:38, Edek pisze:
>>>
>>>
>>
>>>> czy spodziewasz się
>>>>> załamania owego linowego (na skali logarytmicznej) prawa? ;)
>>>
>>>> Zależy od punktu widzenia, zmienna czasu zakrzywi przestrzeń... ;)
>>>> W ogóle szybkość SSD zależy od punktu widzenia, jak cie nie stać to
>>>> są awaryjne, wcale nie szybsze, małe i drogie, a jak cie stać to
>>>> nagle mają megaIOPSy.
>>>
>>> Do domu to jednak poczekam aż stanieją. Mieszkanie też trzeba kupić;)
>>
>> Czy ja wiem, ja już nie potrafię pracować na kompie bez SSD. Może nie
>> taki, o jakich mowa powyżej, ale przyzwoity 128G daje radę.
>
> A co ja tam włożę, waciki? ;)

Nie podejrzewam cię o fetysz zdjęć HD wacików ;)

>
> A na serio?
> System? -pewnie coś da, zwłaszcza bootowanie.
>
> Swap. Ok. Z drugiej strony, właśnie idzie do mnie paczka z 8GB RAMu aby
> łączna mocą 12 problem wyeliminować przy 'domowych zabawach'.
>
> Coś jeszcze? Programy? Chyba nie ma sensu wszystkich.
>
> W sumie zostanie ~100GB na fajny bufor.

Nie wiem, co mi tyle zajmuje. Zazwyczaj dwa systemy, po 10 wersji
różnych cud, sdków i innych badziewi, trochę baz (niewielkich w sumie),
jakoś to miejsce schodzi. 80 by wystarczyło, 64 z trudem, a nie chcę
kupować nowego za rok dwa.

>
>
> Zrobiłem sobie testy jakimś prostym programikiem.
> Zapis-odczyć ciagły ok 100MB/s Losowo Kawałkami po 0.5MB - 50MB/s Losowo
> kawałkami po 4kb 0.5MB/s
>
> Dwustukrotny spadek wydajności ładnie.
>
> Nadal jednak miałbym wątpliwości. A Szkotem nie jestem;)
> No i mam 'tylko' SATA300

Zrobiłem test na starszym, 25M przy 4k write. Trochę lipny test, ale
w praktyce jest podobnie.

Też mam SATA300, ale ponieważ mi sekwencyjny zapis/odczyt nie robi
różnicy (nie kopiuję żadnych filmów pomiędzy ssd), to mi to wisi.
Nawet odkryłem, że driver [1] czasem przełącza link w tryb 1.5Gb, ale tego
nigdy nie zauważyłem używając, niepotrzebnie ;) zajrzałem do logów.

Bottom line: jeżeli cykl kompilacja-uruchomienie zajmuje 1m20s
zamiast 7m50s, to ja to lubię.

Edek

[1] trochę skasztaniony driver do jakiegoś IC Marvela, nie chce mi się
szukać.

do góry

bartekltg <b...@g...com> napisał(a):
>
> Piękna rzecz. Dobrze, że uświadomiliście mi istnienie czegoś
> takiego. Drogie koszmarnie, ale taki 1T 'prawie RAMu'*)
> w paru przypadkach może się przydać.
>
> *) to prawie i w cenie
> $3600 za 960GB to 3.7$/GB
>
> A RAM juz od jakiś $7/GB
>
> Ale ma się terabajt czegoś bardziej podręcznego bez angażowania
> klastra.

Ma ktoś możliwość uruchomienia na podobnym sprzęcie programu, który
na ogromnym pliku (np. 10 razy większym niż dostępna ram w komputerze)
ustawia głowice w losowym miejscu i na przemian zapisuje losowy jeden
bajt albo odczytuje?

Interesuje mnie ilosc operacji wejscia/wyjsca na sekunde w zależności od
ceny.

Z góry dzięki, pozdrawiam.



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry