OSnews.PL

Debian GNU/Linux, Debian GNU/kFreeBSD i FreeBSD – porównanie wydajności

Michael Larabel z serwisu Phoronix przygotował porównanie wydajności Debiana z jądrami Linux oraz FreeBSD oraz z czystym FreeBSD.

Porównanie Debiana GNU/Linux z Debianem GNU/kFreeBSD Phoronix opublikował całkiem niedawno, w styczniu. Jednakże przez ostatnie pół roku wersja Debiana z jądrem FreeBSD znacznie dojrzała — domyślnie instalowaną wersją jądra jest 7.3 (w styczniu 7.2), można też zainstalować 8.0.

Autor porównania test przeprowadził na dwóch różnych notebookach — ThinkPadach R52 (z procesorem Intel Pentium M) oraz T61 (Intel Core 2 Duo T9300 „Penryn”), sprawdzone zostały kolejno: Debian GNU/kFreeBSD z jądrem 7.3 oraz 8.0 (oba optymalizowane pod i686, GCC 4.4.4, domyślny system plików), Debian GNU/Linux z jądrem 2.6.32 (GCC 4.4.4, domyślny system plików Ext3) oraz FreeBSD 7.3 i 8.0 (domyślny kompilator GCC 4.2.1, domyślny system plikow UFS2+S). Wszystkie systemy były 32-bitowe, ponieważ aktualny instalator Debiana GNU/kFreeBSD nie obsługuje wersji 64-bitowej.

Dla porządku należy przypomnieć, że Debian GNU/kFreeBSD wykorzystuje zestaw podstawowych narzędzi (toolchain) GNU i jądro FreeBSD, podczas gdy FreeBSD używa własnych narzędzi.

W skład testu weszły:

  1. Kompresja za pomocą 7-zip.

    Wyniki porównywalne, z lekkim wskazaniem na Debiany na nowszej maszynie

  2. Kompresja za pomocą Gzip (plik 2 GB).

    Przewaga Debianów, co ciekawe wśród czystych FreeBSD na starszej maszynie wyrażnie szybsze było wydanie 8.0, na nowszej — 7.3.

  3. Kompresja za pomocą LZMA (plik 256 MB).

    Na starszej maszynie Debian GNU/Linux wyraźnie wolniejszy, na nowszej wyniki porównywalne. W obu przypadkach najszybszy okazał się Debian z jądrem FreeBSD 8.0.

  4. Szyfrowanie pliku za pomocą GnuPG (plik 1 GB).

    Na starszym sprzęcie FreeBSD 8.0 wolniejszy od reszty systemów, które osiągnęły podobne wyniki. Na nowszym Debian GNU/Linux okazał się szybszy od konkurencji, tutaj również FreeBSD 8.0 wypadło najgorzej, choć różnica była mniejsza.

  5. Generowanie grafiki w POV-Ray.

    Na starszej maszynie Linux okazał się wolniejszy od systemów z jądrem FreeBSD, natomiast na nowszej — zdecydowanie szybszy. Debian z jądrem FreeBSD nieznacznie szybszy od czystego FreeBSD.

  6. Generowanie grafiki w C-Ray.

    Wszystkie Debiany nieznacznie wolniejsze od czystego FreeBSD.

  7. Łamanie hasła za pomocą John The Ripper.

    Porównywalne wyniki.

  8. Wywoływanie zdjęć za pomocą dcraw.

    Systemy z jądrem FreeBSD wyraźnie wolniejsze od Debian GNU/Linuksa.

  9. Porównanie sekwencji nukleotydów za pomocą MAFFT.

    FreeBSD 7.3 wyraźnie wolniejszy od 8.0, który z kolei okazał się wyraźnie wolniejszy od Debianów. Podobna tendencja wśród Debianów, choć tutaj róźnice były minimalne — Debian z jądrem FreeBSD 7.3 nieznacznie wolniejszy od tego z jądrem 8.0, który z kolei był nieznacznie wolniejszy od tego z jądrem linux.

  10. Zmiana rozmiarów zdjęc za pomocą GraphicsMagick.

    Na starszej maszynie Debiany osiągnęły identyczny wynik, nieznacznie lepszy od FreeBSD (również identyczny wynik). Na nowszej przewaga Linuksa, dalej Debiany z jądrem FreeBSD wyraźnie szybsze od czystego FreeBSD.

  11. Test BYTE Unix Benchmark.

    Na starszym sprzęcie wyniki porównywalne, na nowszym nieznaczna przewaga Linuksa.

  12. Automatyczne rozwiązywanie sudoku w Sudokut (tylko na Debianach).

    Debiany z jądrem FreeBSD nieco szybsze od tego z jądrem Linux.

  13. Dodanie 12 500 rekordów w SQLite (tylko na Debianach).

    Debian GNU/Linux wyraźnie szybszy od Debian GNU/kFreeBSD. Na nowszej maszynie wersja z jądrem 8.0 nieco szybsza od tej z 7.3.

  14. Test Himeno.

    Na starszym sprzęcie wszystkie Debiany osiągnęły podobny wynik, absolutnie deklasując czyste FreeBSD. Na nowszym różnice są mniejsze, ale z kolei Debian GNU/Linux okazał się lepszy od Debiana GNU/kFreeBSD.

  15. Operacje wejścia/wyjścia.

    Zwykły test wykonany za pomocą Threaded I/O Tester pokazał na starszym sprzęcie przewagę FreeBSD 8.0 nad Linuksem, który okazał się nieco lepszy od FreeBSD 7.3 oraz obydwu Debianów z jądrem FreeBSD, na nowszym — Debiany z jądrem FreeBSD uzyskały podobny wyni, lepszy od FreeBSD 8.0 i Debiana z jądrem Linux (również podobny wynik). Najgorzej wypadł FreeBSD 7.3.

    Ten sam test w trybie losowym pokazał znaczną przewagę Debiana z jądrem Linux — uzyskał ponad dwukrotnie lepszy wynik niż reszta systemów

