ono aj to vypnutie HT spomalí a niektoré programy prestanú fungovať.
To tvrdí aj pán Pavlík cca od 35:20
https://www.youtube.com/watch?v=rwbs-PN0Vpw
a konkrétny výrok o tom, prečo to nejde je okolo 37:15
Nemusí zhavarovať, stačí ak nesenia časy.. Som zvedavý, či vysvetlíte , prečo dole uvedený kód v cca. 50% na Intel Corw i5 M520 padne na segfault a prečo na AMD Ryzen 5 1500X nepadne nikdy, akurát pri kompilovaní -Ofast, sa program neukončí, pri .-O0, -O1,-O2 aj -O3 nespadne a vždy skončí a skúšajte to pustiť vo forme
s paramtrami
time ./threadTest 1
time ./threadTest 2
time ./threadTest 4
time ./threadTest 8
time ./threadTest 16
time ./threadTest 32
time ./threadTest 64
time ./threadTest 2048
a budete sa čudovať. a potom pochopíte, čo sa deje A pritom toto je taká "vyšši dívčí" v tejto oblasti
P..S. kód (bohužiaľ tag code ruší odsadenie, tak ako bez toho tagu)
#include<stdio.h>
#include<stdlib.h>
#include<pthread.h>
#include <errno.h>
pthread_mutex_t mutualExclusion;
pthread_mutexattr_t atributy;
int activate=0;
int filled=0;
void * fncVlakno(void *);
void (*function[10000000]) (void);
void prva(void)
{
static int count =0;
printf("%d. Prva\n",++count);
}
void druha(void)
{
static int count =0;
printf("%d. Druha\n",++count);
}
int main(int argc, char **argv)
{
int numberOfThreads=1,i;
pthread_t vlakno;
pthread_attr_t parametre;
if(argc==2)
{
sscanf(argv[1],"%d",&numberOfThreads);
}
printf("Number of Threads:%d\n",numberOfThreads);
printf("prva/druha:%p/%p\n",prva,druha);
pthread_mutexattr_init(&atributy);
if((pthread_mutex_init(&mutualExclusion, &atributy))<0)
{
printf("Chyba c.%d\n",errno);
perror("Nepodarilo sa pripojit na mutex\n");
exit(-2);
}
if(pthread_attr_init(¶metre))
exit(-1);
pthread_attr_setdetachstate(¶metre, PTHREAD_CREATE_DETACHED);
srand(1024);
for(i=0;i<numberOfThreads;i++)
{
if (pthread_create(&vlakno,¶metre,fncVlakno,NULL))
exit(-2);
}
for(filled=0;filled<10000000;filled++)
{
if(rand()%2)
{
function[filled]=prva;
}else
{
function[filled]=druha;
}
}
filled++;
while((activate!=filled)||(filled<10000000));
printf("Finished\nNumber of Threads:%d\n",numberOfThreads);
exit(0);
}
void * fncVlakno(void * nic)
{
void (*moja) (void);
int error=0;
while (activate<10000000)
{
if(filled>activate)
{
if (function[activate]!=NULL)
{
if (pthread_mutex_lock(&mutualExclusion))
{
perror("Rodic:Chyba zamykania\n");
exit(-4);
}
moja=(function[activate++]); ;
if(pthread_mutex_unlock(&mutualExclusion))
{
printf("unlock return:%d\n",error);
perror("Rodic:Chyba odomykania:");
exit(-4);
}
(*moja)();
}
}
}
activate++;
pthread_exit(NULL);
}
Mne by to prekážalo, keby to bol trvalý jav a nie len dôsledok toho, že som s nechal vyprovokovať k neuváženému postu. Nepopieram, že sa nechám tento rok vyprovokovať častejšie ako bežne.
Pokiaľ dostanem pripomienku a nie nadávku,.tak sa ju snažím akceptovať a poučiť sa z nej.
P.S. Zvažoval som dlho tento post, lebo "mi
v hlave blikali dve kontrolky":
1. Útočia na teba, musíš sa brániť
2. Frekvencia tvojich postov je blízko hranice, ktorú nesmieš prekročiť lebo je pre teba limitom.
Taký limit blbec nemá a človek s nábehom byť blbec ju má výrazne vyššie ako zbytok populácie.
nevím, jestli si to tím nedáním do vylepšil :), teď ti to nikdo přepisovat nebude, text je plný html entit...
Trochu se mi tomu nechce věřit, co na ten kód řiká -Wconversions -std=gnu99 nebo aspoň -Wextra -pedantic?
Řekl bych, že tam prostě máš chybu :), hned na první pohled vidím pthread_mutex_init, který kontroluješ na zápornou hodnotu a přitom vrací 0 pokud je success, nenulový je chyba.
hodil bych to s gdb a prošel asm, vypadá to, že nám prostě vyprávíš pohádky.
Vypínání HT je běžná činnost u řady systémů, někde je totiž na škodu a člověk ho nechce z konkrétních důvodů používat. Teď to vypadá, že HT bude na odchodu, Intel ho bude muset celý predesignovat a uvidíme co z toho vzejde. My ho holt také vypneme na clusterech a připravíme se o 30 % výkonu, nic neřešitelného :).
Tern kód má ukázať dôležitosť synchronizácie, a čo sa stane keď nie je dobre urobená
>hned na první pohled vidím pthread_mutex_init, který kontroluješ na zápornou hodnotu a přitom vrací 0 pokud je >success, nenulový je chyba.
OK. Ešte som sa nestretol s kladnou hodnotou, takže zmena
if((pthread_mutex_init(&mutualExclusion, &atributy))<0)
{
printf("Chyba c.%d\n",errno);
perror("Nepodarilo sa pripojit na mutex\n");
exit(-2);
}
na
if((pthread_mutex_init(&mutualExclusion, &atributy))!=0)
{
printf("Chyba c.%d\n",errno);
perror("Nepodarilo sa pripojit na mutex\n");
exit(-2);
}
uhf, takže ty jsi nám nechtěl ukázat, že se HT nemá vypínat (viz začátek vlákna), protože pak mohou padat aplikace, ale chtěl jsi, ať ti najdeme v kódu chybu? Proč to prosím tě děláš? :)
Mimochodem, to, že jsi se dosud nedostal do situace, kdy pthread_mutex_init vyhodil kladné číslo naprosto nic neznamená a při první CR ti to musí dotyčný omlátit o hlavu :).
A neuznal som svoju nepresnosť?
uznal. A skoro viem, kde som nabral
Return Value
If successful, the pthread_mutex_destroy() and pthread_mutex_init() functions shall return zero; otherwise, an error number shall be returned to indicate the error.
https://linux.die.net/man/3/pthread_mutex_init
A keď som skúsal podmienky vzniku chýb? tak mi vždy vrátil -errno.
(vtedy som používal threadové mutexy na synchronizáciu procesov , samozrejme cez obchádzky, ktoré sú nutné)
Ja som nechcel nájsť chybu v kóde, ale otestovať, či kolega vie, o čom hovorí, keď pohŕda aj zdrojom môjho vyjadrenia zo SUSE, alebo je to len jeho nezdravé sebavedomie, čo je toho zdrojom
Ja sa nečudujem., ten kód mal niečo ukázať: dôležitosť synchronizácie.
>přistupuje k neatomickým globálním proměnným activate a filled z více threadů bez sychronizace,
práveže sznchronizácia tam je mutexom, ale úmyselne nie všade, a presne na miesta, kde to nie je som sa pýtal kolegu. resp. chcel som sa ho to opýtať. Ja som tie miesta nechcel opraviť, len naznačiť, že to nie je úplna hračka napísať paralelný kód.
V tom kódu je takové množství chyb, že je ztráta času je vypisovat.
Napsat korektní multithread kód není až tak složité, ale je nutné dodržovat nějaké good practices. Tady se míchají globální proměnné mezi funkcema, což je problém sám o sobě. I v single thread je nutné držet scope proměnných co nejužší, aby byl kód čitelný. Jinými slovy je primární problém čitelnost kódu, nikoliv to, že je multithreaded.
K otázce, proč to někde padá, někde ne, ještě podle různých stupňů optimalizací:
- vzhledem k tomu, že proměnné nejsou volatile, tak je kompilátor může cachovat a může být zaručena pro hraniční podmínku a následná hodnota coby index
- podle různých počtů threadů se proměnná vícekrát přičíst při context switch, to se může ještě lišit podle cache, která je postupně rychleji aktualizovaná postupně od HT, L1 atd až do hlavní paměti.
Trocha nechapem ten humbuk v tomto threade. Na zaciatku je nejaka otazka, preco ten kod na inteloch segfaultuje a na AMD nie? Odpoved je jednoducha, ten kod robi fundamentalne zlu vec. A to, ze tato fundamentalne zla vec v nejakom inzieniersky podstatnom pocte pripadov na nejakom konkretnom HW nezhavaruje ju nelegitimizuje.
S vypinanim a zapinanim HT to nema nic spolocne. Je to programatorska chyba, ktora sa spolieha na to, ze za istych striktne ohranicenych podmienok tento fundamentalne zly kod bezi bez chyby.
A zalezitost s pisanim korektneho paralelneho kodu (ktora podla mna nie je velkym problemom, je to dost dobre deterministicky problem) nema s konfiguraciou paralelnej architektury vela spolocneho.
>Na zaciatku je nejaka otazka, preco ten kod
>na inteloch segfaultuje a na AMD nie?
Ten thread začína o dva príspevky skôr:
No, ono se tím vypnutím HT odstraní spoustu dalších zranitelností. Takže je otázka jestli by nebylo místo komplikovaných a zpomalujících patchů lepší rovnou HT vypnout.
Potom som uviedol prečo v SUSE tvrdia, že to tak jednoduché nie je so zdrojom.
Kolega zdroj napadol bez dôkazu, že má kvalifikáciu zdroj spochybniť. Vtedy som vypenil, a chcel sa presvedčiť, či tú kvalifikáciu má, otázkou, či vie aspoň nájsť úmyselne urobené chyby v kóde.
A keďže so tý otázku položil nejasne a teda zle
Tak jednooercentní(ako Vy) mi riadili, a kégia jednopercentných sa do mňa pustila.
Zdroje vysvetľujúce, kto sú jednopercentní:
Parallel programmers not prepared for the glorious revolution
By Wily Ferret
Tue Nov 27 2007, 12:28
INTEL RECKONS barely one per cent of software programmers are prepared to face the challenge of parallel programming, which the hardware giant (unsurprisingly) reckons is the future of development.
http://www.theinquirer.net/inquirer/news/1026585/programmers-prepared-glorious
Software needs meaty cores, not thin, stringy ARMs, says Intel
By Simon Sharwood, 26 Feb 2014
“The world has a big issue around vectorisation and parallelisation of code,” Graylish said. “99% of code isn't written that way.” Graylish also feels “defining a workload that can run in 1000 cores is hard.”
Most software, Graylish added, “still requires a big meaty core” and Intel is happy to provide them.
http://www.theregister.co.uk/2014/02/26/software_needs_meaty_cores_not_thin_stringy_arms_says_intel/
A diskusia sa posúvala do rôznych kapitol v rámci knihy
http://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2017.01.02a.pdf
Každý človek má lepšie a horšie obdobia, kebz u mňa prevažovali horšie tak výrazne, ako tvrdíte nemám auru 88
Otázka je aké mám obdobie teraz.
Co je Aura
Aura se zobrazuje u příspěvků registrovaných uživatelů v našem diskusním fóru a u diskusí pod články a zprávičkami. Číslo vyjadřuje jakousi kvalitu toho, kdo příspěvek zaslal. Na základě Aury pak mohou ostatní uživatelé k příspěvku přistupovat – i naprosto stejná informace má rozdílnou hodnotu podle toho, kdo vám ji říká – když pád dolaru předpovídá váš makléř, jistě tomu přikládáte vyšší váhu, než když to samé tvrdí bezdomovec na parkovišti.
Aura je číslo v rozmezí 0 – 100 (100 znamená nejvyšší kvalitu). Auru může mít pouze registrovaný uživatel, který píše příspěvky pod svým jménem (přihlášením).
https://www.root.cz/redakce/co-je-aura/
Před pár lety jsem chtěl koupit procesor i7 2600S, ale pořád nebyl u žádného z distributorů v ČR, tak jsem to nakonec nevydržel a koupil i5 2500S.
Docela podobné procesory:
https://ark.intel.com/products/52211/Intel-Core-i5-2500S-Processor-6M-Cache-up-to-3_70-GHz
https://ark.intel.com/products/52215/Intel-Core-i7-2600S-Processor-8M-Cache-up-to-3_80-GHz
Co čert nechtěl, snad během měsíce byla na trhu i ta i7. Koupi jsem i7 a i5 prodal, ale než se tak stalo, tak jsem si porovnal výkon. Za těch 66% navíc v pořizovacích nákladech jsem dostal navíc asi 33% výkonu, ale narazil jsem i na program, který na té i7 běžel pomaleji než na té i5. Už si nepamatuji co to bylo, ale mám pocit, že generování nějakých klíčů.
Využívalo to 2 jádra, ale na té i7 to z nějakého důvodu asi běželo na stejném jádře s HT. Na i5 na dvou jádrech, protože tam HT nebyl. Dělal to jeden jediný program, co jsem testoval. Ostatní běžely normálně.
Závisí to na používaných aplikáciách
viď. rozšírený test
The Performance Hit For A Xeon-Backed Ubuntu Linux VM With L1TF / Foreshadow Patches
20 August 2018
TTSIOD 3D Renderer v2.3b Phong Rendering With Soft-Shadow Mapping
FPS, More Is Better
Unmitigated (bez akejkoľvek opravy) 660,20 (fps)
Full Mitigation (s úplnou opravou) 206,30 (fps), to je mínus 68,8% výkonu, len pre túto jednu záplatu
a naopak
SQLite v3.22Timed SQLite Insertions trvanie testu (menej je lepšie)
bez záplaty 61,99s
s plnou zápltou 62,49 s ( starta výkonu cca. 0,8%)
https://www.phoronix.com/scan.php?page=article&item=l1tf-foreshadow-xeon&num=2
+čiže na odpoveď musím niekto vedieť, aké aplikácie a v akom pomere používate (vrátane idle) aby sa dalo aspoň teoreticky spočítať, koľko je to spomalenie.