Grupy dyskusyjne   »   pl.misc.telefonia.gsm   »   8 rdzeni - po co to komu?

8 rdzeni - po co to komu?

Data: 2014-05-23 13:11:39
Autor: K.J.
8 rdzeni - po co to komu?
Witam,
czy sa juz dostepne testy 8 vs 4 rdzenie, glownie chodzi o czas renderowania stron html, zapewne wydajnosc taka sama, niczym sie nie rozni, a tylko wiecej kosztuje, pobiera wiecej energii i skraca czas pracy na bateriach

Data: 2014-05-23 13:06:31
Autor: G Nowak
8 rdzeni - po co to komu?
On 23/05/2014 12:11, K.J. wrote:

czy sa juz dostepne testy 8 vs 4 rdzenie, glownie chodzi o czas
renderowania stron html, zapewne wydajnosc taka sama, niczym sie nie
rozni, a tylko wiecej kosztuje, pobiera wiecej energii i skraca czas
pracy na bateriach

Zapewne teraz strony mobilne beda projektowane z odpowiednia iloscia fajerwerkow (lub zapetlonych skryptow) aby to wykorzystac. Z desktopowymi wersjami stron juz to sie stalo. Odwiedzalem ostatnio pare popularnych adresow uzywajac Athlona X2. Bylo wolno i uzycie cpu 100% przez wiekszosc czasu.

--
Pozdr
G

Data: 2014-05-23 16:07:00
Autor: K.J.
8 rdzeni - po co to komu?
On 05/23/2014 02:06 PM, G Nowak wrote:
On 23/05/2014 12:11, K.J. wrote:

czy sa juz dostepne testy 8 vs 4 rdzenie, glownie chodzi o czas
renderowania stron html, zapewne wydajnosc taka sama, niczym sie nie
rozni, a tylko wiecej kosztuje, pobiera wiecej energii i skraca czas
pracy na bateriach

Zapewne teraz strony mobilne beda projektowane z odpowiednia iloscia
fajerwerkow (lub zapetlonych skryptow) aby to wykorzystac. Z
desktopowymi wersjami stron juz to sie stalo. Odwiedzalem ostatnio pare
popularnych adresow uzywajac Athlona X2. Bylo wolno i uzycie cpu 100%
przez wiekszosc czasu.


nie beda projektowane, 8 rdzeni to strata pieniedzy i energii

Data: 2014-05-23 16:44:11
Autor: G Nowak
8 rdzeni - po co to komu?
On 23/05/2014 15:07, K.J. wrote:

czy sa juz dostepne testy 8 vs 4 rdzenie, glownie chodzi o czas
renderowania stron html, zapewne wydajnosc taka sama, niczym sie nie
rozni, a tylko wiecej kosztuje, pobiera wiecej energii i skraca czas
pracy na bateriach

Zapewne teraz strony mobilne beda projektowane z odpowiednia iloscia
fajerwerkow (lub zapetlonych skryptow) aby to wykorzystac. Z

nie beda projektowane, 8 rdzeni to strata pieniedzy i energii

Niestety, to samo sadzilem o ekranikach tysionc pincet razy piredyliard chujopikseli (jakby full HD przy 5'' nie starczylo). Tym czasem kazda nowa sluchawka juz je ma.

--
Pozdr
G

Data: 2014-05-24 07:54:57
Autor: J.F.
8 rdzeni - po co to komu?
Dnia Fri, 23 May 2014 13:06:31 +0100, G Nowak napisa³(a):
On 23/05/2014 12:11, K.J. wrote:
czy sa juz dostepne testy 8 vs 4 rdzenie, glownie chodzi o czas
renderowania stron html, zapewne wydajnosc taka sama, niczym sie nie
rozni, a tylko wiecej kosztuje, pobiera wiecej energii i skraca czas
pracy na bateriach

Zapewne teraz strony mobilne beda projektowane z odpowiednia iloscia fajerwerkow (lub zapetlonych skryptow) aby to wykorzystac. Z desktopowymi wersjami stron juz to sie stalo. Odwiedzalem ostatnio pare popularnych adresow uzywajac Athlona X2. Bylo wolno i uzycie cpu 100% przez wiekszosc czasu.

Przegladarka w telu potrafi wykorzystac wiele rdzeni ? Na jednej stronie ?