Większość wyników była porównywalna, choć częściej ze wskazaniem na Debiana z jądrem Linux (ten system wg Phoronix wygrał), Debiana z jądrami FreeBSD bądź Debiana bez znaczenia na jądro. Zaledwie w kilku konkurencjach FreeBSD (lub Debian z jądrem FreeBSD) okazał się trochę lepszy od Debiana GNU/Linuksa.

Częściej również Debian GNU/Linux lub Debian GNU/kFreeBSD okazał się wyraźnie lepszy od czystego FreeBSD. Debian GNU/Linux częściej miał znaczną przewagę nad Debianem GNU/kFreeBSD. Czysty FreeBSD oraz Debian z jego jądrem tylko w jednym przypadku okazały się znacząco lepsze od Debiana GNU/Linux.

Pełne wyniki wraz z wykresami można obejrzeć na stronie serwisu Phoronix. Do przeprowadzania badania użyto oprogramowania Phoronix Test Suite.



PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo
  1. Awatar Tomasz Woźniak
    Tomasz Woźniak

    Może to poranek po sobocie, ale dla mnie informacje zawarte w treści silnie nieprzetrawialne. Chodzi mi o wnioski- nie można było tego napisać w kilku zdaniach? Nie każdemu chce się porównywać całość testu na Phoroniksie.

    Odpowiedz
    1. Awatar azhag
      azhag

      Hm, no spróbuję trochę to przeredagować…

      Odpowiedz
      1. Awatar azhag
        azhag

        Gotowe. Może być? Pewnie najlepiej by było wrzucić wykresy, ale myślę, że niecna kradzież i wstawianie 16 wykresów mija się z celem — trochę za dużo.

        Odpowiedz
        1. Awatar halish
          halish

          Miałeś podać _wnioski_. To znaczy wymień, jakie kategorie zostały przetestowane, ale na końcu podaj "najszybszy okazał się X" albo trudno wskazać jednoznacznego zwycięzcę. nie mam czasu czytać całości, a z chęcią bym się dowiedział:)

          Odpowiedz
        2. Awatar bLiNd
          bLiNd

          Albo chociaż pod każdym z testów zaznacz wyraźnie która wersja wygrała, bo tak to ciężko się połapać, szczególnie jeśli chodzi o FreeBSD.

          Odpowiedz
        3. Awatar konski_pytong
          konski_pytong

          Tu się nie da wskazać zwyciezcy, różne schedulery, różne konfiguracje jąder, różne kompilacje, systemy plików – widać, ze Debian podobnie jest wydajny z jadrem linux jak freebsd, mimo, ze jest optymalizowany pod linuksa. Konfiguracja standardowa FreeBSD jest nastawiona na bezpieczenstwo nie wydajność – wiec już samo założenie porównania jest bez sensu. To jak porównywać limuzyne do samochodu formuły 1 – co z tego ze to i to jeżdzi jak ma inne przeznaczenie. Test byłby ok jak by konfiguracje były identyczne, optymalizacje identyczne, i funkcje bezpieczenstwa identyczne… ale czy sie tak da?

          Odpowiedz
        4. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @konski_pytong: i tu się mylisz. Porównywać można i to właśnie zrobili. Wyciągać należy jednak sensowne wnioski. W twoim przykładzie samochodowym- jeśli okazało by się, że limuzyna ma zbliżone do f1 przyspieszenie 0-100, to co to oznacza? Ano to, że coś w F1 skopali.

          Wniosek twój jest zbliżony do tego co napisali autorzy testu- czyli ze FB ma inne założenia, więc totalnie nie rozumiem o co ci chodzi. Osobiście zdziwiła mnie przewaga Debiana/kFB nad FB i pozostanie dla mnie zagadką dlaczego widzisz jakąś optymalizację po Linuksa, skoro w testach zmiana jądra praktycznie jest niezauważalna.

          Test jak test- acha z opisu wychodzi, że Debian miał domyślne jądro Linuksa (i386), a Debian/kFB miał optymalizację dla i686. Może to niedopisanie, ale pewnie i tak niewiele by zmieniło.

          Nie wiem czemu od razu podpinasz ideologię.

          Odpowiedz
        5. Awatar azhag
          azhag

          > pozostanie dla mnie zagadką dlaczego widzisz jakąś optymalizację po Linuksa, skoro w
          > testach zmiana jądra praktycznie jest niezauważalna.

          A czasami wręcz się okazuje, że kFreeBSD jest wydajniejszy niż Linux.

          Ta rzekoma optymalizacja to oczywiście wymysł, pakiety dla kFreeBSD są kompilowane inaczej niźli dla Linuksa.

          Najśmieszniejsze zaś jest podnoszenie larum, że FreeBSD nie był optymalnie skonfigurowany, że stare lub testowe jądro, etc., jakby Debian GNU/* był skonfigurowany optymalnie i miał inne jądra. 🙂

          Odpowiedz
        6. Awatar krzabr
          krzabr

          Czyli w sensie wydajności debian k/freebsd jest już używalny ? 🙂

          Odpowiedz
        7. Awatar konski_pytong
          konski_pytong

          nie.

          Poza tym chyba jest różnica jaki scheduler ma w kompilowane jądro..
          Domyślne flagi FreeBSD, a flagi Debian/kFreeBSD są inne niż w artykule nie było, ze samemu kompilowali jadro i base system.. Domyśle innego schdeulera znajdziemy w FreeBSD, a innego w Debian/kFreeBSD itd.

          Odpowiedz
        8. Awatar krzabr
          krzabr

          Łe myślałem że można się przenosić .

          /etc w debianie k/freebsd jest debianowskie czy bsdowskie ?

          Odpowiedz
        9. Awatar konski_pytong
          konski_pytong

          Niestety debianowe, choć kilka plików dotyczących bezpośrednio jadra BSD znajdzie się już w /etc. Niestety ładu znanego z FreeBSD niema i raczej się nie zapowida, ba jest jeszcze wieksze zamieszanie, bo nie wiadomo co gdzie szukać, czy bedzie to w jendym pliku czy w 3.. a dokumentacji brak. Ot taka ciekawostka.

          Odpowiedz
        10. Awatar krzabr
          krzabr

          Tragedia a powoli zastanawiałem się nad migracją na tego egzotyka , ale niestety pakiety to istotna sprawa ale /etc jak dla mnie jest najistotniejsze .

          Odpowiedz
        11. Awatar bobycob
          bobycob

          Z tym ładem to zależy co kto lubi.
          Pamiętam, że 3bsd zakłada, że w /etc są ustawienia systemu /usr/share/etc programów a w /usr/local/etc (lub podobne ścieżki) programów zainstalowanych przez użytkownika. Ma to jakiś sens i milion lat temu w linuksie też tak bywało. Jednak dnia pewnego na drodze uzgodnień twórcy dystrybucji uznałi, że należy parę rzeczy inaczej uporządkować. Stwierdzili, że lepiej wszystkie ustawienia trzymać w jednym katalogu etc a nie trzech.

          Odpowiedz
        12. Awatar trasz
          trasz

          @bobycob: Nie ma /usr/share/etc. Rozdzial na /etc i /usr/local/cerb ma bardzo duzy sens – dzieki temu jest jasny podzial miedzy "rdzen systemu" i dodatkowe aplikacje. To jedna z tych rzeczy, ktorych w Linuksie brakuje, btw. 😉

          Odpowiedz
        13. Awatar konski_pytong
          konski_pytong

          TY chyba nie, wiesz o czym piszesz.. w freebsd samba ma jeden plik, a nie dziesięć.. nikt niczego nie dziali nie potrzebnie na małe pliczki. A porządek zwiazany z plikami jądra, systemu, oprogramowania w freebsd jest wzorcowy.

          Odpowiedz
        14. Awatar blinkkin
          blinkkin

          @trash: Tylko w przypadku dystrybucji Linuksa taki model się nie sprawdza. Po pierwsze apt/yum wrzuca zazwyczaj binarki do /usr/bin.

          Po drugie ciężko o rozróżnienie samego systemu (base) od programów – przecież nawet jądro jest pod kontrolą menadżera pakietów, podobnie GNU coreutils i tak dalej. Nie wspominając o tym, że userland jest zazwyczaj dosyć obszerny.

          Po trzecie większość linuksowych dystrybucji celuje obecnie w desktopy. Tacy użytkownicy zazwyczaj tworzą jedną dużą partycję. Zresztą chyba automaty podczas instalacji sugerują takie rozwiązanie?

          Podsumowując takie rozwiązanie nie ma większego sensu, jeśli chodzi o Linuksa. Natomiast systemy BSD to już inna bajka. Wiadomo co jest systemem, a co pochodzi z portów. Usunięcie lub zniknięcie /usr/local nie spowoduje większych konsekwencji (nie uszkodzi to samego systemu).

          Co ciekawe FreeBSD, NetBSD i OpenBSD różnią na tle tego, gdzie znajdziemy pliki konfiguracyjne. W przypadku OpenBSD programy wrzucają wszystko do /etc, FreeBSD do /usr/local/etc. Natomiast NetBSD wrzuca wszystko prócz skryptów rc.d do /usr/pkg/etc.

          Odpowiedz
        15. Awatar krzabr
          krzabr

          Dlatego juz dawien dawno pisalem ze OpenBSD ma idealnie stworzona konfiguracje i pliki konfiguracyjne . Dlatego kazdemu kto glebiej chce poznac dzialanie i konfiguracje unixow polecam ten system . Jeszcze do tego ich FAQ , po prostu bajka <3

          Ot wystarczy odhaszowac , choc w innych bsd tez jest grubo lepiej niz w linuxie i tworzenie smietnika pod pozorem "szturmu na desktop" mija sie z celem po prostu lenistwo i robienie na szybko przez programistow robia swoje .

          Odpowiedz
  2. Awatar Otaq
    Otaq

    Strasznie zagmatwany jest opis uzyskanych wyników. Myślę, że dużo czytelniej by było gdyby wypisać kilka najważniejszych punktów zamiast lity tekst 🙂

    Odpowiedz
  3. Awatar oO
    oO

    Teraz czekamy na komentarz tr*sza jak to test został zakłamany albo rezultaty były wynikiem ingerencji UFO. Trzeba w końcu nagiąć fakty do ustalonej teorii.

    Odpowiedz
    1. Awatar t_error
      t_error

      Tekst byłby zakłamany gdyby dotyczył porównania z Windowsem. Nie dotyczy więc jest nieistotny dla działu propagandy szeptanej (za komentowanie nieistotnych tekstów nie płacą).

      Odpowiedz
    2. Awatar azhag
      azhag

      Już Phoronix broni (ważne: rozsądnie!) FreeBSD:

      This though is not to say that FreeBSD is a loser in terms of computing performance against Linux, but FreeBSD did possess a stronger advantage with tests like C-Ray and some I/O operations. FreeBSD and the other *BSDs also have their own set of features and focus that distinguish them from Linux in other ways besides the quantitative performance.

      Odpowiedz
    3. Awatar bobycob
      bobycob

      usłyszymy coś w stylu:
      "ale i tak wszystkie te systemy są niczym przy MacOSX i SunSolaris/OpenSolaris, a testu porównawczego nie robiony aby nie zawstydzić przeciwników."

      Odpowiedz
    4. Awatar jasnieoswiecony
      jasnieoswiecony

      Czy kogokolwiek o zdrowych zmyslach interesuja te i jakiekolwiek porownania wydajnosci? To strata czasu. Swietnie, system a jest szybszy od systemu b o 0.00000000000000001 milisekundy w rozwiazywaniu sudoku, to ze wywalil sie zaraz po wykonaniu obliczen to inna sprawa. Pic na wode.

      Odpowiedz
      1. Awatar bobycob
        bobycob

        Gdybyś miał rację nikt nie robiłby benchmarków. O ile porównanie różnych systemów ma taki sobie sens, to porównanie jednego systemu, ale z różnymi kernelami jest ciekawe.

        Odpowiedz
        1. Awatar jasnieoswiecony
          jasnieoswiecony

          "Kupa jest dobra – miliony much nie moga sie mylic":P
          Poczytaj sobie o benchmarkach linux z BFS.

          Odpowiedz
        2. Awatar bobycob
          bobycob

          a może jaśnie oświecony raczy się podzielić wiedzą

          Odpowiedz
        3. Awatar krzabr
          krzabr

          BFS jest faktycznie szybki shelderem , ale nikt nie zgodził się na wsadzenie go jako domyślny shelder w linuxie .

          Mam nadzieje że go chociaż użyją w innym systemie 🙂

          Odpowiedz
        4. Awatar putrycy
          putrycy

          a co to jest shelder ?

          Odpowiedz
        5. Awatar krzabr
          krzabr

          Shelder to taki program na poziomie jądra który szereguje ci procesy , nadaje im priorytety , wyklucza konflikty między nimi , a czasem nawet może przydzielać im zasoby .

          Odpowiedz
        6. Awatar Reddie
          Reddie

          A nie scheduler?

          Odpowiedz
        7. Awatar krzabr
          krzabr

          Tak literowka xD

          Odpowiedz
    5. Awatar blinkkin
      blinkkin

      @oO: Mnie te rezultaty nie zdziwiły. Phoronix zrobiło porównanie FreeBSD i Ubuntu już ponad rok temu.

      Co więcej uważam, że Debian powinien mieć większą przewagę. FreeBSD korzysta z 3 letniej wersji GCC, w przypadku oprogramowania to przepaść. Z jakiego powodu używana jest wersja GCC 4.2.1, chyba nie muszę tłumaczyć.

      Odpowiedz
      1. Awatar krzabr
        krzabr

        To ciekawe jak wydajność skoczy do przodu po ulepszeniu i dojrzeniu clanga .

        Odpowiedz
    6. Awatar trasz
      trasz

      @oO: Autorzy benchmarkow Phoronixa nie maja pojecia o tym, co mierza (wiekszosc ich "benchmarkow" porownuje optymalizacje robione przez kompilator, a nie wydajnosc systemu operacyjnego), w dodatku robiac to zle (nie wiadomo, ile wlasciwie robia testow, jakie jest standardowe odchylenie i jaki jest w zwiazku z tym blad pomiaru). Poza tym wslawili sie "benchmarkami", ktore tak naprawde nie mierza nic, jak na przyklad "Threaded I/O tester", ktory w rzeczywistosci nie robi zadnego dyskowego I/O. Wiec tak naprawde nie ma czego komentowac – ot, linuksiarska wersja Faktu (gazety).

      Odpowiedz
      1. Awatar Reddie
        Reddie

        Edek: to, że na domyślnej konfiguracji jeden system jest skompilowany z innymi optymalizacjami niż inny jak najbardziej mieści się w wydajności _systemu_.

        Odpowiedz
        1. Awatar trasz
          trasz

          Nie chodzi o optymalizacje systemu, tylko samych benchmarkow.

          Odpowiedz
  4. Awatar azhag
    azhag

    Ups, wpadka.

    Na początku napisałem, że (Debian GNU/k)FreeBSD częściej był wyraźnie lepszy od Debiana z Linuksem — to nieprawda, pomerdały mi się dane kiedy więcej to lepiej, a kiedy gorzej.

    Wybaczcie.

    Odpowiedz
  5. Awatar konski_pytong
    konski_pytong

    LOL na jednym laptopie wygrywa FreeBSD, a na drugim Linux i tak na zamianę, co to za metodologia testowania? Ze w operacjach graficznych FreeBSD powinno być w plecy to norma.. ale jaja z LZMA, POV-Ray, czy Himeno Benchmark, I/O Test to przegięcie skoro czasem Pentium M jest szybszy od Penryna – chyba ktoś zapomniał skompilować z odpowiednimi flagami, lub bez nich.

    Odpowiedz
    1. Awatar konski_pytong
      konski_pytong

      już pomine ZFS, i to że wybrali 2 wersje FreeBSD, jedna z testowym schedulerem druga z starym – zamiast sięgnąć bo FreeBSD Stable po wydnaiu 8.0..

      Odpowiedz
      1. Awatar krzabr
        krzabr

        ZFS z tego co zauważyłem jest wolniejszy w zapisie / odczycie / kopiowaniu od UFS2 .

        Odpowiedz
        1. Awatar konski_pytong
          konski_pytong

          Racja w standardowej konfiguracji i z wszystkimi opcjami zabezpieczeń. Niemniej można przecie zrobić testna szybkość wykonywania snapshotów – gwarantuje, że w FreeBSD będą przeprowadzane najszybciej. Zresztą jeśli chodzi o burst rate to FreeBSD bije na głowę Linux, jednak kupę pasma "marnuje" na zabiegi związane z bezpieczeństwem.

          Odpowiedz
        2. Awatar blinkkin
          blinkkin

          @krzabr: Jeśli chodzi o pojedynczy dysk i "zimny" zapis/odczyt, to rzeczywiście lepiej sprawdza się stary UFS2. Jednak należy pamiętać, że nie w takim celu został stworzony ZFS.

          Po pierwsze ZFS to nie tylko system plików, ale także menadżer woluminów logicznych. Robi to ogromną różnicę w przypadku RAIDów o dużej objętości – ZFS ma pojęcie o logicznej strukturze macierzy.

          Sekundo ZFS posiada możliwość cachowania (za ten zwrot przepraszam purystów językowych) zapisu/odczytu np. na szybkich dyskach SSD. Podobnej funkcjonalności niedawno dorobiło się DragonFly BSD i system plików HAMMER w postaci swapcache. Różnice w wydajności z włączonym i wyłączonym swapcachem były spore (nie chce mi się szukać odnośnika do porównania).

          Podsumowując ZFS nie zostało stworzone z myślą o komputerach domowych.

          Odpowiedz
        3. Awatar bobycob
          bobycob

          Czym takie "cachowanie" (kaszowanie?:D) różni się od standardowego w linuksie?
          Pamiętam kiedyś przeszukiwałem CD pod kąŧem określonego łańcucha, później drugie przy drugim wyszukiwaniu cd nie było już używane. Przeszukiwanie zostało błyskawicznie wykonane z pamięci kaszy 😉

          Odpowiedz
        4. Awatar jak
          jak

          Cachowanie w ZFS z wykorzystaniem SSD poprawia czas dostępu do macierzy/dysku. Operacje zapisu sa wykonywane w pierwszej kolejnosci na dysku SSD (czas dostępu rzędu 1ms) a następnie dane sa w wolnych cyklach IO przesyłane na macierz.
          Zwiększa to radykalnie ilość możliwych operacji zapisu w jedn. czasu – TPS. Natomiast poprawa przy ciągłym zapisie/odczycie dużych porcji danych jest niewielka.

          Odpowiedz
        5. Awatar trasz
          trasz

          @bobycob: Zastosowaniem. Blinkkinowi chodzi o cache devices, czyli szybki dysk (solid-state, na przyklad, tzn. takie cos z DIMM-ami w srodku podpinane przez SATA), ale stosunkowo maly (ze wzgledow ekonomicznych) dysk, na ktorym ZFS trzyma sobie najczesciej odczytywane dane. Cache’owanie w pamieci to osobny mechanizm.

          Odpowiedz
        6. Awatar bobycob
          bobycob

          a widzisz teraz rozumiem – niektórym trzeba jak krowie na rowie 😉

          Odpowiedz
        7. Awatar krzabr
          krzabr

          @Blink : No właśnie dlatego przydatne by było wdrążenie do freebsd nowego szybkiego konwencjonalnego systemu plików bądz znaczne przyśpieszenie UFS2 , ot dla komputerów domowych i embeed .

          Odpowiedz
        8. Awatar trasz
          trasz

          @krzabr: W tym, co jest istotne, UFS2 nie jest wolniejszy od filesystemow dostepnych pod Linuksem. Oczywiscie zakladajac, ze uzywasz SUJ-a albo wlaczysz tryb async, tak jak w Linuksie.

          Odpowiedz
        9. Awatar krzabr
          krzabr

          Owszem jest dosc szybki , ale widac ze i ext4 i ntfs ostatnio przyspieszyly .

          async – jeszcze nie stosowalem , ale jesli mowisz ze to pomaga z szybkoscia to chetnie go sprawdze .

          Odpowiedz
    2. Awatar Tomasz Woźniak
      Tomasz Woźniak

      @konski_pytong: rozumiem, że ponownie wynik testów nie po myśli- ach ta rzeczywistość…

      Czepię się tylko jednej rzeczy:

      LOL na jednym laptopie wygrywa FreeBSD, a na drugim Linux i tak na zamianę, co to za metodologia testowania?

      Może to i śmieszne, ale jeden laptop ma jeden rdzeń a drugi dwa. Może to jeden z powodów? Może jeszcze to, że jeden jest na ATI a drugi na Nvidi?
      Zupełnie nie rozumiem co cię rozbawiło, ale nie musisz wyjaśniać- wcale mnie to nie interesuje.

      Odpowiedz
      1. Awatar azhag
        azhag

        > Może to i śmieszne, ale jeden laptop ma jeden rdzeń a drugi dwa.

        Dwa rdzenie?! OMG, LOL, ROTFL, SEPUKU!

        😉

        Odpowiedz
        1. Awatar maniac
          maniac

          Ale Core 2 Duo ma dwa rdzenie.

          Odpowiedz
        2. Awatar azhag
          azhag

          O szlachetna sztuko ironii, gdzieżeś ty, gdzieżeś?

          Odpowiedz
      2. Awatar konski_pytong
        konski_pytong

        Panie Wożniak OSpudelkowy specjalisto T9300 ma 4 rdzenie ;] I jak były testy schedulera (jednego i drugiego) z FreeBSD oraz Linuksa, to Linux w SMP zawsze wypadał gorzej.

        Odpowiedz
        1. Awatar Arghil
          Arghil

          pewnie pod FB ma 4 (2 dodatkowe za os), ale pod Debianem tylko 2;)

          Na specyfikacji>/a> Intela ma tylko 2. Czterordzeniowe procesory mają oznaczenie Q9000/Q9100.

          Odpowiedz
        2. Awatar Reddie
          Reddie

          http://ark.intel.com/Product.aspx?id=33917

          Odpowiedz
        3. Awatar konski_pytong
          konski_pytong

          http://www.entity.cc/ICONS/free-emoticons.htm

          Odpowiedz
        4. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @konski_pytong: proszę cię, wiem że bycie fanbojem wymaga poświęceń, ale nie zwalnia od myślenia. Jak masz napisać bzdurę, to nie pisz. Jak nie wiesz czym się różni Hyper Thread od rdzenia, to doczytaj nie racz ludzi swoimi przemyśleniami, bo ośmieszasz stajnię BSD.

          Swoją droga przypominasz mi najka… czyżby kolejne wcielenie?

          Odpowiedz
        5. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @konski_pytong: przepraszam ten procek nie ma HT. Powinienem jednak sprawdzić skąd znalazłeś w nim 4 rdzenie, ale błędnie jak wdać uznałem, że zwyczajnie pomyliłeś się a nie świadomie napisałeś bzdurę.

          Przepraszam- następnym razem założę, że fanbojizm jest u ciebie dominującą nad myśleniem cechą, podczas komentowania tematów drażliwych.

          Odpowiedz
        6. Awatar konski_pytong
          konski_pytong

          Jesteś idiota, czy czytać nie potrafisz?
          :] = ironia
          azhag szukał ironii to mu ją dałem..

          Odpowiedz
        7. Awatar Tomasz Woźniak
          Tomasz Woźniak

          @konski_pytong: ironia subtelna jak u Palikota- i ten szanujący oponenta w dyskusji język- nic dodać nic ująć. Miszczu pełną parą- aleś nam pokazał…

          PS.
          Nauczka na przyszłość- nie podejmować z Tobą polemiki.

          Odpowiedz
        8. Awatar jolsky
          jolsky

          A jakiej polemiki oczekiwałeś z gościem, który ma kompleks małego ptaszka?

          Odpowiedz
        9. Awatar konski_pytong
          konski_pytong

          oj żebyś tylko ty miał taki "kompleks"

          Odpowiedz
        10. Awatar bobycob
          bobycob

          nie życz bliźniemu co tobie nie miłe 😀

          Odpowiedz
  6. Awatar krzy3
    krzy3

    Ludzie z Phoronixa po raz kolejny udowodnili że nie mają pojęcia o mierzeniu czegokolwiek.

    Po pierwsze — co mają na celu testy z POVRayem czy GNUPG? Przecież tutaj wydajność nie zależy od jądra, bo praktycznie cały program wykonywany jest w userlandzie. Jeśli wychodzi różnica, to raczej wskazuje na to, że test jest źle zaprojektowany.

    Po drugie — test z GCryptem: wyniki na poziomie milisekund z dużymi różnicami. Znowuż, wydajność szyfrowania nie zależy od OS, tylko od procesora. Milisekundowe różnice w wynikach można np. wytłumaczyć tym, że szybsze w tym przypadku FreeBSD ma po prostu szybszy linker dynamiczny. No, tylko trzeba by było jeszcze wiedzieć co to jest linker i jak działa.

    Analizy błędów wybitni ekspoerci nie zrobili, bo i po co. Przecież oni dobrze wiedzą, że test jako taki się nigdy nie rozjeżdża.

    Jedyne co w tym teście się broni, to są syntetyczne benchmarki wydajności I/O — faktycznie wychodzi z nich w spójny sposób że Linuks jest szybszy. Natomiast cała reszta to jest po prostu lipa.

    Odpowiedz
    1. Awatar Reddie
      Reddie

      @krzy3: to nie był benchmark jąder, tylko systemów. Dlaczego uważasz, że mierzenie różnic na poziomie userlandu czy linkera to "lipa"?

      Odpowiedz
      1. Awatar trasz
        trasz

        Lipą jest "mierzenie" czegos, co w praktycznych zastosowaniach nie ma znaczenia. Predkosc rtld w praktyce istotna nie jest. Tego, co dla rzeczywistej wydajnosci ma znaczenie, Phoronix nie mierzy, bo trudniej.

        Odpowiedz
      2. Awatar krzy3
        krzy3

        Ponieważ program szyfrujący działa tak:

        while((blok = read(…)) {
        zaszyfrowany_blok = szyfruj(blok);
        write(zaszyfrowany_blok)
        }

        Za – powiedzmy – 99% czasu wykonania programu odpowiada funkcja szyfruj(). Wydajność systemu ma wpływ tylko i wyłącznie na czas wykonywania funkcji read() i write() — które wpływają na 1% wyniku końcowego. Zatem, na dwóch różnych systemach test powinien dawać te same wyniki z dokładnością do 1%. Phoronixowi wychodzą w takich sytuacjach bardzo różne wyniki, co oznacza, że czas wykonywania funkcji szyfruj() jest różny. W tym momencie każdemu rozsądnemu człowiekowi zapala się czerwone światło, bo widzi, że w eksperymencie jest jakaś zmienna która jest poza jego kontrolą. Przyjmijmy najprostsze wytłumaczenie że winny jest kompilator który inaczej optymalizuje w obydwu systemach.

        Teraz: skoro kompilator działa inaczej na obydwu systemach, to oznacza de facto tyle, że na obu uruchomiliśmy INNY benchmark — ergo wyniki nie są porównywalne! Bo nie można w każdym przypadku ustalić, czy różnica wydajności która wychodzi w teście jest winą jądra czy kompilatora. To co należałoby zrobić, to np. zamienić kompilatory między systemami i jeszcze raz porównać wyniki.

        W teście jest parę innych absurdów, np. gorszy wynik na szybszym procesorze.

        Co do linkera — wydajność linkera oczywiście można mierzyć i może to być nawet przydatne. Problem w tym, że należy zaprojektować test mierzący wydajność linkera. To co zrobił Phoronix, to test prędkości szyfrowania, który skutkiem nieudolnego zaprojektowania w rzeczywistości mierzy nie wydajność szyfrowania, tylko linkera. Przy czym znowu, wcale nie wiadomo czy winny jest akurat linker, czy może fukcja mmap(), czy może mechanizm zarządzania pamięcią wirtualną. Wiadomo tylko, że "coś" wnosi błąd pomiarowy na poziomie wartości mierzonej! Ja _podejrzewam_ że jest to linker, ale pewności żadnej nie mam.

        Reasumując — twórca tego testu za moich czasów wyleciałby ze studiów na pierwszym roku na pracowni fizycznej, najpóźniej na drugim na miernictwie.

        Odpowiedz
        1. Awatar Reddie
          Reddie

          @krzy3: odpowiem zbiorczo tobie i Edkowi.

          Benchmark, o ile mi wiadomo, ma mierzyć prędkość, z jaką benchmarkowane urządzenie/program/system/kernel wykonuje daną czynność. Jeśli na systemie A domyślne flagi kompilacji to i386 a na systemie B i686, to takie np. szyfrowanie będzie działało szybciej na systemie B. Oczywiście możliwe, że system B jest na tyle kijowy, iż różnica i tak będzie na korzyść systemu A – benchmark również to pokaże! Ogólnie, w temacie tego kompilowania benchmarków: nie ma kompletnie znaczenia, że są skompilowane z różnymi optymalizacjami, bo domyślne flagi również wpływają na wydajność _systemu_. Podobnie nie ma znaczenia to, że gdzieś jest starszy kompilator i można łatwo przekompilować cały system nowym – testujemy domyślną wydajność, period. Jak FreeBSD dorobi się clanga to Edek będzie pisał to samo 😉

          Oczywiście to o czym piszę nie wyklucza błędów na poziomie kodu benchmarka, które – jeśli mają miejsce – istotnie taki benchmark eliminują.

          Odpowiedz
        2. Awatar trasz
          trasz

          @Reddie: Ktorego slowa w "pomiary robione przez Phoronixa nijak sie maja do rzeczywistej wydajnosci mierzonej benchmarkami aplikacyjnymi" nie rozumiesz? Ok, wyjasnienie autorstwa krzy3 jest troche dlugie i wymaga minium wiedzy na temat teorii pomiarow i zasady dzialania komputerow, ale powyzsze zdanie powinno byc dosyc zrozumiale.

          Odpowiedz
        3. Awatar krzabr
          krzabr

          Mnie i tak zdziwiło że freebsd wypadło porównywalnie , spodziewałem się znacznie gorszych wyników a w przypadku debiana k/freebsd tragicznej wydajności więc nie jest aż tak źle .

          Odpowiedz
        4. Awatar Reddie
          Reddie

          @Edek: którego słowa w "pomiary robione przez Phoroniksa mają mierzyć wydajność systemu na domyślnej konfiguracji" nie rozumiesz?

          Odpowiedz
        5. Awatar konski_pytong
          konski_pytong

          Nie bo to nie logiczne. Robimy test "desktopowy", a w szramki stają system desktopowy i system strikte serwerowy. Przecie nie trzeba tu nic testować, by znać odpowiedz co będzie szybsze. To jakby organizować wyścigi F1 i 4×4 na jednym torze..

          Odpowiedz
        6. Awatar krzy3
          krzy3

          > Benchmark, o ile mi wiadomo, ma mierzyć prędkość, z jaką benchmarkowane urządzenie/program/system/kernel wykonuje daną czynność.

          Termometr który masz za oknem nie mierzy temperatury powietrza, tylko własną. Cała sztuka polega na tym, aby z jego wskazania móc wnioskować o temperaturze powietrza. Bo to jest akurat dla nas interesujące.

          Podobnie benchmark mierzy prędkość wykonywania benchmarku. Cała sztuka polega na tym by tak zaprojektować testy, aby prędkość wykonywania benchmarku była w sensowny sposób związana z prędkością wykonywania zadać rzeczywistych. Jeśli chcemy mierzyć wydajność szyfrowania, to wynik nie powinien zależeć od rodzaju używanego linkera. Jeśli zależy, to znaczy, że albo w systemie coś jest fundamentalnie poknocone, albo że test jest zły. Ponieważ żadnego nie wyeliminowano, z doświadczenia obstawiam to drugie.

          Niezgodności wyników które są w teście jednoznacznie wskazują na to, że benchmark Phoronixa nie mierzy nic poza czasem wykonywania benchmarku Phoronixa. Ergo wnioskowanie na jego podstawie o wydajności systemu w zastosowaniach rzeczywistych jest niemożliwe.

          Odpowiedz
        7. Awatar krzy3
          krzy3

          Addendum:

          Jeśli chodzi o wpływ kompilatora, to w takich zastosowaniach jak szyfrowanie oczywiście ma on znaczenie i test powinien go uwzględniać. Ale Phoronix zrobił 2 testy na szyfrowanie: jeden GNUPG, a drugi GCryptem — i dostal rozbieżne wyniki. Kompilator był ten sam, więc należy uznać, że jeden z testów był wadliwy. Obstawiam, że wadliwy był test z GCryptem i w rzeczywsitości mierzył wydajność linkera.

          P.S. Jak widzę wyniki testu z GCryptem zostały już ze strony skasowane. Hehehe.

          Odpowiedz
        8. Awatar Reddie
          Reddie

          @konski_pytong: Debian desktopowy? Toś przywalił…

          @krzy3: Dziękuję za rzeczową odpowiedź. Jak dla mnie temat wyczerpany 🙂

          Odpowiedz
        9. Awatar konski_pytong
          konski_pytong

          To porównaj prace planisty w dowolnym linuksie a w freebsd, oraz ilość softu strikte desktopowego.

          Odpowiedz
        10. Awatar krzabr
          krzabr

          Debian i FreeBSD maja zblizona liczbe domyslnych paczek , zblizone zastosowania oraz targety , jedyny plus to moze to ze debian moze domyslnie zainstalowac srodowisko graficzne z poziomu graficznego , w fbsd trzba troche pogrzebac zeby to zrobic .

          Wiec imo testy i porownania obu systemow maja sens , no chyba ze ktos mi wyskoczy ze targetem fbsd nie sa serwery ? TO w takim razie co ? Skoro embeed jest w powijakach , rt ten system nigdy nie byl , a na desktop trzeba szukac innego distra .

          Odpowiedz
        11. Awatar trasz
          trasz

          @krzabr: Embedded. Serio. Embedded FreeBSD napedza cala mase sprzetu, od wiekszosci routerow szkieletowych (Juniper), przez duza czesc enterprise'owych NAS-ow (NetApp, Isilon), roznych IDS-ow, IPS-ow i EPS-ow (NETASQ, Niksun, Packet Forensics). Nawet Silicon Graphics sprzedaje sprzet chodzacy na pochodnej FreeBSD do serwowania storage'u swoim linuksowym klastrom.

          To oczywiscie "duze" embedded. "Małe" embedded we FreeBSD zrobilo w ciagu ostatniego roku ogromne postepy (w pelni funkcjonalne sa porty na MIPS, MIPS64, ARM oraz PowerPC/PowerPC 64), ale niespecjalnie jest jeszcze kojarzone przez potencjalnych klientow.

          Odpowiedz
        12. Awatar Reddie
          Reddie

          @Edek: to, co wymieniłeś, jest napędzane nie FreeBSD a zamkniętymi forkami FreeBSD.

          Odpowiedz
        13. Awatar trasz
          trasz

          @Reddie: Bez znaczenia – to, co jest z Linuksa w embedded, to tez zwykle jakies przyciete na miare forki, a nie waniliowy kernel.

          Odpowiedz
        14. Awatar masterx
          masterx

          @krzy3: "Reasumując — twórca tego testu za moich czasów wyleciałby ze studiów na pierwszym roku na pracowni fizycznej, najpóźniej na drugim na miernictwie."

          Uważaj, żebyś nie zdeżył się z samolotem, nosząc głowę wysoko w chmurach. Mało kogo interesują Twoje nudnawe informatyczne studia.

          Odpowiedz
        15. Awatar el.pescado
          el.pescado

          Tfu, elyty, tfu!

          Odpowiedz
        16. Awatar krzabr
          krzabr

          Widac tam embeeded nabiera nowego znaczenia 😀

          Na maly embeed podzial od lat jest niezmienny – Systemy RT , Systemy Wbudowane na Forkach Linuxa i NetBSD .

          Reddie – Jest tez mnostwo malych urzadzen napedzanych forkami linuxa , tak odleglymi od glownej galezi ze maja osobne , api , scheldery a kompilowane sa przez zupelnie dziwaczne kompilatory C

          Odpowiedz
        17. Awatar Reddie
          Reddie

          @krzabr: no i co z tego?

          Odpowiedz
        18. Awatar krzabr
          krzabr

          To że przypieprzasz się do zamkniętych forków Fbsd , a w linuxie embeeded powstają podobne twory . Ot np dynamicznie ładowane zamknięte moduły do jądra . Tylko inaczej się to nazywa , ale strategia działania niemalże identyczna .

          Odpowiedz
        19. Awatar Reddie
          Reddie

          @krzabr: ale co z tego że powstają? Czy ja podaję je jako argument na to, że embedded jest targetem Linuksa albo że Linux jest na tym odcinku intensywnie rozwijany? Bo Edek podaje.

          Nawet argument „u was biją murzynów” trzeba umieć stosować.

          Odpowiedz
        20. Awatar krzabr
          krzabr

          Reddie 29 lipca 2010 o godz. 0:32 #

          @Edek: to, co wymieniłeś, jest napędzane nie FreeBSD a zamkniętymi forkami FreeBSD.

          Reddie 30 lipca 2010 o godz. 16:45 #

          @krzabr: ale co z tego że powstają? Czy ja podaję je jako argument na to, że embedded jest targetem Linuksa albo że Linux jest na tym odcinku intensywnie rozwijany? Bo Edek podaje.

          Nawet argument “u was biją murzynów” trzeba umieć stosować.

          Czasem czytaj co sam piszesz

          Odpowiedz
        21. Awatar Reddie
          Reddie

          @krzabr: czytaj ze zrozumieniem, zawsze.

          Odpowiedz
        22. Awatar krzabr
          krzabr

          źdatyzc mejmó ejN

          Ein Reich ! Ein Volk ! Ein Gnu !
          Hejl Stallmann ! Hajlł Konkin !

          Odpowiedz
  7. Awatar el.pescado
    el.pescado

    O benchmarkach serwisu Phoronix

    Odpowiedz
    1. Awatar krzy3
      krzy3

      Zakładając, że komputer zasadniczo działa deterministycznie, to brak słupków błędów nie jest znowu aż takim strasznym błędem, bo można uznać że powinny być na poziomie rozdzielczości zegara (aczkolwiek przyzwoitość nakazywałaby sprawdzić).

      Główny problem z Phoronixem polega na tym, że oni nie wiedzą co tak naprawdę mierzą.

      Odpowiedz
  8. Awatar krzabr
    krzabr

    @Trasz : Po co freebsd wspiera achitekture pc98 ? Jest jakiś człowiek który uparcie robi na nią buildy czy jak ?

    Odpowiedz
    1. Awatar trasz
      trasz

      @krzabr: Doskonale pytanie. Nie mam pojecia.

      Odpowiedz
      1. Awatar krzabr
        krzabr

        Ja też nie mam pomysłu , wydaje mi to się zwykłym mało rozpowszechnionym złomem w sam raz dla NetBSD i ContikiOS .

        Jeśli się dowiesz kto i dlaczego robi ten port napisz mi na fb , chętnie poczytam 🙂

        Odpowiedz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *


media społecznościowe

ostatnie artykuły

Popularne tagi

android apple bezpieczeństwo biznes google hardware internet iphone kaspersky media microsoft mobile open-source press-release programowanie software UNIX windows Wydania Wydarzenia

Kategorie