Szybszy Windows
Firma Diskeeper, która specjalizuje się w oprogramowaniu do defragmentacji dysków, twierdzi, że jest w przededniu znaczącego przełomu technologicznego, dzięki któremu systemy z rodziny Windows będą uruchamiały się 20% krócej niż obecnie. Program, który pozwala na takie zwiększenie wydajności ma jeszcze w trzecim kwartale bieżącego roku trafić do producentów systemów komputerowych.
Szeroko zakrojone testy przeprowadzone w systemie Windows XP na różnych platformach sprzętowych wykazały znaczące skrócenie czasu uruchamiania systemu. W niektórych przypadkach startował on o 10 sekund szybciej. Testy na Windows 7 RC wykazały nawet 20-procentowe skrócenie czasu uruchamiania systemu - oświadczyli przedstawiciele Diskeepera.
Firma nie testowała Visty, gdyż nie przygotuje swojego programu dla tego systemu. Z naszych rozmów z OEM wynika, że czas życia Visty będzie ograniczony. W XP wciąż tkwi potencjał, ale wszyscy skupiają się na Windows 7 - mówi John Lake z Diskeepera.
Na razie nie zdradzono zasady działania nowego programu, ani jego nazwy. Wiadomo tylko, że system Windows 7 startuje od 15 do 26% szybciej (przeciętnie ponad 20%), a Windows XP do 30% szybciej.
Program będzie najprawdopodobniej dostarczany tylko z nowymi komputerami.
Komentarze (19)
Tolo, 15 czerwca 2009, 17:05
Jakoś nie wydaje mi się ze mogło by to być coś bardziej skomplikowanego jak optymalizacja plików w kontekście ich rozmieszczenia. Pewnie odpowiednie ich rozmieszczenie w połączeniu ze stała defragmentacją newralgicznych plików np przed zamknięciem systemu zadba o prędkość.
Kiedyś speed disk czy turbo speed disk potrafiły dużo pomóc przy defragmentacji na wolnych dyskach <100 mega jak się umiejętnie poukładało pliki na początku dysku to wolne dyski znacznie przyspieszały Ale to było w czasach fgdzy kazdy pocięty plik wydatnie zwalniał system. Pojawiły się Windowsy komputery przyspieszyły i ludzie o tym zapomnieli tak jak o wirusach w MBR.
mikroos, 15 czerwca 2009, 17:20
Nie wystarczy rozmieścić plików blisko siebie (albo inaczej: to poprawi szybkość, ale to już przecież jest znane od lat), bo co z tego, że są blisko, jeżeli pliki odczytywane wspólnie będą rozrzucone? Osobiście przypuszczam, że ten program zmienia pozycję plików, ale nie wszystkich i nie tylko zwyczajnie jeden za drugim. Przypuszczam, że może chodzić o to, by dane odczytywane jednocześnie znajdowały się na różnych talerzach dysku, i żeby te odczytywane po nich także były na różnych talerzach, ale zaraz za tymi odczytywanymi poprzednio. Mam nadzieję, że napisałem dość jasno
Przynajmniej ja bym tak to zrobił, gdybym był dostatecznie kompetentny, by przekuć tę myśl na konkretny kod ;D
thikim, 15 czerwca 2009, 17:29
Wydawało mi się że tak robi się już od lat...
Tutaj poruszono jedynie kwestie uruchamiania.
Rozwiązanie jakie można zastosować jest następujące.
Pliki wczytywane w czasie startu systemu ułożyć w postaci jednego bloku danych na początku dysku w kolejności wczytywania. Można te pliki np umieścić w pliku swp (pamięci wirtualnej) w postaci jednego pliku.
Programy do defragmentacji robią podobną operację, ale:
1. Nie zwracają większej uwagi na kolejność wczytywania plików.
2. Pliki chociaż same są zdefragmentowane to już w czasie wczytywania głowica musi troche po dysku poskakać gdyż nie są ułożone w pobliżu siebie.
3. W każdym systemie są różne pliki wczytywane a programy do defragmentacji mają mało zindywidualizowane ustawienia.
mikroos, 15 czerwca 2009, 17:52
Ogólnie mówiąc miałem to samo na myśli, szczególnie z tym układaniem plików na talerzach w kolejności odpowiadającej kolejności, w jakiej bedą odczytywane, a nie tylko przypadkowo jeden za drugim.
thikim, 15 czerwca 2009, 18:58
Wspomniałeś o różnych talerzach co sugerowało że to jest ten pomysł(a to już jest od dawna, pliki zapisuje się cylindrycznie od zewnątrz). Co do układania to każdy program defragmentujący jakoś układa.
Gość derobert, 15 czerwca 2009, 19:18
wow no po prostu ekstra przyspieszenie, ludzie beda czekac 2 minuty zamiast 2,5...
z resztą hibernacja jest fajniejsza bo komputer uruchamia się jakieś 10 sekund.
Tolo, 15 czerwca 2009, 19:49
Panowie ale właśnie w czasach dosa jeden z wymienionych przeze mnie programów (albo oba bo to w zasadzie było chyba nawet to samo) miał taka możliwość by zdefiniować mu kolejność plików jaka ma być po defragmentacji.
mikroos Co do tych talerzy to tak sie to odbywa od zawsze tylko ze nie wiem czy z poziomu Windowsa było by możliwe manipulowanie tym, trzeba mieć na uwadze ze dysk twardy jest w stanie maskować swoja rzeczywistą wewnętrzną strukturę fizyczną mapować ją na inna tak jak to ma w miejsce w przypadku relokacji uszkodzonych sektorów. Fizycznie sektor jest gdzieś indziej ale to problem dysku bo na zewnątrz wygląda jak by była to (nazwijmy to tak) strukturą ciągłą.
To umieszczanie w jednym pliku tez kiedyś grali nazywało się to drvspace/dblspace to było narzędzie do kompresji dysków które pozwalało zaoszczędzić miejsce tracone w slackspace przy dużej ilości plików (tak pi razy drzwi 0.5 pojemności pojedynczego sektora/plik) i jeszcze troszkę przez kompresje. Problem jednak jest taki ze taki pojedynczy plik ma ten minus ze musi posiadać dodatkowo jakąś wewnętrzna strukturę. Co daje dodatkowy narzut na jego przeszukiwanie.
Jak dla mnie to pomysł ten musi oszczędzać czas "mechanicznej pracy" dysku a wiec tak rozmieścić dane na dysku i na tyle mało pofragmentowane by głowica wykonywała jak najmniej przeskoków. W przyadku systemu DOS który wczytywał pliki przy uruchomieniu praktycznie w przewidywalnej sekwencji odpowiednie ułożenie plików i brak fragmentacji miało znaczeni kluczowe ponieważ głowica nie wykonywała dalekich skoków które jeszcze wtedy zdarzało się ze były realizowane przez silniki krokowe a nie voice coil. I dwa identyczne komputery były się w stanie uruchamiać z rożną szybkością.
To będzie dla mnie powielenie tego schematu Bo naprawdę jest wiele zapomnianych roziązań które kiedyś były stosowane powszechnie ale poszły w niepamięć.
Tolo, 15 czerwca 2009, 19:55
thikim, 15 czerwca 2009, 20:44
Tak i nie. Na tej zasadzie obecnie działa pamięć wirtualna. O tym pisałem a nie o drvspace które służyło do zupełnie innych celów.
Przeliczenie adresów w przypadku takiego pliku to owszem opóźnienie ale niewielkie w porównaniu z zyskiem na braku wykonania dodatkowych ruchów głowicą.
To jest już robione od dawna.
I myślę że hibernacja to przyszłość uruchamiania. Oczywiście lekko zmodyfikowana.
Tolo, 15 czerwca 2009, 21:09
Boje się ze jednak zamkniecie tego w jednym pliku nie minimalizuje skoków głowicy bo będzie koneczne wyszukiwanie oparciu o jakąś strukturę wewnętrzna. I będzie to zdublowanie tej samej czynności raz na poziomie systemu plików a drugi raz na poziomie pliku. Poza tym to była by już ingerencja w sam system.
Wiem, ze to jest robione od dawna nawet ob bardzo dawna przykład z początku lat 90tyh podałem w pierwszym poście.
Tylko ze o ile ten proces byłem w stanie przeprowadzić ręcznie pod dosem jako mały gnojek chodzący do podstawówki (sam bym na to pewnie nie wpadł ale miałem w okolicy kliku starszych mistrzów a internetu wtedy nie było, to były czasy w których jak znajomy powiedział w swoim technikum ze będzie składać sobie komputer to odpowiedź kolegów z jego klasy brzmiała a jak ty sobie z tymi wszystkimi kabelkami środku poradzisz a Bajtek po złożeniu komputera zalecał 24 ro godzinne testowanie a i tak czytało się to jak SF).
Dzisiaj w przyadku Windowsa XP ręczna taka optymalizacja jest praktycznie niewykonalna i o ile w przyadku dosa kolejność ładowania pliko była albo stała albo definiowana przez mnie to pod Xp nie mam na to wpływu poza tym każdy Windows będzie inny i być może nawet zmienny w czasie i to tu może być genialność tego pomysłu.
mikroos, 15 czerwca 2009, 21:21
Nie masz wpływu na kolejność ładowania plików, ale przecież możesz podsunąć Windowsowi potrzebne pliki w odpowiedniej kolejności![:P](https://forum.kopalniawiedzy.pl/uploads/emoticons/default_tongue.png)
Tolo, 15 czerwca 2009, 21:23
Ale nie mam gwarancji ze ta kolejność jest stała w czasie.
czesiu, 15 czerwca 2009, 22:31
Dla Windows XP takim cudem techniki miał być program bootvis (który w jedynie sobie znany sposób optymalizował proces uruchamiania systemu).
Odnośnie kolejności uruchamiania programów - w jakimś chipie (z ostatniego pół roku, w dziale jakże pomocnych "tipsów") był opis jak ustalić własną kolejność uruchamiania aplikacji - wszystkie automatycznie uruchamiane programy znajdujące się w najróżniejszych miejscach rejestru są pakowane do pliku wsadowego (BAT), który jest automatycznie uruchamiany (za pośrednictwem rejestru) z systemem. Z tego co mi pozostało w pamięci ręczne przerzucenie wszystkich wpisów w jedno miejsce uruchamiania się nie sprawdza, bo Windows domyślnie uruchamia programy na zasadzie "kto pierwszy ten lepszy". Pomijam fakt że rejestr w Windowsie jest jednym wielkim śmietnikiem, w którym połowa rzeczy nigdy nie powinna się znaleźć.
czesiu, 15 czerwca 2009, 23:11
BTW - co za różnica czy system uruchamia się 2 min czy też 4min? Ważne jest, aby działał szybko już po uruchomieniu. U mnie komputer "chodzi" praktycznie przez cały dzień, tak więc nawet zakładając 3 uruchomienia - 6 - 12 minut wobec 12 godzin jest niczym.
[jak na złość nie znalazłem przycisku umożliwiającego edycję posta]
mikroos, 15 czerwca 2009, 23:19
Nie wiem, jak jest w Windowsie, bo ma zamknięte jądro, ale w Linuksie możesz bardzo precyzyjnie ustalić kolejność wgrywania poszczególnych plików. Spodziewam się, że w Windowsie też.
wilk, 16 czerwca 2009, 12:26
Sęk w tym, że systemowo praktycznie nie ma sposobu na ustalenie kolejności autostartu, a jedynie włączenie/wyłączenie. W systemach 9x były narzędzia walign/winalign, które optymalizowały aplikacje. Pakiet Nortona także prócz świetnego defragmentatora miał jakiś optymalizer. Pamiętam, że było też narzędzie, które ładowało do pamięci DLL-ki zanim uruchomiono aplikację. Natomiast jedyne sensowne narzędzie do autostartu to Autorun z zestawu dawnego SysInternals i odhaczanie zbędnych programów i "speedlaunch", które rzekomo mają przyspieszyć start niektórych aplikacji (np. acrobar reader czy java quick start), ale przez to zajmują cykle i bieżącą pamięć, zaś samo przyspieszenie jest mało warte. No i oczywiście sensowna defragmentacja. Np. w przypadku O&O Defrag pierw pełna alfabetyczna lub pod względem czasu dostępu, a potem systematyczne defragmentacje wolnego miejsca.
mikroos, 16 czerwca 2009, 13:00
Nie, ale jest sposób na ustawienie plików właśnie w takiej kolejności.
thikim, 16 czerwca 2009, 18:01
Ależ oczywiście że jest
jak zwykle kilka.
Plik bat z ukrytym wyprowadzaniem wyników na ekran.
Nie trzeba się bać
Trzeba ten plik wczytać do dużej pamięci RAM i wówczas można skakać po niej jak się chce. Zresztą podobnie działa pamięć wirtualna o której pisałem wcześniej
Obecnie przeciętny nowy komputer ma tej pamięci 2 GB lub więcej, przy czym XP wystarczy 500-600 MB. Resztę można właśnie tak wykorzystać.
wilk, 16 czerwca 2009, 20:06
No tak, ale to NIE jest rozwiązanie systemowe (udostępniane przez system), a zabawa na około. Zresztą to tylko uszereguje moment uruchomienia zadania i nie spowoduje przyspieszenia ładowania. Pamiętać trzeba także, że same aplikacje też nie startują błyskawicznie, a wpierw przygotowują swoje środowisko, ładują biblioteki itd., zatem multitasking i tak swoje zrobi i ich uruchomienie się nałoży na siebie. No chyba, że da się opóźnienia, ale przecież zależy tutaj na jak najszybszym starcie. Poza tym kolejności/opóźniania uruchamiania serwisów, sterowników itd. w ten sposób się nie zrealizuje, a nie sądzę, by ktoś miał (z ludzi którzy nie moją śmietnika na kompie) z 30 wpisów w autostarcie i HKCU/HKLM\Run, by było to aż takim obciążeniem przy starcie.