J.

Data: 2014-05-24 09:13:50
Autor: Marek
8 rdzeni - po co to komu?
On Sat, 24 May 2014 07:54:57 +0200, "J.F." <jfox_xnospamx@poczta.onet.pl> wrote:
Przegladarka w telu potrafi wykorzystac wiele rdzeni ? Na jednej stronie ?

Przecież pobieranie "elementów" stron jest asynchroniczne, wystarczy żeby strona miaÅ‚a kilka requestów  w ajaksie to każdy poleci w osobnym wÄ…tku i poÅ‚Ä…czeniu. A jak osobny wÄ…tek to scheduler prawie na pewno rozdzieli to na procesory, w tym nie problem. Problem
w tym jak arm jako platforma radzi sobie  z smp i czy nie ma wÄ…skich gardeÅ‚, czy po przekroczeniu pewnej iloÅ›ci rdzeni nie przestanie być skalowalny.

--
Marek

Data: 2014-05-24 12:28:40
Autor: RadoslawF
8 rdzeni - po co to komu?
Dnia 2014-05-24 09:13, Użytkownik Marek napisał:
On Sat, 24 May 2014 07:54:57 +0200, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:
Przegladarka w telu potrafi wykorzystac wiele rdzeni ? Na jednej
stronie ?

Przecież pobieranie "elementów" stron jest asynchroniczne, wystarczy
żeby strona miaÅ‚a kilka requestów  w ajaksie to każdy poleci w osobnym
wątku i połączeniu. A jak osobny wątek to scheduler prawie na pewno
rozdzieli to na procesory, w tym nie problem. Problem
w tym jak arm jako platforma radzi sobie  z smp i czy nie ma wÄ…skich
gardeł, czy po przekroczeniu pewnej ilości rdzeni nie przestanie być
skalowalny.

Doświadczenie z wielowątkowym przesyłaniem uczy że lepiej i
szybciej po kolei niż kilka równocześnie.
Kolejna sprawa to przy dzisiejszych prockach wąskim gardłem
jest przesyłanie a nie wyświetlanie.
No ale może ja o czymś nie wiem.


Pozdrawiam

Data: 2014-05-24 17:13:03
Autor: Marek
8 rdzeni - po co to komu?
On Sat, 24 May 2014 12:28:40 +0200, RadoslawF <radoslawfl@spam_wp.pl> wrote:
Doświadczenie z wielowątkowym przesyłaniem uczy że lepiej i
szybciej po kolei niż kilka równocześnie.

Przesyłaniem czego?

--
Marek

Data: 2014-05-24 17:52:42
Autor: RadoslawF
8 rdzeni - po co to komu?
Dnia 2014-05-24 17:13, Użytkownik Marek napisał:

Doświadczenie z wielowątkowym przesyłaniem uczy że lepiej i
szybciej po kolei niż kilka równocześnie.

Przesyłaniem czego?

Danych.
W tym przypadku elementów jakiejś strony www.


Pozdrawiam

Data: 2014-05-25 00:38:12
Autor: Marek
8 rdzeni - po co to komu?
On Sat, 24 May 2014 17:52:42 +0200, RadoslawF <radoslawfl@spam_wp.pl> wrote:
Danych.
W tym przypadku elementów jakiejś strony www.


Jakoś tego doświadczenia nie podzielają autorzy np. ajaxa domyślnie ustawiając tryb przesyłania async, przeładuj dowolna stronę z ajaxem zawierającą kilka żądań i policz w ilu wątkach pójdą te żądania (i ile gniazd użyją).

--
Marek

Data: 2014-05-26 18:06:11
Autor: RadoslawF
8 rdzeni - po co to komu?
Dnia 2014-05-25 00:38, Użytkownik Marek napisał:

Danych.
W tym przypadku elementów jakiejś strony www.


Jakoś tego doświadczenia nie podzielają autorzy np. ajaxa domyślnie
ustawiając tryb przesyłania async, przeładuj dowolna stronę z ajaxem
zawierającą kilka żądań i policz w ilu wątkach pójdą te żądania (i ile
gniazd użyją).

