Windows 10 będzie potrzebował mniej miejsca

[KopalniaWiedzy.pl 324]

System Windows 10 będzie potrzebował nawet 2,6 gigabajta przestrzeni dyskowej mniej niż dotychczas, gdyż będzie kompresował własne pliki. Dodatkowe 4-12 gigabajtów zostanie zaoszczędzonych dzięki rezygnacji z obrazu potrzebnego do odzyskania systemu w razie awarii. Windows 10 został napisany tak, by radził sobie bez tego obrazu.

Dzięki skompresowaniu plików systemowych użytkownicy 32-bitowej wersji nowego OS-u zaoszczędzą 1,5 gigabajta, a użytkownicy wersji 64-bitowej – 2,6 GB. Producenci komputerów z preinstalowanym systemem nie będą już umieszczali na dysku obrazu OS-u. Użytkownicy będą mogli jednak skorzystać z własnego nośnika z kompletnym obrazem systemu oraz zainstalowanych programów i odzyskać z niego całe oprogramowanie w razie awarii. Taki nośnik przyda się, gdy system ulegnie na tyle poważnej awarii, że nie będzie w stanie sam siebie naprawić.

« powrót do artykułu

[Piotrus Pan 0]

MS znowu kombinuje i znowu w złą stronę. Kompresja to spadek wydajności, poza tym HDD 1TB można już tanio kupić, więc posiadając 1TB co za różnicę mi zrobi zyskanie 2,6GB?

Nawet jak MS zakłada, że wszyscy już mają SSD, to czy kompresja nie wywołuje więcej okeracji dyskowych? Czyli szybciej wykańcza SSD?

Z nimi tak zawsze ... jeden krok do przodu i dwa do tyłu ...

[wilk 103]

Ciekawe jak się chodzi z HDD podpiętym do telefonu - pamiętaj, że Windows 10 ma być jeden na wszystkie platformy. Dlaczego ma być więcej operacji odczytu? Mniejszy plik - mniej komórek/sektorów zajmuje. Ponadto w przypadku SSD nie mamy problemu z fragmentacją. Jedyny problem, tak jak piszesz, to narzut na dekompresję. Ostatnio pojawiły się wyniki testu SSD wedle których najwytrwalszy model wytrzymał 2,4PB transferu: http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead

[Astroboy 34]

 

 

pamiętaj, że Windows 10 ma być jeden na wszystkie platformy

 

To mnie właśnie przeraża. Linuxa stawia się bez problemu na superkomputerze, komputerze domowym, telefonie, tunerze satelitarnym czy pralce od wielu lat, ale oczywiście noblesse oblige.

[thikim 117]

Z kompresją zależy jakie dane się kompresuje. Jak kompresujemy pliki rzadko używane i takie do których czas dostępu nie jest krytyczny to spadku wydajności systemu nie zauważymy.

Zresztą po prawdzie to wiele exeków to pliki skompresowane i jakoś nikomu to nie przeszkadza...

Niektóre pliki systemowe są skompresowane już od dawna w wielu windowsach i dopóki o tym nie napisali to nikomu spadek wydajności nie przeszkadzał

Edytowane 19 marca 2015 przez thikim

[chwytajemocje 0]

Dla mnie osobiście wszystkie systemy powyżej systemu windows Xp, dziadostwo. Mianowice dla tego że kupuje się system z mnóstwem niepotrzebnych nam rzeczy które zżerają tylko pamięć ram, procesor i zapychają dysk śmieciami. Po za tym gratuluję wszystkim firmom które wypuszczają kompy z systemem win 7 i dają 2 lub 3 giga ramu, na początku działa spoko ale pobierze parę aktualizacji i zainstaluje się kilka programów to już po jakimś czasie zaczyna nieco zamulać. Widocznie firmy które konfigurują ten sprzęt nie mają wiedzy o tym że win 7 w pełni wykorzystuje swoje zasoby dopiero przy 4 giga ramu.
Zwłaszcza gratuluję firmie NTT która wypuściła netbuki z systemem win 7 i jednym giga ramu, a żeby było tego mało to po dołożeniu 3 giga, system widzi tylko 2, rewelacja.
Pozdrawiam
 

