Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia AI asistenta Lumo.
Amazon koupil společnost Bee zaměřenou na nositelnou osobní AI aktuálně nabízející náramek Pioneer (YouTube) s mikrofony zaznamenávající vše kolem [𝕏, LinkedIn].
Společnost Teufel nedávno představila svůj první open source Bluetooth reproduktor MYND.
Byla vydána verze 4.2 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Anton Carniaux, právní zástupce Microsoft France, pod přísahou: Microsoft nemůže garantovat, že data z EU nepředá do USA bez EU souhlasu, musí dodržovat americké zákony.
Byl vydán Mozilla Firefox 141.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Lokální AI umí uspořádat podobné panely do skupin. Firefox na Linuxu využívá méně paměti. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 141 je již k dispozici také na Flathubu a Snapcraftu.
NÚKIB upozorňuje na kritickou zranitelnost v SharePointu. Jedná se o kritickou zranitelnost typu RCE (remote code execution) – CVE-2025-53770, která umožňuje neautentizovaný vzdálený přístup a spuštění kódu, což může vést k úplnému převzetí kontroly nad serverem. Zranitelné verze jsou pouze on-premise verze a to konkrétně SharePoint Server 2016, 2019 a Subscription Edition. SharePoint Online (Microsoft 365) není touto zranitelností ohrožen.
Společnost Valve zpřísnila pravidla pro obsah, který je možné distribuovat ve službě Steam. Současně řadu her ze Steamu odstranila. V zásadách a pravidlech přibylo omezení 15: Obsah, který by mohl porušovat pravidla a normy stanovené zpracovateli plateb a souvisejícími sítěmi platebních karet a bankami nebo poskytovateli připojení k internetu. Sem spadají zejména určité druhy obsahu pouze pro dospělé.
Programming stuff. And stuff.
"Zákeřnost" hash_map je třeba brát trocha s rezervou, běžné na její zákeřnost nejspíš nenarazíte, ale extrémní případy jsou pak kruté.
Máme třídu Signatuře (reprezentující signaturu typu argumentů funkce), který datový členy vypadají asi takhle:
class Signature { /* ... */ private: std::vector<size_t> _argumentTypes; size_t _returnType; bool _varArg; };
Instancí třídy Signatuře je mnoho (mnoho funkcí). Překlad standardní knihovny funkci trvalo na linuxu 3 sekundy, na windowse 5 minut.
Po zjišťování "WTF is going on" jsem zjistil, že nejvíc času se tráví ve win na počítání hashe a porovnávání dvou signatur (operátor <). Zřejmě implementace hash_map v msvc třídí buckety podle operátoru <.
V tomhle případě se sešli tři faktory, které přispěly k celkové pomalosti:
Řešení:
// header .h class Signature { public: /* ... */ size_t hash() const { return _hashValue; } size_t computeHash() const; /* ... */ private: std::vector<size_t> _argumentTypes; size_t _returnType; bool _varArg; size_t _hashValue; }; inline size_t hash_value(const Signature& s) { return s.hash(); // vrátí v konstruktoru predpočítanou hodnotu _hashValue } // .cpp Signature::Signature(...) { /* nastavení member atributů atd. */ _hashValue = computeHash(); } size_t Signature::computeHash() const { size_t seed = _returnType; size_t argHash = boost::hash_range(_argumentTypes.begin(), _argumentTypes.end()); boost::hash_combine(seed, size_t(_varArg)); boost::hash_combine(seed, argHash); return seed; }Pak se z 5 minut stalo na windows několik sekund. Rule of thumb: 1. Vůbec nepoužívejte hash_map. Když tak radši boost::unordered_map. Performance pak bude stejná na všech platormach. Není pak navíc potřeba definovat vícero operátorů (postačí definování hashe a operátorů rovnosti). 2. Pro malé mapy (do velikosti řádově 100-1000 klíčů) použijte std::map, je to rychlejší (měřeno profilerem). 3. Nikdy nepoužijte spoustu instanci hash_map pro obrovské množství malých map. Tohle pravidlo hodně souvisí s alokátorma - vedlejší efekty jsou pomalost a memory fragmentation (příště).
Tiskni
Sdílej:
Neminim rypat, ale opravdu jsem jediny komu tohle pripada jako trochu "nedodelany" zapisek? Nebo je to umysl a budes na nem jeste pracovat? Pokud je to "První část blogu věnována performance", tak mi trochu nedochazi (ale mozna je to umysl) k jakymu blogu je to prvni cast, a co je to "performance" (prosty preklad z anglictiny mi trochu nesedi do kontextu - nema to byt nazev nejakeho projektu?). Na "prvni cast" mi prijde ze se to az moc odkazuje na nejakou "nultou cast" (jestli je to diplomka / bakalarka, tak asi Uvod).
Navic mi obcas trochu nedochazi logicke souvislosti mezi odstavci (kde je v tride Signature nejaka hash_map? Co s tim ma doba prekladu co delat?).
Pokud to ma byt pokus o predstaveni novych veci z TR1 a na co si pri praci s nimi davat pozor, tak je to dobry napad (samotneho by me to zajimalo). Pokud se ale odkazujes na nejake predchozi veci (a predpokladas uroven znalosti "neceho" - STL? Boostu? ), mozna by nebylo spatne udelat k tomu nejaky uvod (napr. co je vlastne smyslem tohohle vseho a pro koho to je).
Sorry jestli to nebylo jasne:
Signature je klic v hash tabulce, sama zadnou tabulku neobsahuje.
Smyslem je ukazat mozne (a neocekavane) problemy pri pouzivani ruznych struktur v C++ (hash_map v tomhle pripade). Urcite nejsem jediny, kdo na to narazil/narazi (a bude to muset resit) a prvni krat je to velke prekvapeni. Specialne hash_map mela neco do cineni s kazdym druhym performance bugem, ktery jsem resil ("performance" lze prelozit jako "vykon", ale neni to uplne ekvivalent). Podle dokumentace clovek napr. ocekava O(1) slozitost vkladani/vyhledavani (za predpokladu ze kolizi neni mnoho), ale skutecna implementace muze delat celkem ruzne veci.
Znalost STL je predpokladana (alespon vedet o existenci kontejneru jako map, hash_map). Uvod moc udelat nejde, protoze to by byl uvod do prekladacu (proto jsou nastineny jenom podstatne struktury). Je asi potreba hodne predstavivosti
I kdyz se omlouvam za tu nejasnost u slova "preklad" - je mineny preklad nejakych zdrojaku tou aplikaci, podobne "standardni knihovna" je standardni knihovna funkci te aplikace.
Hlavne jsem vcera stravil vic nez hodinu jenom pokusem text postnout - CMS mi vzdy po kazdem nahledu zmenilo entity gt/lt (pouzite pri tech parametrech sablon) na vetsitka/mensitka a vzdy jsem to musel rucne opravit pred dalsim nahledem/dokoncenim (po asi 20 nahledech jsem mel fakt dost, proto je tam nekolik preklepu, nevim jestli jde editovat prispevek i po postnuti).
Uvod moc udelat nejde, protoze to by byl uvod do prekladacu (proto jsou nastineny jenom podstatne struktury). Je asi potreba hodne predstavivostiÚvod určitě udělat jde, mělo by z něj vyplynout co je vlastně smyslem článku. Například tento odstavec by podloužil téměř dokonale:
Smyslem je ukazat mozne (a neocekavane) problemy pri pouzivani ruznych struktur v C++ (hash_map v tomhle pripade). Urcite nejsem jediny, kdo na to narazil/narazi (a bude to muset resit) a prvni krat je to velke prekvapeni. Specialne hash_map mela neco do cineni s kazdym druhym performance bugem, ktery jsem resil ("performance" lze prelozit jako "vykon", ale neni to uplne ekvivalent). Podle dokumentace clovek napr. ocekava O(1) slozitost vkladani/vyhledavani (za predpokladu ze kolizi neni mnoho), ale skutecna implementace muze delat celkem ruzne veci.
Například tento odstavec by podloužil téměř dokonale
Tak tomuhle bych nerozumněl zas já.
JJ, taky jsem se s tim setkal. Port aplikace na Solaris byl priserne pomalej. Po chvili googlovani jsme zjistili, ze na solarisu jsou dve STL knihovny. Standartni - plne kompatibilni, a "rozsirena", ktera pry plne neodpovida standartu. Ta prvni pouziva pro mapu vektor(nebo seznam) a ta "nestandartni" pouziva hash tabulku. Stacilo doinstalovat nejaky balik a prekompilovat aplikaci a vse jelo jak vino. Souhlasim s tim, ze to dost zakerna vec, ze zdrojaku vubec nemate sanci odvodit aplikace bude pomala.