Autorzy wielu przyśpieszaczy robią rzeczy świadczące o braku wiedzy
lub logiki. A tak naprawdÄ™ chodzi o napisanie czegoÅ› na czym siÄ™
zarobi a nie na przyśpieszeniu komukolwiek czegokolwiek.
A tak z ciekawości sam sprawdziłeś. Napiszesz jaka była różnica
na jakiej stronie ina jakim Å‚Ä…czu ?


Pozdrawiam

Data: 2014-05-26 22:28:33
Autor: Marek
8 rdzeni - po co to komu?
On Mon, 26 May 2014 18:06:11 +0200, RadoslawF <radoslawfl@spam_wp.pl> wrote:
A tak z ciekawości sam sprawdziłeś. Napiszesz jaka była różnica
na jakiej stronie ina jakim Å‚Ä…czu ?


Strona, która wymaga zaÅ‚adowania 10 parametrów (wartoÅ›ci liczbowe) kontrolnych pewnego systemu w trybie async Å‚aduje szybciej, w trybie sync wolniej  i wyraźnie wydać Å‚adowanie pokolei  zamiast efektu zaÅ‚adowania "od razu". W tym przypadku nie ma wysycenia Å‚Ä…cza ale nawet zakÅ‚adowanie kilkudziesiÄ™ciu bajtów przez równolegle wÄ…tki i poÅ‚Ä…czenia jest szybsze niż w trybie async.

Test pobierania pliku 20MB po seci lokalnej 1GB (FreeBsd@2xamd64 1.7GHz)
Dwa procesy po kolei:
  time -p sh -c 'wget -q   -O /dev/null 192.168.2.164/plik ; wget -q -O /dev/null 192.168.2.164/plik '

real 0.51
user 0.04
sys 0.24

Dwa procesy równolegle:
time -p sh -c 'wget -q   -O /dev/null 192.168.2.164/plik & wget -q -O /dev/null 192.168.2.164/plik '

real 0.37
user 0.02
sys 0.13 0.37 s vs.  0.51 s , równolegle wÄ…tki wyraźnie szybciej.
 Dla równolegÅ‚ych 3 procesów daje czas pobierania 0.54s a po kolei 0.77 s.
Widać  że FreeBSD caÅ‚kiem liniowo siÄ™ skaluje w smp :).

--
Marek

Data: 2014-05-27 18:47:26
Autor: RadoslawF
8 rdzeni - po co to komu?
Dnia 2014-05-26 22:28, Użytkownik Marek napisał:
On Mon, 26 May 2014 18:06:11 +0200, RadoslawF <radoslawfl@spam_wp.pl>
wrote:
A tak z ciekawości sam sprawdziłeś. Napiszesz jaka była różnica
na jakiej stronie ina jakim Å‚Ä…czu ?


Strona, która wymaga załadowania 10 parametrów (wartości liczbowe)
kontrolnych pewnego systemu w trybie async Å‚aduje szybciej, w trybie
sync wolniej  i wyraźnie wydać Å‚adowanie pokolei  zamiast efektu
załadowania "od razu". W tym przypadku nie ma wysycenia łącza ale nawet
zakładowanie kilkudziesięciu bajtów przez równolegle wątki i połączenia
jest szybsze niż w trybie async.

Test pobierania pliku 20MB po seci lokalnej 1GB (FreeBsd@2xamd64 1.7GHz)
Dwa procesy po kolei:

time -p sh -c 'wget -q   -O /dev/null 192.168.2.164/plik ; wget -q -O
/dev/null 192.168.2.164/plik '

real 0.51
user 0.04
sys 0.24

Dwa procesy równolegle:
time -p sh -c 'wget -q   -O /dev/null 192.168.2.164/plik & wget -q -O
/dev/null 192.168.2.164/plik '

real 0.37
user 0.02
sys 0.13
0.37 s vs.  0.51 s , równolegle wÄ…tki wyraźnie szybciej.

Dla równoległych 3 procesów daje czas pobierania 0.54s a po kolei 0.77 s.
Widać  że FreeBSD caÅ‚kiem liniowo siÄ™ skaluje w smp :).

Podsumowując wielowątkowe ściąganie jest wolniejsze od
jednowÄ…tkowego. Szybsze jest tylko dwu wÄ…tkowe. :-)


Pozdrawiam