Edytowane 20 marca 2015 przez pogo
usunięta reklama

[Jarek Duda 131]

Kompresja w locie wymaga szybkich/tanich kompresorów - i trochę się ostatnio zmieniło na tym polu.

Standardowo używamy np. gzipa - tutaj jest porównanie z kilkoma kompresorami które już przeszły z kodowania Huffmana lub Range coding na Asymmetric Numeral Systems (zhuff, lzturbo, LZA, ZSTD) z http://mattmahoney.net/dc/text.html :

 

kompresor, wielkość enwiki8 po skompresowaniu, czas kompresji, dekompresji (ns/bajt)

LZA 0.82b  –mx9 –b7 –h7  26,396,613  449  9.7
lzturbo 1.2  –39  –b24         26,915,461  582  2.8
WinRAR 5.00  –ma5 –m5   27,835,431  1004  31
WinRAR 5.00  –ma5 –m2   29,758,785  228  30
lzturbo 1.2  –32                   30,979,376  19  2.7
zhuff 0.97 –c2                     34,907,478  24  3.5
gzip 1.3.5   –9                     36,445,248  101  17
pkzip 2.0.4 –ex                    36,556,552  171  50
ZSTD 0.0.1                         40,024,854  7.7  3.8
WinRAR 5.00 –ma5 –m1    40,565,268  54  31

 

Czyli są rzędu 5 razy szybsze zarówno w kodowaniu jak i dekodowaniu od opartych na Huffmanie (rar, gzip, pkzip) dla podobnego stopnia kompresji.

