# [OT] 64 bit, czy to napewno obsługiwane ?

## Yatmai

Oglądam oferty handlowe, świetnie się czyta, przykładowy Core Duo - 64 bit, 2 rdzenie, każdy po prawie 3Ghz, a na początku przyszłego roku ma wyjść wersja z 4 rdzeniami.... Wszystko pięknie, ładnie, tylko czy to napewno jest wykorzystywane ? Dwu rdzeniowość jestem pewien, że nawet na Linuksowym desktopie nie będzie w 100% wykorzystana, a na takim Xp/Vista to wogóle marnotrastwo mocy.

64bit... no przecież jeszcze nie ma Windziaka64Bit więc kolejne marnotrastwo i chwyt marketingowy, ale Linux ? Są w końcu Linuchy 64bit, samo Gentoo można też na tę architekturę skompilować. Pytanie tylko czy daje to takiego kopa jak reklamują media, czy tylko w pewnych warunkach, czy wogóle to pic na wode ?  :Very Happy: 

----------

## sir KAT

Generalnie kopa daje, ale w pewnych warunkach większego w innych mniejszego zależy od typu aplikacji. Instalowałem na kilku serwerach 64 bitowych (dwu procesorowych na dodatek) Gentoo i działało wyśmienicie. Jak będę kupował nowego desktopa dla siebie to też będzie to 64 bit. Generalnie taki jest kierunek rozwoju i nie ma co się oglądać na Windows, który jak zawsze jest 100 lat za pingwinami  :Wink: 

PS

Nie mogę teraz sobie przypomnieć ale gdzieś można wygooglać benchmarki Gentoo na 32 bitach z Gentoo na 64 bitach.

----------

## manwe_

Windows 64bit jest [XP i Vista], ale cóż z tego, jak większość oprogramowania i tak jest jeszcze x86. 

Natomiast co do Gentoo - sam używam [AMD Turion MT-32 1.8GHz] i działa szybciej [nic nie pobije kompilowania pod architekturę], ciężko mi powiedzieć dokładnie co i o ile, głównie opieram to na odczuciu pracy, ale jeżeli chcesz mogę jakieś konkretne benchmarki w porównaniu z AthlonemXP 1.8GHz przeprowadzić.

----------

## Yatmai

W sumie aż tak dokładnych nie potrzebuje, ale np byłbym wdzięczny za porównanie czasów kompilacji powiedzmy mplayer'a. Bo w sumie tylko to się liczy poza ogólnym odczuciem szybkości działania na codzień, co jak widze jest nad wyraz pozytywne  :Smile: 

----------

## manwe_

Hm, tak przeglądam historię, kompilacje ku mojemu zdziwieniu jednak trwają mniej/więcej tyle samo czasu, z ciekawości sprawdziłem mplayer'a teraz:

Turion: 

 *Quote:*   

>      Sun Jul 23 18:59:19 2006 >>> media-video/mplayer-1.0_pre8-r1
> 
>        merge time: 8 minutes and 31 seconds.

 

XP: 

 *Quote:*   

>      Sun Jul 23 19:02:41 2006 >>> media-video/mplayer-1.0_pre8
> 
>        merge time: 7 minutes and 43 seconds.

 

Przy czym na tym pierwszym pracowałem, więc spokojnie minutę można mu odjąć. 

Co dziwne niektóre pakiety kompilują się na 64bitach nawet dłużej. Przykład dla kdelibs:

Turion:

 *Quote:*   

>      Mon Jun 19 23:13:43 2006 >>> kde-base/kdelibs-3.5.3
> 
>        merge time: 1 hour, 9 minutes and 47 seconds.
> 
>      Tue Jun 27 02:55:54 2006 >>> kde-base/kdelibs-3.5.3-r3
> ...

 

XP:

 *Quote:*   

>      Wed Feb  1 19:48:33 2006 >>> kde-base/kdelibs-3.4.3-r1
> 
>        merge time: 37 minutes and 43 seconds.
> 
>      Wed Mar  1 11:37:42 2006 >>> kde-base/kdelibs-3.5.1-r1
> ...

 

Może to wina flag [ CFLAGS="-O2 -pipe -msse3 -march=k8" vs. CFLAGS="-O3 -march=athlon-xp -pipe" ], a może czegoś innego. Nie wiem.

----------

## mbar