Data: 2014-05-28 00:53:21
Autor: Marek
8 rdzeni - po co to komu?
On Tue, 27 May 2014 18:47:26 +0200, RadoslawF <radoslawfl@spam_wp.pl> wrote:
Podsumowując wielowątkowe ściąganie jest wolniejsze od
jednowÄ…tkowego. Szybsze jest tylko dwu wÄ…tkowe. :-)

Nie wiem skÄ…d taki wniosek,  3 równolegle procesy pobraÅ‚y szybciej (0.53s) niż 3 po kolei (0.77s). Gdyby testowana maszynka miaÅ‚a wiÄ™cej niż dwa rdzenie wynik byÅ‚by jeszcze lepszy. W tym przypadku wÄ…skim gardÅ‚em jest jedynie implenentacja fork/exec. W przypadku przeglÄ…darki i js, pobieranie sync po kolei jest jeszcze wolniejsze bo wszystko siÄ™ odbywa w interpreterze js, kolejne poÅ‚Ä…czenie bÄ™dzie zestawione dopiero po zakoÅ„czeniu poprzedniego. W przypadku pobierania async (równolegÅ‚ego) poszczególne wÄ…tki nie muszÄ… czekać na zakoÅ„czenie poprzedniej transmisji.

--
Marek

Data: 2014-05-29 00:28:14
Autor: Marek Wodzinski
8 rdzeni - po co to komu?
On 05/26/2014 10:28 PM, Marek wrote:
Dwa procesy równolegle:
time -p sh -c 'wget -q   -O /dev/null 192.168.2.164/plik & wget -q -O
/dev/null 192.168.2.164/plik '

real 0.37
user 0.02
sys 0.13
0.37 s vs.  0.51 s , równolegle wÄ…tki wyraźnie szybciej.

Ale tak mierzysz tylko czas drugiego wgeta :-)

Dla równoległych 3 procesów daje czas pobierania 0.54s a po kolei 0.77 s.

Wąskim gardłem w tym teście jest sieć, serwer po drugiej stronie lub za mały plik i czas poświęcony na handshake+geta zanim dostanie się prawdziwe dane, a nie system czy procesor. Przy takich testach procek przestał być problemem w erze pentium I, a przy gigabicie w okolicach Pentium III.
Co innego jak potrzebujesz coś policzyć. Ale wtedy żadne bsd nie pomoże jak liczba wątków jest większa od liczby corów, a jeszcze gorzej jak będą chciały mieszać dużo po wspólnym ramie w architekturze numa.

Akurat równoległe otwieranie socketów i czekanie na dane nie jest żadnym obciążeniem i liczba cpu nie ma tu znaczenia.
Dopiero rendering tego co się dostanie wymaga cpu, ale tu przeglądarki jakoś się nie skalują:-) Owszem, flasha odpali na drugim corze, sandboxy też może porozrzucać, ale jak otwierasz tylko jedną stronę, to wiele Ci nie da fefnaście corów.

Widać  że FreeBSD caÅ‚kiem liniowo siÄ™ skaluje w smp :).

Raczej widać, żeś fan FreeBSD.


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

Data: 2014-05-30 01:12:23
Autor: Marek
8 rdzeni - po co to komu?
On Thu, 29 May 2014 00:28:14 +0200, Marek Wodzinski <majek@ODSPAMIACZ.mamy.to> wrote:
Ale tak mierzysz tylko czas drugiego wgeta :-)

Bo tylko wystarczy czas drugiego pod warunkiem, że pierwszy będzie w tle.Zwróć uwagę pod czego wątek się zaczął.

Dopiero rendering tego co siÄ™ dostanie wymaga cpu, ale tu
przeglÄ…darki
jakoÅ› siÄ™ nie skalujÄ…:-) Owszem, flasha odpali na drugim corze,
sandboxy
też może porozrzucać, ale jak otwierasz tylko jedną stronę, to
wiele Ci
nie da fefnaście corów.

Chyba w1993 :).
Teraz "jedna strona" może może mieć kilkanaÅ›cie-dziesiÄ…t reqestów do kontentu na różnych serwerach (nawet jak jest keep alive to i tak dziaÅ‚a w obrÄ™bie jedengo poÅ‚Ä…czenia) + ajax, przeglÄ…darka pociÄ…gnie to w osobnych wÄ…tkach.A to już daje teoretycznÄ… szansÄ™ na rozÅ‚ożenie tego miÄ™dzy "cory". Paradoxalnie to czasami jest problematyczne, bo jak ma siÄ™ serwer www embeded z 5kb ram i ograniczenia na dwa gniazda "na raz" a przegladarka naraz chce w 6 poÅ‚Ä…czeniach pobrać kontent to 4 jej siÄ™  przyblokujÄ… zanim dwa możliwe siÄ™ zwolniÄ…. A wtedy tylko ajax+sync pomaga kosztem czasu Å‚adowania.


