64-bitowy Chrome tylko dla Linuksa
- Dodano: 23 sierpnia 2009
- Wprowadził: Szymon Barczak
- Komentarze: 78
64-bitowa wersja przeglądarki Google Chrome będzie na razie dostępna tylko dla Linuksa.
Dean McNamee, deweloper Chrome, napisał na liście mailingowej, iż ekipa Google v8 JavaScript pracuje nad 64-bitowym portem przeglądarki. Są już obecne instrukcje na wiki Google Code for Chromium odnośnie budowy pakietu Chrome dla 64-bitowej wersji Linuksa. Dodatkowo warto dodać, iż istnieje już zbudowana wersja amd64 Chromium, która dostępna jest dla użytkowników Ubuntu na Ubuntu Launchpad PPA
Inny deweloper, Sig Ager, napisał:
V8 nie jest jeszcze skompilowany w trybie 64-bitowym dla Windows. Koncentrujemy się na dostarczeniu 64-bitowej wersji wpierw na Linuksa i MacOS. Oczywiście pracujemy nad wersja dla Windows, która powinna ukazać się w najbliższym czasie.
Mimo tego, wciąż istnieje główna różnica między Chrome dla Windows i Linuksa – pomimo informacji o priorytecie w dostarczeniu 64-bitowej wersji pod systemy z pingwinkiem, to na Linuksa wciąż nie ma udostępnionej nawet publicznej bety przeglądarki.
Więcej informacji: http://blog.internetnews.com/skerner/200...-vers.html
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
78 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
prosta sprawa – ilu uzytkownikow windy uzywa 64bit systemu, a ilu uzytkownikow uniksoidow uzywa systemow 64bit.
i sprawa jasna…
No ja nie mam pojecia, więc skończ z dramaturgią i rozjaśnij ile ich jest :>
Z tego co wiem to juz troche jest tych Vista 64 bitowych na rynku. Ale mulą samo tak jak 32bitowe, a i wiele programow sie crashuje
Absolutny FUD nie poparty żadnymi dowodami…
64 bitowy Win7 chodzi idealnie. Szybciej od 32 bitowej wersji. Nie zauważyłem żadnych bugów.
A zauważyłeś wykorzystanie pamięci?
Ja zauważyłem. Wykorzystuje pamięć, rzeczywiście. W sumie to zdziwiłbym się, gdyby jej nie wykorzystywał. -.-'
Potwierdzam – Win7x64 chodzi pięknie
co z tego ze system chodzi, poinstaluj sobie troche programow to wtedy odczujesz "zalety" windowsa 64bit
Mam Vistę 64. Trochę programów mam zainstalowanych. System działa dobrze. Aha i lubię UAC.
uzytkownik windy, jesli chce uzywac 4 giga ramu lub wiecej, zmienia system na 64 bitowy, uzytkownik 'uniksoidow' zmienia jedem wpis w kernelu…
To powiedz mi dlaczego 32bitowy Windows Server łyka więcej niż 4GB i nie protestuje?
To proste, PAE jest aktywne, ale co do Visty to możesz uaktywnić PAE ale microsoft programowo ograniczy Ci ilość używanej pamięci
Zaalokuj w jednym procesie te więcej niż 4GB to pogadamy.
Bezpośrednio się nie da, ale od czego jest mapowanie? Winda ma API do okien na PAE – jednocześnie widoczny jest mniejszy obszar niż przydzielony. Zrób klasę-wrappera i nawet nie zauważysz…
Zauważę, będzie wolniej.
@LV: C64 też mogło mieć więcej niż 64kB RAMu, ale nie były one w pełni adresowalne. PAE to nie to samo co natywne adresowanie więcej niż 32bitów.
Trzeba jeszcze dodać, że gonitwa za numerkami trwa w najlepsze. Chyba z powodu właśnie tych 64 bitów Chromium (pewnie Chrome też) ma już numer 4 ;]
Bzdury.
Są trzy różne linie (produkcyjne).
Wedle wersji "na dzisiaj":
Google Chrome 2.0.172.40 Stable
Google Chrome 3.0.195.4 Beta
Google Chrome 4.0.202.0 Dev
Ha, ja mam skompilowany Chromium z wczoraj i mam 4.0.203.0
ha, a ja mam dluzszego!
Zabawne jest, że tyle osób się z Tobą zgadza. Takiś popularny, no no…
@bies: ciekawe ile kliknięć to faceci ;-P .. fuj
Z tego co się orientuję Chromium jest jedno, a o nim głównie pisałem.
Trzeba dodac ze ta wersja naprawde dziala swietnie w porownaniu do poprzednich buildow ktore testowalem z svn.
teraz
wczesniej
A mnie dziwi czemu programiści ciągle piszą na 32 bity, skoro już procesory 64 bitowe są od czasów Athlona64? I powstają to coraz nowsze dystrybucje na Linuksa w 32 bitach. Gdybym ja je pisał to zamiast cofać się do tyłu ,wolał bym iść do przodu, już nawet najstarsza dalej rozwijana dystrybucja Linuksa "Slackware(Slack)" stworzyło wersję 64 bit.I wcale nie jest prawdą że system 64 bitowy potrzebuję 4Gb ramu i procesora 4 rdzeniowego ,na 512 taki system działa równie sprawnie jak nie lepiej od 32 bit, tylko że jest jeszcze mało wspierany,sterowniki,itp. Korzystam już od dawna z 64bit i według mnie działa super lepiej niż na 32bit. Czekam teraz na opinię posiadaczy Athlona64 i 512-1024 ramu |-) pozdro.
To taki ciekawy efekt placebo. Ja na przykład porównywałem wydajność windowsów i linuksów 32 i 64bity. W wydajności nie zauważyłem najmniejszej rożnicy.
Niemniej skoro (tak naprwdę) większość ludzi ma już 64bitowe procesory to czemu ciągle robi się 32bitowe aplikacje. Ta tendencja będzie utrzymywać się jeszcze z 5-6 lat tak sądzę.
A 64bitowe systemy potrzebująwięcej ramu (ponieważ biorą go więcej).
Pozdrawiam!
Potrzebują więcej RAMu, ponieważ rozmiar wskaźnika jest 2 razy większy. A aplikacje powinno pisać się tak, że powinny dać się kompilować i na 32, i na 64 bitach
.
To to wiem.
Takie pisanie aplikacji to kompatybilność wsteczna. Zawsze będzie niedoskonała i wolniejsza.
Bo tylko rozmiar wskaźnika większy… Słowo maszynowe jako takie większe – liczby nim reprezentowane też są większe. Instrukcje posiadają dodatkowe prefiksy i inne takie cuda, w trybie 64bit nie ma części krótkich form instrukcji, oczywiście operandy zgodnie z tym co wcześniej rosną – kod puchnie strasznie, mimo większej liczby rejestrów.
@LV
przeprowadzano porównania, program zajmuje 20-40% pamięci więcej dla wersji 64 bitowej.
Ale za to 64 bity dają ci speeda na zadniach bardzo procożernych typu szyfrowanie czy ripping.
Po za tym 64bity to już standard dla baz danych (wątki i ograniczenie ~2.8GB na shared memory) poza tym indeksy 64 bitowe są wydajniejsze.
Ogólnie na desktopie między 64 a 32 bitam różnicy nie zauważysz no chyba:
1. Masz poniżej 1G pamięci
2. ripujesz
,szyfrujesz itd 
Program to nie tylko kod, ale i dane, to raz. Dwa – nic o wydajności nie mówiłem. Co do porównań to polecam dokumentacje i insze papiery intela poczytać – tam masz sensowne porównania.
Primo wolę papiery AMD, secundo zamiast czytać można po prostu zmierzyć. Mi ,,głupi'' flac kodował niemalże 80% szybciej na x86_64. Pisałem już kiedyś.
Skoro 64 bit zagości na dobre za 5-6 lat to kiedy wyjdzie 128bit za 30lat?
Skoro 32bit – 386 na PC – wszedł w latach 80` to nie zdiwiłbym się jakby trwało to nawet więcej. Szybciej doczekamy się wynalazków typu komputer optyczny, kwantowy, lotów na marsa, świń w kosmosie…
Oprócz zwiększenia ilości adresowalnej pamięci, trybie x86-64 widoczne jest dodatkowe 8 rejestrów ogólnego przeznaczenia. To ułatwia kompilatorom optymalizację kodu.
> czemu programiści ciągle piszą na 32 bity, skoro już procesory 64 bitowe są (…)
Bo nie oznacza to że 32 bitowe maszyny nagle znikną, z głośnym puf..Puki co, komputery z 32 bitowymi procesorami nadal są produkowane i sprzedawane.
Nie piszą bo to strata RAMu. Sami programiści Chromium pisali kiedyś, że 64-bitowa wersja nie będzie miała żadnej przewagi ani zalet. Główną wadą będzie większe wykorzystanie RAMu.
Zainstaluj sobie Ubuntu x86-64 i x86. Uruchom programy, których używasz i porównaj ile zajmują pamięci. U mnie różnica była w granicach 50%. Ale czarę goryczy przepełniły niestabilne 64-bitowe sterowniki od Nv.
Na razie, póki ilość pamięci RAM nie przekracza grubo ponad 4GB to tylko fanaberia.
Jeśli mocno liczysz (kodowanie multimediów, raytracing itp.) to ta fanaberia daje znaczne zyski.
Sprae – masz jakieś linki na ten temat? Miałem obie wersje Ubuntu i nie zauważyłem takich różnic.
To co napisałem wynika z moich obserwacji Systemu, którego w 64 bitowej wersji używałem od połowy 2007r. Teraz przy aktualizacji zmieniłem sobie na 32 dla sprawdzenia. Skłoniły mnie do tego teksty ludzi z Chromium i niestabilność sterowników Nvidii.
Podejrzewałem, że będzie jakaś oszczędność ramu, ale nie wiedziałem, że aż taka. Codziennie używam najczęściej w pracy około 8 aplikacji. W wersji 64 bitowej system brał podczas pracy z nimi 700 – 1000 MB, teraz ciągnie 350 – 650 (dla samych aplikacji) z łącznej puli 4 GB.
Co do wydajności to mam c2d w którym "fusion" działa tylko w trybie 32 bitowym. Zastanawialiśmy się czy korzystając z możliwości gcc da się uzyskać większą wydajność z dodatkowych 8 rejestrów sse (dostępnych tylko w trybie 64b), czy z "fusion".
Fusion – technologia firmy Intel pozwalająca na wykonywanie kilku instrukcji w jednym cyklu zegara. Głównie chodzi o połączenia CMP ze skokami.
BTW myślę, że jakaś racja w tym jest i to dość poważna. Gdyby była niepoważna to panowie pracujący nad JVM nie robiliby kompresji wskaźników i stosu dla wersji 64 bitowej.
Ależ oczywiście, że jest poważna. Większy kod i dane to mniej trafień w cache. Z drugiej strony 2 razy więcej rejestrów to 2 razy większy ,,cache zerowego poziomu''. Coś za coś, najlepiej jest po prostu zmierzyć.
Nie chodzi o wyzszosc Linuxa nad Winda ale o to że:
- na Linuxie x64 można uruchamic tylko aplikacje x64
- na Windowsie x64 pójdą rowniez aplikcje x32
I stąd prosty wniosek – pierwsze x64 dla Linuxa.
Ale to raczej wada niz zaleta.
kto ci takich glupot naopowiadal jak "na linuksie x64 mozna uruchamiac tylko apliakacje x64"?
prosze o nie powtarzanie tego typu blednych opinii…
W dużej części faktycznie działają, ale trzeba się ciągle bawić w instalowanie dodatkowych bibliotek i innych pierdół a i tak nie jest tak stabilnie jak być powinno.
nie spotkalem sie z brakiem stabilnosci, bo i to te same biblioteki ktore sa instalowane na systemach 32bit.
to JEST FUD!
jesli jest niestabilne – to tak samo jak na 32bit – to JEST FAKT.
a na x64 próbował zabaw z łajnem?
Tak, i działa tak samo jak na x86.
A mozesz mi sypnac linkiem do opisu uruchamiania aplikacji x32 w linuxie x64? Chetnie skorzystam z porady.
Jaki to problem? instalujesz ia32-libs a potem paczki x32 i po sprawie
plichu: moze pod debianoidami (w tym łubudubu
)
Greg: prosze, nie ponizaj sie juz bardziej i jesli serio nie radzisz sobie z tym (a pewnie nawet nie probowales) – podpytaj google…
btw. nie ma czegos takiego jak x32
btw. na innych architekturach (mipsy, sparki) tez bez problemu mozna na 64bit systemie uruchamiac aplikacje 32bit. w przypadku ia64 tez mozna uruchamiac aplikacje ia32 – mimo braku sprzetowej kompatybilnosci (procesory te maja rozne zestawy instrukcji) – w tym wypadku dzieje sie to za sprawa emulacji. w przypadku architektury amd64 – do uruchomienia aplikacji w trybie 32bit – kernel zawiera odpowiednie "gejty" 32bit, i wykonuje aplikacje w trybie 32bit (tak jak to mialo w miejsce w przypadku uruchamianiu kodu v86 na procesorach do 386 w gore).
widzisz, jak sam piszesz trzeba zainstalowac ia32-libs. takie rzeczy to błachostka dla wprawnych linuxowcow, jednak google pomyslalo o mniej wprawionych userach i dalo od razu wersji x64. i o co tyle zamieszania? dodatkowo nikomu niepotrzebne obrazanie. troche kultury panowie. w taki oto sposob linux nie moze wejsc na szerszy plac, kazde pytanie jest solidnie bombardowane dogryzaniem. zycze powodzenia w zyciu prywatnym.
Mam fedore x86-64 i wszystkie appsy 32bitowe dzialaja od reki, bez instalacji dodatkowych pakietow.
.
No chyba ze to program z repo, ale one same instaluja zaleznosci, wiec gdzie tu problem?
FUD!
To ciekawe w jaki sposób do tej pory Chromium u mnie działało skoro mam 64 bity ;]
Ciekawe jak działa mi sterownik do drukarki skoro jest 32 bitowy.
I najciekawsze jak działają mi 32 bitowe programy z windowsa na moim 64 bitowym linuksie.
No to juz przesada z sterownikami. Pewny jestes?
Dlaczego przesada? Sterowniki drukarek są w userspace w CUPS. Powinno działać.
Pomimo tego, że nie ma jeszcze publicznej bety Chromium na Linuksa, to u mnie dev alpha jest główną przeglądarką. Działa wszystko co potrzebne, czasem (rzadziej niż FF) zaliczy crasha, nie działa flash (kiedy się go uruchomi to przeglądarka robi się strasznie niestabilna) ale po co komu reklamy
.
czyżby chrome os był dostępny tylko na 64 bity?;-)
wow wpierw flash 64 bit – teraz chrome 64 bit którego jeszcze nie ma no ale jest 64 bit (?)). Super.
sprae
A to dziwne że na Ubuntu jest taka różnica 50%, bo na innych wersjach Linuksa aż takiej nie ma. To pewnie coś z tym Ubuntu nie tak.
kiedyś próbowałem mandrivy 64bit i było podobnie
zależy od programu … jedne więcej przyrastają inne mniej
Nie rozumiem czemu użytkownicy 2-rdzeniowych 64bitowych procków z ramem ponad 3GB boją się tak bardzo 64bitowego jajeczka.
Zainstalowane działa po małych adjustacjach (nawet ubuntu) stabilnie i przyjemnie, 32-bitowy userland w gentoo działał znakomicie już 2 lata temu.. Zresztą, już większość programów w 64bitowych Xach (czyli łubudubu i debianowatych, gentu & tych z czerwonymi kapeluszami) jest napisana jest w wersji 64bit i działa tak jak powinna działać.
(lub bardzo podobnie)
Różnica – in plus – wydajność, dekodowanie (wideło & mjuzik), kodowanie, przeglądarki z fleszem video, wszystko działa jak powinno.
Programy do edycji audio, i 32-bitowe wersje tego co jest tylko w 32bitach.
Czyli, bez obaw – wszystko działa.. pozostaje zarchwizować dane i przenieść się – aha, na 5GB pamięci wyraźnie widać przyspieszenie dla 64-bitowego łubudubu, z wyraźną róznicą na korzyść w responsywności systemu (czyli, od kliknięcia do zadziałania tego czegoś co zamierzamy ruszyć)
Używam arch64 od ponad roku i jestem bardzo zadowolony.
Jedynym mankamentem jest wine – które trudno zmusić do współpracy z d3d, a i wydajność na tym polu ma mniejszą.
Dziwię się jednak że przy 5GB ramu zaobserwował Pan wzrost wydajności – musi używać Pan baaaardzo ramożernych aplikacji. Bo innego wytłumaczenia nie widzę – system nie powinien być szybszy tylko dlatego że ma więcej ramu, skoro nawet na niego nie "wchodzi".
To nawet nie tak, zwyczajnie odpaliłem 2 filmy w h264, do tego 2 xvid'y i jeszcze dało się używać przeglądarki
– oczywiście wszystko na 1 panelu.
Dla porównania przed przejściem na 64bit z 32bitowego OS'a zrobiłem taki sam test – i różnica jest bardzo zauważalna.
Co do szybkości – wszystko zależy od kompilacji kodu, jeśli 64-bitowy OS korzystał będzie z pełnego rejestru procesora to siłą rzeczy (czas wykonania kodu) będzie szybszy niżby korzystał z rejestru procesora 32-bitowego. Różnice są rzędu kilku procent ale są, kilka procent na jajku kilka na kilku aplikacjach – i nagle jest 15-20% do przodu.
Zatem, wszystko w rękach ludzi od kodu i ich chęci optymalizacji & tego w jaki sposób kod jest potem kompilowany. Na szczęście GCC już od dawna optymalizuje 64-bitową architekturę z właściwym skutkiem.
dobrze
ale nie o tym mowa.
Napisał Pan cytuję "aha, na 5GB pamięci wyraźnie widać przyspieszenie dla 64-bitowego łubudubu" – dlaczego na 5GB? przy 4GB łubudubu jest ciągle zbyt powolny?
Wydaje mi się, że mój arch64 wcale nie będzie szybszy jeśli dorzucę mu kolejne 4GB ramu (mam teraz 4GB). Tzn będzie szybszy jeśli faktycznie będzie chciał wziąć więcej niż te 4GB które posiada. Co jeszcze mu się chyba nie udało, niecałe 4GB konsumował po odpaleniu kilku maszyn wirtualnych – każda bierze od 512 do 1024MB.
Nie, nie tylko. Weź pod uwagę, że poza pamięcią procesów masz pamięć cache dyskowego. A to dyski są zazwyczaj najwolniejszym elementem systemu. Im więcej cache dyskowego tym lepiej (ba, powyżej jakiegoś rozmiaru RAM można pobawić się w ramdysk na biblioteki i programy w systemie).
można też np. korzystać z demona "preload"
bies – a może jakieś małe howto albo chociaż link do tutoriala jak ustawić właśnie system (biblioteki i programy) w ramdysku? (czy w tmpfs ?)
Howto (nie sprawdzone — piszę ot tak sobie):
mkdir /tmp/libcpy && cp -r /usr/lib64 /tmp/libcpy
mount none /usr/lib64 -t tmpfs
cp -r /tmp/libcpy /usr/lib64
Gdzieś na etapie gdy /usr/lib64 nie jest jeszcze potrzebne.
Przy zamykaniu:
rsync –delete -axtrHl /usr/lib64 /tmp/libcpy
umont /usr/lib64
rsync –delete -axtrHl /tmp/libcpy /usr/lib64
Wszystkie użyte programy muszą być albo statyczne albo linkować z bibliotekami w /lib. Nie odpowiadam za uszkodzenia czegokolwiek. Nie zastanawiałem się też nawet 3 minut czy to będzie działać.
Porządne How To znajdziesz na drugim końcu wyszukiwarki.
Tak sobie myślę, że można po prostu zrobić cat /usr/lib64/* >/dev/null na starcie systemu i biblioteki wylądują grzecznie w cache. Bez kombinacji z tmpfs. Preload to zaawansowana wersja tegoż.
używam chromium Bubu 9.04 od miesiąca. jest bardzo szybki. odkąd odpaliłem flasha opcją -enable–plugins jest niezastąpiony
pomimo że chromium 64 jest super szybki w wyświetlaniu stron, to jednak z obsługą flasha mogłoby być znacznie lepiej (ex. przewijanie aktywnego youtube) – niezależnie od tego czy plugin flasha jest 64 czy 32 bitowy.
Ps. a wolę używać wersji 32-bitowej z uwagi na duuużo lepszą jej responsywność.
system to wspomniany arch64 a posiadam wydajny system.
obecność elementów flash na praktycznie każdej stronie = kulejące przewijanie, musimy poczekać, a szkoda bo chromium jest naprawdę szybkie
+ brak adblocka można ponoć rozwiązać odpaleniem chromium z obsługą proxy opcją np. -all_proxy=127.0.0.1:8118 , ale niestety świeży chromium który posiadam zwraca tutaj wyjątek – brak implementacji obsługi proxy, także ustawień proxy środowiska kde4 z którego korzystam nie potrafi zaimportować :/.
Zatem i dorzuciłem do /etc/hosts ciągi 0.0.0.0 domena.com, jak pokazano w tym przykładzie:
http://someonewhocares.org/hosts/zero/
niestety zamieszczony zbiór jest zbyt mały by ograniczyć wszystkie reklamy…
Czy orientuje się ktoś może czy do pliku /etc/hosts można dorzucać ciągi podobne do tego: */adpopup?* … zapewne nie i jest to głupie pytanie
jest jeszcze porzucony już projekt adsweep http://www.adsweep.org który prawie daje sobie radę. Musimy dodać –enable-extensions do wywołania chromium aby zainstalować i używać tego plugina
udało się! proxy działa.
Po prostu polecenie obsługi proxy jest inne od tego które podaje samo chromium, więcej tutaj:
http://dev.chromium.org/developers/design-documen…
No to teraz privoxy ładnie blokuje śmieci