Czas kompilacji programu to akurat nie jest dobry benchmark. Testujesz tylko sprawność samego kompilatora gcc, który w 64-bitach ma więcej do zrobienia  :Wink:  Nie wiem, co dokładnie jest tego przyczyną, ale np. glibc 2.4 pod AMD64 (2,5 GHz San Diego) kompiluje się u mnie zauważalnie dłużej, niż 32-bitowy glibc 2.4 na procesorze pentium-m 1,5 GHz. Ale sam system po skompilowaniu działa na A64 znacznie lepiej.

----------

## manwe_

A może to kwestia tego, że gcc potrzebuje więcej czasu procesora na optymalizację programów pod arch. 64bitową. Odpowiedź na to już chyba tylko programiści gnu znają.

----------

## Yatmai

 *manwe_ wrote:*   

> 
> 
>  *Quote:*        Sun Jul 23 18:59:19 2006 >>> media-video/mplayer-1.0_pre8-r1
> 
>        merge time: 8 minutes and 31 seconds. 
> ...

 

 *Quote:*   

> Czas kompilacji programu to akurat nie jest dobry benchmark. 

 

No faktycznie, bo na moim Celeronie 866 (sprawdzałem jaka będzie zmiana po podkręceniu to kojażę  :Very Happy: ) trwało to jakieś 4'12s  :Very Happy: 

Ale w sumie cieszy mnie to, że ogólnie sys działa szybciej, choćby dlatego, że taki Semp64 jest tańszy od swego 32bit'owego brata  :Very Happy: 

A tak aktualizując sobie jeszcze baze danych (czyt. resztki rozumku  :Very Happy: ) kiedyś czytałem, że arch. 64Bit powoduje "drobne" problemy, głównie z tego co pamiętam z flashem i javą. Poprawiło się coś w tym względzie ?  :Smile: 

----------

## mbar

Z firefox-bit (32-bit w systemie 64-bit) nie ma problemu. Osobiście używam jednak kompilacji ff 64-bitowej, flash nie chodzi, ale z javą problemów nie uświadczyłem.

----------

## manwe_

Różne "problemy" powoduje. 