Raczej widać, żeś fan FreeBSD.

W życiu, akurat był pod ręką.

--
Marek

Data: 2014-05-30 12:52:00
Autor: Marek Wodzinski
8 rdzeni - po co to komu?
On Fri, 30 May 2014, Marek wrote:

On Thu, 29 May 2014 00:28:14 +0200, Marek Wodzinski <majek@ODSPAMIACZ.mamy.to> wrote:
Ale tak mierzysz tylko czas drugiego wgeta :-)

Bo tylko wystarczy czas drugiego pod warunkiem, że pierwszy będzie w tle.Zwróć uwagę pod czego wątek się zaczął.

No zaczÄ…Å‚ siÄ™ od tego ile rdzeni potrzeba.
I od tego, że dałeś przykład niczego nie udowadniający w tej kwestii.
Na 10 wgetów w tle wystarczy 1 rdzeń, co w zasadzie pokazałeś wysycając gigabit i pokazując, że on jest wąskim gardłem. Plus narzuty na handshake itp. Nic co wymagałoby więcej niż jednego rdzenia w normalnym wielozadaniowym systemie.

Dopiero rendering tego co siÄ™ dostanie wymaga cpu, ale tu
przeglÄ…darki
jakoÅ› siÄ™ nie skalujÄ…:-) Owszem, flasha odpali na drugim corze,
sandboxy
też może porozrzucać, ale jak otwierasz tylko jedną stronę, to
wiele Ci
nie da fefnaście corów.

Chyba w1993 :).
Teraz "jedna strona" może może mieć kilkanaście-dziesiąt reqestów do kontentu na różnych serwerach (nawet jak jest keep alive to i tak działa w obrębie jedengo połączenia) + ajax, przeglądarka pociągnie to w osobnych wątkach.

Mylisz lub nie odróżniasz ściągania danych od ich renderowania. Przy ściąganiu jest potrzebne bardzo mało cpu, w drugim wypadku ono się bardzo przydaje.
Owszem, multitasking tak jak piszesz pomaga _ściągnąć_ dane szybciej (lub nawet w pewnej preferowanej kolejności jeżeli chodzi o ajaxa), ale nie wynika z tego, że potrzeba do tego ileśtam rdzeni.

Natomiast to co napisałem wyżej o fefnastu corach, to to, że przeglądarki różnie radzą sobie z wykorzystaniem tych rdzeniu do renderingu. Oczywiste i najprostsze rzeczy już ostały zrobione - czyli pluginy i zakładki w osobnych procesach/wątkach, ale to co pozostało zaczyna być trudniejsze.
O ile Chrome sobie z tym radzi, to Firefox już średnio. Opera wcale.

A to już daje teoretyczną szansę na rozłożenie tego między "cory".

Praktycznie, to i pół rdzenia by wystarczyło na sieć :-)
I nie zawsze uruchomienie wielu wątków na wielu rdzeniach daje oczekiwany efekt, czasem szybciej całość chodzi w obrębie jednego o ile go nie wysycamy.

Paradoxalnie to czasami jest problematyczne, bo jak ma siÄ™ serwer www embeded z 5kb ram i ograniczenia na dwa gniazda "na raz" a przegladarka naraz chce w 6 poÅ‚Ä…czeniach pobrać kontent to 4 jej siÄ™  przyblokujÄ… zanim dwa możliwe siÄ™ zwolniÄ…. A wtedy tylko ajax+sync pomaga kosztem czasu Å‚adowania.

Czyli tak jak pisałem - to nie cpu czy liczba rdzeni na kliencie jest wąskim gardłem w _ściąganiu_ danych przez przeglądarkę.


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

Data: 2014-05-30 18:57:23
Autor: Marek
8 rdzeni - po co to komu?
On Fri, 30 May 2014 12:52:00 +0200, Marek Wodzinski <majek@ODSPAMIACZ.mamy.to> wrote:
No zaczÄ…Å‚ siÄ™ od tego ile rdzeni potrzeba.

