pěkný článek, jako obvykle plný hodnotných odkazů, díky.
Jinak ve spojení s Sandy Bridge se ještě objevuje L0 cache jako taková forma dřívější trace cache.
Ještě bych doplnil, že Java má s tímhle velké problémy, její všudepřítomný array of references dokáže pěkně rychle pročistit sdílenou cache jenom při drobném iterování struktur. U kritických aplikací se to občas obchází denormalizací struktur do array of primitives...
Jen pro zajímavost, jak detekuješ tohle chování? Dají se vůbec v komplexních aplikacích najít žravá vlákna?
"O L0 je zmínka tady":[http://funkcionalne.cz/2015/05/l1i-cache-a-itlb-kdyz-ani-spekulace-nepomuzou/].
U pole referencí je mnohem větší problém omezená lokalita dynamicky alokovaných objektů, která vede k nekonečné sérii *cache-miss*, která bude naprosto dominovat.
Tohle chování nijak nedetekuji, protože nikdy nebylo třeba. V cestě vždycky stojí tisíc jiných drobných překážek, které přinesou mnohem znatelnější zrychlení. Zdrojem soupeření o LLC v prostředí JVM může být každé vlákno, které hodně alokuje nebo provádí GC. Ale protože jde o cache sdílenou všemi jádry na daném socketu, neplatí to jen o různých vláknech, ale i o různých procesech a o různých virtuálních systémech. Doslova napříč celým systémem.
VisualVM umí měřit *per thread allocations*, což může být v určitých situacích dobré vodítko, ale neumí měřit *per thread memory traffic*. Na to je potřeba něco jako perf.
Jinak ve spojení s Sandy Bridge se ještě objevuje L0 cache jako taková forma dřívější trace cache.
Ještě bych doplnil, že Java má s tímhle velké problémy, její všudepřítomný array of references dokáže pěkně rychle pročistit sdílenou cache jenom při drobném iterování struktur. U kritických aplikací se to občas obchází denormalizací struktur do array of primitives...
Jen pro zajímavost, jak detekuješ tohle chování? Dají se vůbec v komplexních aplikacích najít žravá vlákna?
U pole referencí je mnohem větší problém omezená lokalita dynamicky alokovaných objektů, která vede k nekonečné sérii *cache-miss*, která bude naprosto dominovat.
Tohle chování nijak nedetekuji, protože nikdy nebylo třeba. V cestě vždycky stojí tisíc jiných drobných překážek, které přinesou mnohem znatelnější zrychlení.
Zdrojem soupeření o LLC v prostředí JVM může být každé vlákno, které hodně alokuje nebo provádí GC. Ale protože jde o cache sdílenou všemi jádry na daném socketu, neplatí to jen o různých vláknech, ale i o různých procesech a o různých virtuálních systémech. Doslova napříč celým systémem.
VisualVM umí měřit *per thread allocations*, což může být v určitých situacích dobré vodítko, ale neumí měřit *per thread memory traffic*. Na to je potřeba něco jako perf.