Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Ferda 02. 07. 2018, 20:37:12
-
Hrál jsem si s Pythonem a Cythonem na Raspberry Pi Zero W a učinil jsem zajímavou zkušenost.
Udělal jsem si benchmarkovy program, který přičítá k proměnné jedničku. Kód i výsledky jsou vidět na obrázku.
(https://thumb.ibb.co/bTT6NJ/py_cy_c.png) (https://ibb.co/bTT6NJ)
Běželo to na Raspbery Pi Zero W taktovanem na 700 MHz. Dnes jsem si hrál s tatováním a přetaktoval toho chudáka na 1100 MHz. Výsledky mě překvapily, očekával jsem poměrné zkrácení času.
Jenže je to jinak, user time se změnil takto:
add_i.py 24,230 => 17,952
add_i 8,798 => 12,170
addx_i 6,979 => 6,150
addc_i 7,166 => 6,305
U pythoního kódu spuštěném v Pythonu se zrychlení projevilo výrazně. Zato ten samý pythonní kód přeložený Cythonem se výrzaně zpomalil, jak je to možné? Optimalizovaný pythonní kód i céčkový kód se zrychlily jen nepatrně, jak je to možné?
-
Napadá mě, zda:
- přetaktovaný stroj správně měří čas (zkuste se stopkama v ruce)
- zda se nepřehřívá a v důsledku toho nezpomaluje procesor
-
Takový krátký cyklus může být ošemetný, protože se může přehřívat malá oblast v procesoru, který se musí adekvátně bránit. Časté skoky v krátkém cyklu také mohou způsobit časté zahazování výsledků rozpracovaných instrukcí. Operační paměť nemusí stíhat takt procesoru, ten musí přidávat cykly, jejichž časování nemusí být optimální.
Pokud potřebuješ škálovat, tak to zkus horizontálně. Co takhle hyperkrychle z 16 ks RPiZ?
-
sledujes i teplotu? aneb: https://en.wikipedia.org/wiki/Dynamic_frequency_scaling
-
Teplotu jsem sledoval. Snažil jsem se dokonce toho chudáka přetížit a nandat mu co největší load, ale teplota nepřeleze 55 st. C a už se ani po 15 minutách trápení, kdy má load přes 3.
-
Takový krátký cyklus může být ošemetný, protože se může přehřívat malá oblast v procesoru, který se musí adekvátně bránit. Časté skoky v krátkém cyklu také mohou způsobit časté zahazování výsledků rozpracovaných instrukcí. Operační paměť nemusí stíhat takt procesoru, ten musí přidávat cykly, jejichž časování nemusí být optimální.
Pokud potřebuješ škálovat, tak to zkus horizontálně. Co takhle hyperkrychle z 16 ks RPiZ?
S tou pamětí mě to také napadlo, ale zaráží mě, že některý program to urychlí razantně a jiný to razantně zpomalí. Problém s pamětí by asi zpomalil všechny programy, ne?
-
sledujes i teplotu? aneb: https://en.wikipedia.org/wiki/Dynamic_frequency_scaling
Tohle jsem zkoušel taky, s různými hodnotami, třeba i 400/1100 MHz, asi je to úsporné a dobré na šetření energií, ale na výkonu to nepřidá, právě naopak, vždy došlo ke snížení výkonu.
-
Tohle jsem zkoušel taky, s různými hodnotami, třeba i 400/1100 MHz, asi je to úsporné a dobré na šetření energií, ale na výkonu to nepřidá, právě naopak, vždy došlo ke snížení výkonu.
sorry, ten link nebyl presnej, sice je to redirect z "CPU throttling" ale koukam ze tam je o tom jen zminka, resp. o tom snizovani vykonu pri zvysene teplote... tedy slo mi konkretne o to, zda pri pretaktovani u tebe nedochazi k zvysene teplote nad limit, kdy se zacne napeti a/nebo frekvence CPU snizovat a vede to prave k opaku ceho chces dosahnout, tedy snizeni vykonu... pokud by to bylo ono, da se to resit pridanim chladice na CPU (pripadne i RAM), lepsi nez slabozebrovej hlinik za $1 z ciny, je urcite mohutnejsi medenej(napr. (http://rpishop.cz/chlazeni/196-medeny-chladic-pro-raspberry-pi.html))... pokud by to nestacilo, tak pouzit nejakej mohutnej/vetsi (https://www.youtube.com/watch?v=1AYGnw6MwFM) nebo primo aktivni chladic s vetrackem (https://www.youtube.com/watch?v=5Ud-grj4Zl0)...
-
Frekvenci jsem sledoval v /proc, tam snizena nebyla, pri zahajeni vypoctu skoci nahoru a pak uz tam drzi. Nebo se muze snizit, aniz by o tom kernel vedel?
-
Je známý fakt, že přetaktováním může poklesnout výkon z různých důvodů - nejčastěji TDP.
Příklad - jedno vlákno jede na 5GHz, ale zbylá jsou přiškrcená a takt skáče sem tam. Na první pohled se to tváří relativně normálně. Spotřeba vyskočí nahoru, ale výkon nikde - obecně bych radil netaktovat, nebo jen o zanedbatelnou část (bez zvýšení napájení).
Další důvody můžou být různé děličky frekvencí, které se třeba podtaktují aby to vycházelo apod. (paměti, čipové sady,...)
Prostě nic šokujícího to je na detailní analýzu problému. Na tohle hodně trpěla ta Bulldozer architektura AMD (přetaktování prostě nikam neposunulo). Procesor si to škrtil dál sám.
-
To je docela bezny, znamy jiz z dob Celeronu 300... Timingy pameti, cache a sbernice jsou mimo syncu, taky se zvysuje frekvence chyb na sbernici a nutnost znovu preposilat data, kdyz je detekovana chyba. Uplne normalni, proste jses jiz za limitem :D
-
To je docela bezny, znamy jiz z dob Celeronu 300... Timingy pameti, cache a sbernice jsou mimo syncu, taky se zvysuje frekvence chyb na sbernici a nutnost znovu preposilat data, kdyz je detekovana chyba. Uplne normalni, proste jses jiz za limitem :D
Tomu bych rozuměl, kdyby se zpomalily všechny programy.
-
Pokud potřebuješ škálovat, tak to zkus horizontálně. Co takhle hyperkrychle z 16 ks RPiZ?
Jasně, třeba bitcoin cluster na raspberry nebo RAID z microSD karet (linustechtips)... Spíš by to chtělo prášky na hyperaktivitu