Nie , ktoś napisał że ściągając "po kolei" jest szybciej.niż "równolegle", nie o renderowanie ( raczej generowanie) strony chodziło, mój.komentarz był tylko do kwestii ściągania.

--
Marek

Data: 2014-06-01 03:50:44
Autor: animka
8 rdzeni - po co to komu?
W dniu 2014-05-30 12:52, Marek Wodzinski pisze:
On Fri, 30 May 2014, Marek wrote:

On Thu, 29 May 2014 00:28:14 +0200, Marek Wodzinski
<majek@ODSPAMIACZ.mamy.to> wrote:
Ale tak mierzysz tylko czas drugiego wgeta :-)

Bo tylko wystarczy czas drugiego pod warunkiem, że pierwszy będzie w
tle.Zwróć uwagę pod czego wątek się zaczął.

No zaczÄ…Å‚ siÄ™ od tego ile rdzeni potrzeba.
I od tego, że dałeś przykład niczego nie udowadniający w tej kwestii.
Na 10 wgetów w tle wystarczy 1 rdzeń, co w zasadzie pokazałeś wysycając
gigabit i pokazując, że on jest wąskim gardłem. Plus narzuty na handshake
itp. Nic co wymagałoby więcej niż jednego rdzenia w normalnym
wielozadaniowym systemie.

Dopiero rendering tego co siÄ™ dostanie wymaga cpu, ale tu
przeglÄ…darki
jakoÅ› siÄ™ nie skalujÄ…:-) Owszem, flasha odpali na drugim corze,
sandboxy
też może porozrzucać, ale jak otwierasz tylko jedną stronę, to
wiele Ci
nie da fefnaście corów.

Chyba w1993 :).
Teraz "jedna strona" może może mieć kilkanaście-dziesiąt reqestów do kontentu
na różnych serwerach (nawet jak jest keep alive to i tak działa w obrębie
jedengo połączenia) + ajax, przeglądarka pociągnie to w osobnych wątkach.

Mylisz lub nie odróżniasz ściągania danych od ich renderowania. Przy
ściąganiu jest potrzebne bardzo mało cpu, w drugim wypadku ono się bardzo
przydaje.
Owszem, multitasking tak jak piszesz pomaga _ściągnąć_ dane szybciej (lub
nawet w pewnej preferowanej kolejności jeżeli chodzi o ajaxa), ale nie
wynika z tego, że potrzeba do tego ileśtam rdzeni.

Natomiast to co napisałem wyżej o fefnastu corach, to to, że przeglądarki
różnie radzą sobie z wykorzystaniem tych rdzeniu do renderingu. Oczywiste
i najprostsze rzeczy już ostały zrobione - czyli pluginy i zakładki w
osobnych procesach/wątkach, ale to co pozostało zaczyna być trudniejsze.
O ile Chrome sobie z tym radzi, to Firefox już średnio. Opera wcale.

A to
już daje teoretyczną szansę na rozłożenie tego między "cory".

Praktycznie, to i pół rdzenia by wystarczyło na sieć :-)
I nie zawsze uruchomienie wielu wątków na wielu rdzeniach daje oczekiwany
efekt, czasem szybciej całość chodzi w obrębie jednego o ile go nie
wysycamy.

Paradoxalnie to
czasami jest problematyczne, bo jak ma siÄ™ serwer www embeded z 5kb ram i
ograniczenia na dwa gniazda "na raz" a przegladarka naraz chce w 6
poÅ‚Ä…czeniach pobrać kontent to 4 jej siÄ™  przyblokujÄ… zanim dwa możliwe siÄ™
zwolniÄ…. A wtedy tylko ajax+sync pomaga kosztem czasu Å‚adowania.

Czyli tak jak pisałem - to nie cpu czy liczba rdzeni na kliencie jest
wąskim gardłem w _ściąganiu_ danych przez przeglądarkę.

Większe pliki można ściągać FlashGet-em. Jest on też rozszerzeniem w Firefox.


--
animka

8 rdzeni - po co to komu?

Nowy film z video.banzaj.pl wiêcej »
Redmi 9A - recenzja bud¿etowego smartfona