Dekodowanie ~500MB/s na rdzeń procesora to teraz standard dla ANS ( https://github.com/Cyan4973/FiniteStateEntropy ) - przy takich prędkościach można sobie pozwolić na kompresję w biegu - zarówno żeby oszczędzić miejsce na dysku, ale także żeby przyśpieszyć transmisję.

Edytowane 20 marca 2015 przez Jarek Duda

[wilk 103]

po dołożeniu 3 giga, system widzi tylko 2

 

Przyczyn może być wiele. Na początek sprawdź ile masz w BIOS-ie zarezerwowane na karty AGP. Możliwe, że masz wersję Starter, która więcej niż 2GB nie obsłuży nigdy. Moduły mogą się "gryźć" ze sobą. Spróbuj wkładać moduły w innej kolejności lub nie wszystkie naraz i odpalać system. Ostatecznie mogą być uszkodzone.

 

Niektóre pliki systemowe są skompresowane już od dawna w wielu windowsach i dopóki o tym nie napisali to nikomu spadek wydajności nie przeszkadzał

 

Hehe, dokładnie. Przy przetwarzaniu np. skompresowanych folderów z mnóstwem plików tekstowych wydajność jest minimalnie zauważalna, a oszczędność miejsca gigantyczna. Poza tym zapewne obrazy exe-ków byłyby utrzymywane w pamięci w postaci rozpakowanej już, więc ewentualny spadek wydajności byłby tylko przy pierwszym odwołaniu się do jakiejś biblioteki.

[Jarek Duda 131]

Szybka kompresja raczej poprawia wydajność dysków, których fizyczny transfer jest zwykle tym wąskim gardłem - dzięki kompresji wystarczy odczytać mniejszy plik.

Np. LZ4 ( https://code.google.com/p/lz4/ ), używany w dziesiątkach produktów, osiąga 2GB/s/rdzeń  - dużo taniej zdekodować w locie niż przeczytać z dysku większy plik.

Tak samo kompresja w locie pozwala zmniejszyć wymagania transmisji (np. walka H.264 -> H.265) - przyszłość to trzymać wszystko skompresowane.

Niestety problem jest zwykle z dostępem wewnątrz takich danych, ale też idzie się w tą stronę: http://en.wikipedia.org/wiki/Compressed_data_structure

[Astroboy 34]

Ciekaw jestem, kiedy hardwarowe rozwiązania na stałe zagoszczą na płytach głównych. Ciekawostka:

http://www.academia.edu/3308033/On-board_Implementation_of_Fractal_Compression_of_Satellite_Images_using_Distributed_Networked_GPUs

[Jarek Duda 131]

Odnośnie kosztownych kompresorów, szczególnie wideo, pewnie masz ASIC w telefonie ...

Dla reszty chyba wystarczy procesor - dostając rzędu 2GB/s/rdzeń dla kiepskiej kompresji, czy rzędu 500MB/s/rdzeń dla przyzwoitej.

Ale jasne można też robić FPGA czy ASIC - tutaj ANS też poprawia sytuację bo ma prostą tanią inicjalizację, podczas gdy Huffman wymaga sortowania symboli - budowanie drzewa jest sprzętowo dość kosztowne.

[Astroboy 34]

Jasne:

"The Internet? We are not interested in it"

"640K ought to be enough for anybody"

 

Mam bardzo prosty telefon, którym można wbijać gwoździe i dzwonić/esemesować. Jakoś niczego więcej nie oczekuję od telefonu.

[Jarek Duda 131]

A jak przestanie obsługiwać nowe modele gwoździ...

 

Pewnie i tak ma sprzętową kompresję dźwięku.

[Astroboy 34]

 

 

A jak przestanie obsługiwać nowe modele gwoździ...

 

Tu technologia nie odnosi takich sukcesów, ale przyznam, że nie testowałem tytanowych gwoździ. Prozaiczna sprawa – nie stać mnie na to.

 

 

 

Pewnie i tak ma sprzętową kompresję dźwięku.

 

Owszem. Jak sam zauważasz, hardware ma kolosalną przyszłość.

[thikim 117]

Nie chciało mi się pisać więcej bo myślałem że wystarczy to co napisałem.

Tu nie chodzi o kompresowanie dużych ilości danych i tworzenie dysku skompresowanego (co umożliwiał już bodajże Windows 95) ani o robienie paczek archiwów co robiono już od DOSa.

Tylko w takich wypadkach byłby obserwowany jakiś spadek szybkości.

Tu chodzi o to że kompresji możemy poddawać poszczególne pliki.

Jak sobie skompresujemy plik 10 MB do załóżmy 7 MB to jakie będą opóźnienia przy jego załadowaniu do pamięci i dekompresji?

Załadować to go nawet szybciej załadujemy a zdekompresowanie 10 MB zajmie ułamki sekund nie odczuwalne. Wiele plików będzie tutaj skompresowanych niezależnie. Plików które zapewne są rzadziej używane przez system.

A te częściej też można w zasadzie skompresować bo zostaną zdekompresowane raz w czasie uruchamiania systemu i przez cały czas jego pracy pozostaną w pamięci operacyjnej.

http://arstechnica.com/information-technology/2015/03/windows-10-shaves-off-gigabytes-with-selective-system-file-compression/

"To enable high performance decompression, Microsoft has added a number of new compression algorithms to the NTFS filesystem that are designed for compressing executable files. These all appear to be variants of algorithms already well used and tested in other Windows software; three are variants of the "Xpress" algorithm used for hibernation files, Windows Updates, and the Windows Imaging Format (WIM) files used by the Windows installer. The fourth algorithm, LZX, is used in Microsoft's CAB archives, and it's also an option for WIM. The different algorithms each offer different size/space trade-offs. These join the LZNT1 algorithm that's more suitable for general data compression."

Oczywiście najpierw napisałem jak jest a dopiero później poszukałem artykułu dla niedowiarków

Chodzi o kompresowanie wykonywalnych plików. Co wiele firm (i MS) i tak robiło wcześniej, tylko na poziomie tworzenia oprogramowania.

[Jarek Duda 131]

Przy szybkiej kompresji, nawet w RAMie może bardziej się opłacać trzymać skompresowane, jak w przypadku kompresji tekstur: http://en.wikipedia.org/wiki/Texture_compression

Szczególnie przy rozwoju sprzętowej - może warto kompresować nawet np. komunikację między CPU i GPU ...

Edytowane 20 marca 2015 przez Jarek Duda

[Astroboy 34]

 

 

Microsoft has added a number of new compression algorithms to the NTFS filesystem that are designed for compressing executable files.

 

Dla mnie to niezbyt rozsądny pomysł. Dlaczego niby system plików nie miałby odpowiadać za blokadę treści pornograficznych? Uważam, że nie tędy droga. Jarku, ten pomysł nie przerzuca odpowiedzialności na procesory.

 

"Przy szybkiej kompresji, nawet w RAMie może bardziej się opłacać trzymać skompresowane. Szczególnie przy rozwoju sprzętowej."

Jarek, producenci procesorów przy takim podejściu już zacierają ręce.

[Jarek Duda 131]

Apple też się odchudza: http://thenextweb.com/apple/2015/06/09/app-thinning-in-ios-9-might-finally-mean-your-16gb-iphone-isnt-always-out-of-space/

obiecują zmniejszyć z 4.6 do 1.3 GB - dość ostro.

Jednym z czynników jest ich nowy kompresor: LZFSE, czyli Lempel Ziv Finite State Entropy, gdzie to FSE to już nie standardowy Huffman czy kodowanie arytmetyczne, tylko wspomniany ANS: https://github.com/Cyan4973/FiniteStateEntropy

Twierdzą że LZFSE jest 3x szybszy, dając lepszą kompresję od standardowego ZLIB. ANS niedługo spotkamy też w grach ( http://cbloomrants.blogspot.de/2015/05/05-09-15-oodle-lzna.html ), kompresji DNA (CRAM 3.0: http://www.ebi.ac.uk/ena/software/cram-toolkit ) i wielu innych miejscach (np. https://github.com/Cyan4973/zstd czy https://sites.google.com/site/powturbo/ ).

[Astroboy 34]

W tym konteście działający Linux (jądro) wygląda jakoś dziwnie; wciąż mieści się chyba na dyskietce.

[Jajcenty 314]

wciąż mieści się chyba na dyskietce

 

 

Nie. Od lat się już nie mieści. Oczywiście możesz sobie przykroić i pewnie da się zmieścić. Się składa, że właśnie od kolegów dostałem brand noje Debian:

-rw-r--r-- 1 root root 15931756 cze 12 10:03 initrd.img-3.16.0-4-amd64

Ma to 15 mega z hakiem 

a kernel:

-rw-r--r-- 1 root root  3112752 maj 26 06:05 vmlinuz-3.16.0-4-amd64

prawie 3

 

 

Edytowane 12 czerwca 2015 przez Jajcenty

[Astroboy 34]

 

 

a kernel: -rw-r--r-- 1 root root 3112752 maj 26 06:05 vmlinuz-3.16.0-4-amd64 prawie 3

 

Niech będzie, dwie dyskietki z hakiem… Pewnie wpierdzielone elementy zewnętrznego sterownika "nv".

[Jajcenty 314]

 

 

Niech będzie, dwie dyskietki z hakiem

 

Nie umiem powiedzieć co tam jest. Od lat nie skompilowałem sobie jądra. Jednak branie pod uwagę tylko jądra bez modułów to trochę jak podawanie długości penisa z kręgosłupem . Potrzebujemy też /bin oraz /usr/bin. Walka (Win vs Lin) na rozmiary będzie długa i wyniszczająca.

[Astroboy 34]

 

 

to trochę jak podawanie długości penisa z kręgosłupem . Potrzebujemy też /bin oraz /usr/bin. Walka (Win vs Lin) na rozmiary będzie długa i wyniszczająca.

 

Niekoniecznie. Tuner satelitarny sąsiada (naprawiłem gadzinie ) chodzi pod Linuxem (całkiem sympatyczne OSD). Spróbuj tam postawić jakiegoś windowza.

Edit: oczywiście, by nie wychodziło, że to, o czym pisze Jarek nie ma sensu (bo ma): vmlinuz to od giezzipowanego vmlinuxa, ale ma to już tyle lat, że szkoda gadać.

[Jarek Duda 131]

Owszem giezip to prehistoria (Huffman) - proponuję porównać sobie z czymś na ANS, np. (LZ+tANS jak LZFSE Apple) https://sites.google.com/site/powturbo/

[Krzychoo 29]

Jest jakiś kompresor ANS na winde?