1. Flash tylko na 32bity [choć nie próbowałem jeszcze gplflash'a], ale jest nspluginwrapper [ebuild chyba gdzieś po forum się wala, ale mam jakby co] żeby odpalić to pod 64bitami

2. Są rzeczy 32bitonly, jak np. win32codecs [jest w portage skompilowany mplayer-bin do ich obsługi], czy opera [wymaga emul-linux-x86-xlibs/qtlibs, emerge wrzuci]

3. Java - w portage jest skompilowany blackdown do 32bitów, przydatny dla opery.

Ogólnie trzeba trochę więczej czasu poświęcić na system przez takie pierdoły, ale prędzej czy później udało mi się uruchomić wszystko co chciałem. I nie zrażaj się jeśli np. jakiś pakiet nie jest oznaczy +/~amd64, nieraz pomimo to się kompilują [miałem tak kiedyś z kbeam, wg ebuild'a był tylko ~x86, a działał u mnie bez problemu].

----------

## 13Homer

Z tym "benchmarkowaniem" za pomocą emerge lepiej uważać, bo do czasu instalowania danej aplikacji dolicza się też czas pobierania plików z sieci. W tych pokazanych tutaj czasach nie widać czegoś takiego, ale żeby się ktoś nie zdziwił, jak mu czas "kompilacji" skurczy się kilkukrotnie.

----------

## Yatmai

W sumie przyszło mi na myśl, jeśli coś jest 32bit-only to może by skompilować to z march=686 i zamaskować, a upgrady robić ręcznie ?

To czysta teoria, bo nie wiem jak sie zachowa taka mieszanka architektur (choć na logike powinno działać, bo procek obsłuży i 32, i 64bit'owe instrukcje  :Smile:  )

----------

## deluge

 *mbar wrote:*   

> Czas kompilacji programu to akurat nie jest dobry benchmark. Testujesz tylko sprawność samego kompilatora gcc, który w 64-bitach ma więcej do zrobienia  Nie wiem, co dokładnie jest tego przyczyną, ale np. glibc 2.4 pod AMD64 (2,5 GHz San Diego) kompiluje się u mnie zauważalnie dłużej, niż 32-bitowy glibc 2.4 na procesorze pentium-m 1,5 GHz. Ale sam system po skompilowaniu działa na A64 znacznie lepiej.

 

A czy przypadkiem glibc nie kompiluje sie dluzej gdyz robi to 2 razy? zapewne masz multilib wiec szykuje biblioteki 32 i 64 bitowe. Chyba  :Wink: 

----------

## mbar

Tak, też na to wpadłem, ale niestety nie wiem  :Smile:  Do programów 32-bit są ściągane biblioteki z "emul" w nazwie -- może ktoś inny wie lepiej.  :Smile: 

----------

## Yatmai

Udało wam sie może uruchomić Cool'n'Quiet (widniejące w kernelu jako PowerNow! ) ?  :Very Happy: 

----------

## mbar

oczywiście

----------

## Aktyn

 *Art.root wrote:*   

>  Dwu rdzeniowość jestem pewien, że nawet na Linuksowym desktopie nie będzie w 100% wykorzystana

 

Wszytko zależy od tego co robisz na tym desktopie, jak tylko klikać na stronki w mozili to raczej dużo uploadu nie przyspieszy  :Wink: 

Jednak jak wykorzystujesz komputer w mocniejszym celu, to owszem, dwurdeniowość oraz 64 bity oraz oczywiście oprogramowanie do tego, mogą dużo dać. Nie wiem jak jest np z gimpem do obróbki zdjęć, jeżeli ma taka opcja to pomoże, Poza tym konwersja audio czy wideo. Zawsze możesz konwertować dwie rzeczy na raz   :Smile:  Bo jedna czasami sie nie bardzo da rozpisać na wielowątkowość. Choć zawsze może lecieć proces osobno dekompresji i kompresji, co jest wykorzystwane zdajesie w transcode z filtrem wejsciowym na mplayerze. Ale to tak domniemuję.

64 bity wykorzystuje jednak wiecej pamięci, za względu na dłuższy adres. Jednak możliwości pamięciowe są o wiele większe.

Przy konwersji wideo czy audio na 64 bitach, pomaga jednostka zmiennoprzecionkowa, szczególnie ta o podwójnej precyzji.

U mnie konwersja do wav->ogg trwa okolo 30% szybciej.

Na pewno jeżeli dobrze jest napisane oprogramowanie, to można przyspieszyć, operacje porównania i wyszukiwania.

I takie tam inne matematyczne niuanse.

Może troche pisze tak sucho, ale możliwości są  :Smile: 

 *Art.root wrote:*   

>  64bit... no przecież jeszcze nie ma Windziaka64Bit

 

masz sie czym martwić  :Wink: 

Mam linuksa 64 bitowego (prawie 8 miesięcy) i tylko z tą myślą wymieniłem kompa i w sumie mam to czego sie spodziewałem.

Proc na razie jednordzeniowy, ale w planach mam zmiane na dwurdzeniowy, tylko na razie inwestuje w inne dziedziny  :Wink: 

Problemem może być tylko brak 100% wsparcia w kwestiach co już manwe_ zauważył, no i coś do DOSa nie działa. DOSEMU działa bo to emulator, tylko to to drugie pracuje jedynie pod 32 bitami.

----------

## Yatmai

Cóż DOS'a nie przewiduje, a jakby mnie przypyliło to mam jeszcze obok Cell'a 866  :Very Happy:  A czy sam fakt 64Bit przyspiesza może emulatory jak DOSEmu, DOS Box czy Wine, czy wręcz spowalnia, bo choćby w przypadku dwóch pierwszych występuje jeszcze większy skok technologiczny w stosunku do docelowych 386  :Very Happy: 

A propos dwóch rdzeni, to w grach czy nieprzystosowanych procesach raczej to nie pomoże, ale.... Gdy jeden rdzeń zajmie się kadu, xmms'em, kde, jakieś kopiowanie w tle czy co tam jeszcze, to drugi całkowicie bezczynny może się zająć choćby konwertowaniem wav->mp3  :Smile: 

Generalnie tak czy inaczej 2 rdzenie na Linuchu to świetna sprawa (szkoda tylko, że kosztuje to tyle co 2 procki scalone w jedno :/ ), choć w takich domowych warunkach raczej nie będzie to wykorzystane w 100%, ale to ja tak z natury sie czepiam  :Very Happy: 

 *Quote:*   

> 64 bity wykorzystuje jednak wiecej pamięci, za względu na dłuższy adres. 

 

A coś tak podświadomie czułem, że ram będzie musiał być najmocniejszym elementem mojego nowego kompa  :Very Happy:  Myślałem o 2x256 Dual (specjalnie po to biorę s939  :Very Happy: ) ale teraz poważnie rozważę 2x512  :Smile: 

PS. Tak mi teraz przyszło do głowy, czy jest możliwość by na dwóch rdzeniach odpalić dwa różne kernele ? Kiedyś pracowano nad takimi prockami, na których można by odpalić 2 systemy operacyjne, tylko nie wiem czy to ukończono ( i czy czasem nie miały być to dopiero 4-ro rdzeniowce  :Very Happy: )

----------

## Aktyn

 *Art.root wrote:*   

> PS. Tak mi teraz przyszło do głowy, czy jest możliwość by na dwóch rdzeniach odpalić dwa różne kernele ? Kiedyś pracowano nad takimi prockami, na których można by odpalić 2 systemy operacyjne, tylko nie wiem czy to ukończono ( i czy czasem nie miały być to dopiero 4-ro rdzeniowce )

 

Podobno pracują nad rozwiązaniem aby móc uruchamiać jedncześnie dwa systemy, ale kiedy skończą i czy system też nie będzie musiał mieć przy tym wsparcia, to nie wiem. 

Poza tym w domowych warunkach czasami mocniejszy proc też sie przydaje. Tym bardziej że te nowe procki podczas braku obciążenia naprawde nie pobierają dużo mocy, a kiedy trzeba to ruszają z kopyta   :Cool: 

Choć podejrzewam że wszelkie symulacjie projektowe w poważniejszym znaczeniu będą sie wlokły.

Zastanawiam sie tylko jakiego mocnego komputera użyto podczas projektowania niewykrywanego myśliwca nadżwiękowego F22

W sumie zagadnienie chyba nie takie straszne, wyliczenie płaszczyzn odbicia, tyle że połączone razem z areodynamiką  :Smile: 

----------

## Yatmai

Pewnie tego samego co, co do symulacji i wyliczenia trasy lotów kosmicznych  :Very Happy:  Choć zawsze mnie zastanawiało jakie można mieć problemy, żeby do rozwiązania trzeba było zaprząc na rok jednostkę z kilkoma tysiącami procków  :Very Happy: 

----------

## Kurt Steiner

 *Art.root wrote:*   

> Myślałem o 2x256 Dual (specjalnie po to biorę s939 ) ale teraz poważnie rozważę 2x512 

 Jak masz mozliwosc wydania kilku zlotych wiecej to sie nawet nie zastanawiaj tylko bierz 1GB. Jest to lepsza inwestycja. RAM na pewno sie przyda - chocby gdyby Cie naszla ochota vmware. Zreszta Linux tego nie zmarnuje. Jak nie pojdzie na programy to na cache i bufory.

----------

## Aktyn

właśnie, jest w Polsce gdzieś na uczelni mocny sprzęt, mysle że uczeni wiedzą co liczą   :Very Happy:  Część to pewnie symulacje czy konstrukcja  podoła trudom zadania. Na pewno dużo mogą zajmować rzeczy do optymalizacji, właśnie podałem przykład myśliwca. Poprzedni myśliwiec f117 projetkowany w dobie braku mocnych komputerów, nie odznacza sie dobrymi parametrami co do areodynamiki, bo jest po prostu kanciasty  :Smile: 

Wiem że sa programy do symulacji pożarów ( dość wiernie obrazujące realny przebieg ) itp. choć pewnie one aż przez rok nie liczą  :Smile: 

Poza tym z tego co ja wiem matematycy mają jakieś tam swoje problemy i twierdzenia, które ciężko im rozstrzygnąć. W sumie porównując moc DeepBlue który gra sobie w szachy oraz zdolność człowieka do rozwiązywania problemów, to sie nie dziwie że czasem trzeba sie naliczyć  :Smile:  Z czego podobno DeepBlue wygrał nie dlatego że jest lepszy, tylko dlatego że przeciwnik po kilku partiach zaczął sie męczyć i popełniać błędy.

Ja kończe to OT

----------

## sir KAT

 *Aktyn wrote:*   

> właśnie, jest w Polsce gdzieś na uczelni mocny sprzęt, mysle że uczeni wiedzą co liczą   Część to pewnie symulacje czy konstrukcja  podoła trudom zadania.

 

Tak w Polsce jest trochę mocnego sprzętu np. http://www.cyf-kr.edu.pl/uslugi_obliczeniowe/?a=kdmo

A tak naprawdę to największe zapotrzebowanie na moc obliczeniową mają chemicy (generalnie jest taniej i bezpieczniej przeprowadzać reakcję wirtualnie) oraz fizycy. A co do tych mocy obliczeniowych to to czym teraz dysponujemy to jest nic w porównaniu do zapotrzebowań. Zwykle obliczenia projektuje się tak aby dały wynik w realnym czasie (czyli mniej niż rok) a i tak uzyskiwana rozdzielczość jest niezadowalająca i nawet wzrost mocy obliczeniowych o czynnik 10 wielkiej rewolucji nie przyniesie.

----------

## Drwisz

Wystąpił ciekawy efekt "nasycenia" mocą obliczeniową komputera. W zasadzie by grać, pracować i uczyć się wystarcza procesor athlonXp2000 i odpowiednio duża ilość pamięci. Przyśpieszenie można osiągnąć przez wymianę kart graficznych, nośników informacji a nie przez wymianę procesora. Słupki i inne wizualzacje mające pokazać wyższość jednego procesora nad drugim to zwykła pomyłka i marketing. Dla zwykłego użytkownika w zasadzie nie mają znaczenia i nie są widoczne.

Dodam jeszcze od siebie: wymuszona uszkodzeniem płyty przesiadka na amd64 z athlonaXP 1700 przyniosła mi: większą szybkość kompilacji, wzrost wielozadaniowości, poprawę komforu pracy, troszkę szybciej się wszystko ładuje (po prostu jest szybszy). I to w zasadzie tyle. Wniosek jest prosty- jeśli w krótkim czasie nie nastąpi rewolucja technologiczna oprogramowania, to do zwykłych zastosowań domowych wystarczać będzie dalej architektura 32 bitowa. By prawidłowo wykorzystać 64 bitową architekturę, jest potrzebny specjalnie napisany tylko dla niej program. Większość oprogramowania to zwykłe konwersje na 64 bity niewykorzystujące potencjału procesorów. Dlatego procesory wielordzeniowe 32bitowe długo jeszcze będą gościć w komputerach. I co ważne, doskonale spisywać się w codziennych pracach.

----------

## mbar

 *Drwisz wrote:*   

> amd64 z athlonaXP 1700 przyniosła mi: większą szybkość kompilacji, wzrost wielozadaniowości, poprawę komforu pracy, troszkę szybciej się wszystko ładuje (po prostu jest szybszy).

 

W takie bajki to ja nie wierzę, podaj jakieś obiektywne wyniki, jak np. time kompilacji pakietów (tylko nie glibc z oczywistych względów).

Oops, my bad  :Wink:  Bzdury wypisuję...Last edited by mbar on Fri Aug 11, 2006 7:31 am; edited 1 time in total

----------

## Yatmai

W sumie kompilacja jajka trwa mi mniej więcej tyle samo, ale SuperPI na 64bit liczy jakieś 30% szybciej. UT chodzi tak samo szybko.

Narazie tyle, bo mam jeszcze system 32bit, to pewnie jeszcze ten procek nie rozwija skrzydeł  :Very Happy: 

----------

## Drwisz

Przyniosła bo zamiast athlonaXP 1700 mam athlona64 3000, czyli szybszy procesor o czym pisałem. Ilość pamięci ta sama na obu płytach 1G. Płyta asus a8v-mx starej nie pamietam coś na nforce2.

Przed wymianą kompilacja kde 3.5.3 trwała około 10h- obecnie jest to 7.30h dla kde, gnome, xfce w jednej sesji, kompilator gcc 3.4.4.

Dlaczego nie gcc z serii 4.xx, bo nie widzę racjonalnych przesłanek, a przyspieszenie rzędu 0,01sek to troszkę za mało. 

Make.conf

```
CFLAGS="-march=athlon64 -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j2"

LINGUAS="pl en"

ACCEPT_KEYWORDS="~amd64"

USE="-doc mad dlloader esd oss alsa symlink mp3 vorbis ogg xvid mpeg cups gnome 3dnow 3dnowext berkdb bzip2 unicode pam ipv6 kde qt dvd dvdr cdr cdrw gtk gtk2 tcl tk nls keyboard mouse nsplugin"

VIDEO_CARDS= "nv vesa vga"

LANGUAGE="48"

ALSA_CARDS="emu10k1"

PORTDIR="/usr/portage"

AUTOCLEAN="yes"

FEATURES="ccache candy moo"

CCACHE-SIZE="512M"
```

----------

## mbar

Sorry Drwisz, to ja miałem pomroczność  :Smile:  Przeczytałem dokładnie odwrotnie, że uzyskałeś lepszą wydajność na axp 1700 niż na amd64 i dlatego chciałem  jakieś wyniki  :Smile:  No jasne, że na amd64 jest lepiej i szybciej, bo sam też wykonywałem swego czasu taką przesiadkę. Zapomnijcie o moim poprzednim poście  :Smile: 

----------

