Společnost Anthropic oznámila Projekt Glasswing a s ní související AI model Claude Mythos Preview. Jedná se o iniciativu zaměřenou na kybernetickou bezpečnost, do které se zapojily velké technologické společnosti Amazon Web Services, Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA a Palo Alto Networks. Anthropic věří, že nový AI model Claude Mythos Preview dokáže
… více »Firma Ojective Development vydala svůj nástroj pro monitorování a řízení odchozích síťových připojení Little Snitch i pro operační systém Linux. Linuxová verze se skládá ze tří komponent: eBPF program pro zachytávání provozu a webové rozhraní jsou uvolněny pod GNU GPLv2 a dostupné na GitHubu (převážně Rust a JavaScript), jádro backendu je proprietární pod vlastní licencí, nicméně zdarma k použití a redistribuci (cena přitom normálně … více »
Vojenské zpravodajství (VZ) se v březnu zapojilo do mezinárodní operace proti aktivitám hackerské skupiny APT28, která je spojovaná s ruskou vojenskou zpravodajskou službou GRU a která přes slabě zabezpečené routery prováděla kybernetické útoky na státní a další organizace v ČR i zahraničí. Operaci vedl americký Federální úřad pro vyšetřování (FBI) a jejím cílem bylo odebrat útočníkům přístup k napadeným zařízením a ty následně … více »
Tvůrcem nejpopulárnější kryptoměny bitcoin, který se skrývá za pseudonymem Satoši Nakamoto (Satoshi Nakamoto), je britský kryptograf Adam Back. Na základě vlastní investigativní práce to tvrdí americký deník The New York Times (NYT). Několik indicií podle autorů jasně ukazuje na to, že Back a Nakamoto jsou stejný člověk. Jde mimo jiné o podobný odborný a osobnostní profil či totožné chyby a manýry v psaném projevu.
Google Chrome 147 byl prohlášen za stabilní. Nejnovější stabilní verze 147.0.7727.55 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře. Přehled novinek v Chrome DevTools 145 až 147 také na YouTube.
Vývojáři z Laboratoří CZ.NIC vydali nové verze aplikací Datovka (Datovka 4.29.0, Mobilní Datovka 2.6.2). V případě desktopové verze přibyly možnosti projít všechny uložené zprávy, zkontrolovat časy expirací časových razítek a přerazítkovat datové zprávy, které lze v ISDS přerazítkovat. Novinkou je také možnost vytahovat myší ze seznamu ZFO soubory datových zpráv, tento úkon jde udělat i pomocí tlačítek Ctrl+C. Nová verze Mobilní Datovky přináší jen drobné úpravy.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.28.0. Z novinek lze vypíchnout novou třídu machine.CAN.
Michael Meeks, CEO společnosti Collabora, na apríla oznámil, nebyl to ale apríl, že nadace The Document Foundation zastřešující vývoj kancelářského balíku LibreOffice vyloučila ze svých řad všechny zaměstnance a partnery společnosti Collabora, tj. více než třicet lidí, kteří po mnoho let přispívali do LibreOffice. Nadace The Document Foundation po několika dnech publikovala oficiální vyjádření. Přiznává pochybení při zakládání
… více »Protože je už po aprílu, můžou strahováci opět zveřejnit program další Virtuální Bastlírny, aniž by připravená témata působila dojmem, že jde o žert. Vězte tedy, že v úterý 14. dubna (změna!!!) od 20:00 proběhne VB, kde se setkají bastlíři, technici, učitelé i nadšenci do techniky a kde i vy se můžete zapojit do družného hovoru, jako by všichni seděli u pomyslného piva. Co mají bastlíři tento měsíc na srdci? Pravděpodobně by nás musel zasáhnout
… více »Byla vydána verze 26.1 aneb čtvrtletní aktualizace open source počítačového planetária Stellarium (Wikipedie, GitHub). Vyzkoušet lze webovou verzi Stellaria na Stellarium Web.
To sice jo, ale i dávno vyřešené věci někdy neuškodí prodiskutovat znova. Právě proto, že se řešily dávno.
pocitac: IBM p550-v lparu je dedikovan 1 dualcorovy p5+ procesor suse-tftp:/tmp/memtest # cat /proc/cpuinfo processor : 0 cpu : POWER5+ (gs) clock : 1648.350000MHz revision : 3.1 (pvr 003b 0301) processor : 1 cpu : POWER5+ (gs) clock : 1648.350000MHz revision : 3.1 (pvr 003b 0301) timebase : 512365000 machine : CHRP IBM,9133-55A suse-tftp:/tmp/memtest # cat /etc/SuSE-release SUSE Linux Enterprise Server 10 (ppc) VERSION = 10 g++ optimalizace: -Wall -O3 -pipe Average time: 33.70 bez optimalizace: Average time: 160.10
G++ (bez optimalizace)
-----------------------
Standard memcpy() Average time: 45.90
Offset-driven copy test (bytes) Average time: 1713.40
Offset-driven copy test (ints) Average time: 583.30
Offset-driven copy test ('long long's) Average time: 218.60
Pointer-driven copy test (bytes) Average time: 1206.90
Pointer-driven copy test (ints) Average time: 265.40
Pointer-driven copy test ('long long's) Average time: 156.60
Special 'modulo' copy test (bytes) Average time: 1791.40
Special 'modulo' copy test (ints) Average time: 390.00
Special 'modulo' copy test ('long long's) Average time: 160.00
G++(-Wall -O3 -pipe)
--------------------------
Standard memcpy() test Average time: 46.10
Offset-driven copy test (bytes) Average time: 250.80
Offset-driven copy test (ints) Average time: 128.30
Offset-driven copy test ('long long's) Average time: 39.20
Pointer-driven copy test (bytes) Average time: 252.10
Pointer-driven copy test (ints) Average time: 128.40
Pointer-driven copy test ('long long's) Average time: 39.20
Special 'modulo' copy test (bytes) Average time: 137.30
Special 'modulo' copy test (ints) Average time: 41.60
Special 'modulo' copy test ('long long's) Average time: 33.60
Je pro mě příjemným překvapením, že ta moje slátanina šla vůbec zkompilovat a spustit na jiné architektuře.
Každopádně děkuji za velmi zajímavý výsledek. Knihovní memcpy je u Vás asi napsaná komplet v assembleru, když jí optimalizace škodí...
Pointer-driven copy test (ints) Average time: 128.40
Pointer-driven copy test ('long long's) Average time: 39.20
Promiňte mi hloupou otázku: Ten stroj je 64-bitový? Jinak si neumím vysvětlit tak velký nárůst rychlosti při použití long long...
G++ (bez optimalizace)
-----------------------
Standard memcpy() Average time: 271.10
Offset-driven copy test (bytes) Average time: 867.70
Offset-driven copy test (ints) Average time: 262.10
Offset-driven copy test ('long long's) Average time: 180.90
Pointer-driven copy test (bytes) Average time: 814.60
Pointer-driven copy test (ints) Average time: 251.10
Pointer-driven copy test ('long long's) Average time: 182.20
Special 'modulo' copy test (bytes) Average time: 779.50
Special 'modulo' copy test (ints) Average time: 243.90
Special 'modulo' copy test ('long long's) Average time: 174.20
G++ (-O2 -march=athlon-xp -pipe -mcpu=i686 -fomit-frame-pointer -msse -mmmx -m3dnow -ffast-math -fprefetch-loop-arrays
-finline-limit=600 -ftracer)
-----------------------
Standard memcpy() Average time: 244.90
Offset-driven copy test (bytes) Average time: 998.20
Offset-driven copy test (ints) Average time: 287.40
Offset-driven copy test ('long long's) Average time: 198.60
Pointer-driven copy test (bytes) Average time: 896.50
Pointer-driven copy test (ints) Average time: 267.60
Pointer-driven copy test ('long long's) Average time: 190.10
Special 'modulo' copy test (bytes) Average time: 814.00
Special 'modulo' copy test (ints) Average time: 258.40
Special 'modulo' copy test ('long long's) Average time: 183.40
Překvapivé. U Vás není vítězem memcpy(). Jak je to možné?
To je divné. Týká se to dokonce i 32-bitových Athlonů, jak je vidět o kus níž. Jestli se používá často memcpy i v kernelu...
[andrej@xandrej linux]$ grep -R memcpy * | wc -l 9318
...tak to je potom smutné. Takže procesory AMD asi nejsou využité tak dobře, jak by mohly být.
Tak to abychom udělali vlastní fork kernelu :)
A ten by spočíval v rekurzivním průchodu stromem a nahrazení všech memcpy() něčím jiným. 
Zjistil jsem, že kernelu se případný problém netýká. Má totiž vlastní implementaci knihoven pro každou architekturu zvlášť. Kompilují se různé jejich části podle toho, jaké možnosti má cílový procesor. Je to k vidění například zde:
[andrej@popelnice linux]$ ls arch/i386/lib/mem* arch/i386/lib/memcpy.c [andrej@popelnice linux]$ ls arch/x86_64/lib/mem* arch/x86_64/lib/memcpy.S arch/x86_64/lib/memmove.c arch/x86_64/lib/memset.S
Používají se tam i poměrně nové sady instrukcí, takže uživatel může být klidný, že strhujícím výkonem jeho stroje nikdo neplýtvá 
Je tu už i měření Michala Kubečka, kde memcpy() na AMD s drtivou převahou vítězí.
1.-O0
2.-Os -march=athlon64 -msse3 -pipe
3.-O3 -march=athlon64 -msse3 -pipe
4.-O3 -march=athlon64 -mtune=athlon64 -msse3 -pipe -falign-functions=4
-fprefetch-loop-arrays -fomit-frame-pointer
1 2 3 4
Standard memcpy() test 192.80 150.60 56.30 54.90
Offset-driven copy test (bytes) 755.40 257.70 206.80 224.60
Offset-driven copy test (ints) 222.70 108.80 94.20 73.40
Offset-driven copy test ('long long's) 132.50 88.30 71.40 70.30
Pointer-driven copy test (bytes) 707.80 207.20 204.30 224.60
Pointer-driven copy test (ints) 213.30 96.00 97.80 68.30
Pointer-driven copy test ('long long's) 128.30 76.20 73.20 66.40
Special 'modulo' copy test (bytes) 671.00 141.70 146.30 146.10
Special 'modulo' copy test (ints) 206.20 87.40 83.90 83.60
Special 'modulo' copy test ('long long's) 124.80 75.00 71.50 70.80
Těch 10 běhů je asi málo.
Taky se tu nesnažíme o nějakou velkou přesnost.
Funkce test_run() má parametr repeat, kterým lze počet běhů nastavit. Taky jsem musel vypnout ondemand. 
Překvapuje mě, že na AMD64 není memcpy() vítězem. Není tam náhodou 32-bitový kernel nebo alespoň 32-bitové knihovny? To by bylo jediné možné vysvětlení, proč může být tento kód rychlejší než memcpy().
ldd test
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu
/4.1.2/libstdc++.so.6 (0x00002b3c41d78000)
libm.so.6 => /lib/libm.so.6 (0x00002b3c41f76000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b3c420cb000)
libc.so.6 => /lib/libc.so.6 (0x00002b3c421d9000)
/lib64/ld-linux-x86-64.so.2 (0x00002b3c41c5b000)
1.-O0
2.-O2 -march=athlon-xp -pipe -fomit-frame-pointer -msse -mmmx -m3dnow
-ffast-math -fprefetch-loop-arrays -finline-limit=600 -ftracer
3.-Os -march=athlon-xp -pipe
4.-O3 -march=athlon-xp -pipe
1 2 3 4
Standard memcpy() test 220.70 163.90 169.10 164.10
Offset-driven copy test (bytes) 964.70 319.50 288.20 266.60
Offset-driven copy test (ints) 288.20 127.00 174.90 185.40
Offset-driven copy test ('long long's) 218.90 145.70 144.00 145.70
Pointer-driven copy test (bytes) 915.90 286.50 296.90 266.50
Pointer-driven copy test (ints) 274.60 133.60 176.40 165.60
Pointer-driven copy test ('long long's) 217.70 145.20 163.90 145.00
Special 'modulo' copy test (bytes) 868.50 242.10 226.70 227.40
Special 'modulo' copy test (ints) 258.00 163.60 164.40 156.60
Special 'modulo' copy test ('long long's) 218.70 144.30 143.00 144.30
Ale tohle je 32-bitový stroj, že jo? Takže to s tím memcpy() je fakt záhada. Připadá mi, jako by tvůrci knihoven věnovali víc pozornosti Intelu na úkor AMD. Ani v jednom případě není memcpy() vítězem. To je do očí bijící rozdíl. V procesorech AMD se skrývá nějaký tajemný nevyužitý potenciál. 
CXXFLAGS='-march=k8 -m64 -O3 -fomit-frame-pointer') je na Athlon64 3500+ memcpy() zřetelně nejrychlejší (kolem 40), pak následují všechny verze používající typ long long (77-78).
Nejspíš má tedy problém jen některá verze na některých strojích. Nechtělo se mi věřit, že by byla opravdu memcpy() obecně pro AMD pomalá. Už přece musely proběhnout tisíce benchmarků, mnohem podrobnějších a přesnějších než ten můj. (A kdyby se na něco takového přišlo, bylo by to už před lety v knihovnách opraveno.) I tak jsou výsledky zajímavé. 
Hádejte, kdy ten můj benchmark hodí segmentation fault! 
Stane se to tehdy, když uděláte na Intelu spccpy< long double >(). Napřed se mi to zdálo podivné, ale počítač má vždycky pravdu:
Jest totiž sizeof( long double ) == 12. (Pentium M, Linux, GCC) Dále jest MEMSIZE / 12 == 8333333, což zjevně není násobkem osmi. Proto v tom while cyklu podteče proměnná bytes do velkých čísel. Je totiž bezznaménková. 
Jsou dvě možnosti řešení:
Nastavit si MEMSIZE = 120000000u. Pak bude MEMSIZE / 12 násobkem 8.
Nikdy nepoužívat unsigned proměnnou jako řídící proměnnou cyklu. Tuto poučku jsem stokrát slyšel, stokrát porušil a stokrát jsem si nabil nos.
Blogpost raději ponechávám v původní podobě, protože většina lidí nebude chtít testovat dvanáctibytové datové typy.
Navíc bych tím znehodnotil výsledky, které mi tu už někteří z vás ochotně napsali.
Testoval jsem důkladně rychlost kopírování v plovoucí rádové čárce. Zdá se mi, že na procesorech Intel v tom vůbec není rozdíl. Jediné, co hraje roli, je velikost proměnné. Procesory Intel totiž mají univerzální registry pro různé typy dat. Možná by ale na jiném procesoru byla situace jiná. S upraveným MEMSIZE mám takovouhle funkci main():
int main( void ) {
struct memcpy_test tests[ 19 ];
tests[ 0 ].test_name = "Standard memcpy() test";
tests[ 0 ].memcpy_function = std_memcpy;
tests[ 1 ].test_name = "Offset-driven copy test (bytes)";
tests[ 1 ].memcpy_function = func_type( pluscpy, char );
tests[ 2 ].test_name = "Offset-driven copy test (ints)";
tests[ 2 ].memcpy_function = func_type( pluscpy, int );
tests[ 3 ].test_name = "Offset-driven copy test ('long long's)";
tests[ 3 ].memcpy_function = func_type( pluscpy, long long );
tests[ 4 ].test_name = "Pointer-driven copy test (bytes)";
tests[ 4 ].memcpy_function = func_type( endcpy, char );
tests[ 5 ].test_name = "Pointer-driven copy test (ints)";
tests[ 5 ].memcpy_function = func_type( endcpy, int );
tests[ 6 ].test_name = "Pointer-driven copy test ('long long's)";
tests[ 6 ].memcpy_function = func_type( endcpy, long long );
tests[ 7 ].test_name = "Special 'modulo' copy test (bytes)";
tests[ 7 ].memcpy_function = func_type( spccpy, char );
tests[ 8 ].test_name = "Special 'modulo' copy test (ints)";
tests[ 8 ].memcpy_function = func_type( spccpy, int );
tests[ 9 ].test_name = "Special 'modulo' copy test ('long long's)";
tests[ 9 ].memcpy_function = func_type( spccpy, long long );
tests[ 10 ].test_name = "Offset-driven copy test (floats)";
tests[ 10 ].memcpy_function = func_type( pluscpy, float );
tests[ 11 ].test_name = "Offset-driven copy test (doubles)";
tests[ 11 ].memcpy_function = func_type( pluscpy, double );
tests[ 12 ].test_name = "Offset-driven copy test ('long double's)";
tests[ 12 ].memcpy_function = func_type( pluscpy, long double );
tests[ 13 ].test_name = "Pointer-driven copy test (floats)";
tests[ 13 ].memcpy_function = func_type( endcpy, float );
tests[ 14 ].test_name = "Pointer-driven copy test (doubles)";
tests[ 14 ].memcpy_function = func_type( endcpy, double );
tests[ 15 ].test_name = "Pointer-driven copy test ('long double's)";
tests[ 15 ].memcpy_function = func_type( endcpy, long double );
tests[ 16 ].test_name = "Special 'modulo' copy test (floats)";
tests[ 16 ].memcpy_function = func_type( spccpy, float );
tests[ 17 ].test_name = "Special 'modulo' copy test (doubles)";
tests[ 17 ].memcpy_function = func_type( spccpy, double );
tests[ 18 ].test_name = "Special 'modulo' copy test ('long doubles's)";
tests[ 18 ].memcpy_function = func_type( spccpy, long double );
if ( !test_alloc( MEMSIZE ) ) { return 1; };
test_run( tests, 19, 10 );
test_free();
return 0;
}
Nemyslím si, že požívat unsigned proměnnou v řídící části cyklu je hřích. Naopak, ve chvíli, kdy přičítáte, my přijde jako velice vhodné přičítat do unsigned. Při odčítání je to ale jiná káva.
Linux album 2.6.21-gentoo-r2 #1 PREEMPT Fri May 25 11:39:18 CEST 2007 i686 AMD
Duron(tm) processor AuthenticAMD GNU/Linux
gcc (GCC) 4.1.2 (Gentoo 4.1.2)
1. g++ -Wall -O0
2. g++ -Wall -march=athlon-tbird -O3 -pipe -fomit-frame-pointer
1. 2.
Standard memcpy() test 660.30 386.80
Offset-driven copy test (bytes) 1882.60 736.00
Offset-driven copy test (ints) 688.90 377.30
Offset-driven copy test ('long long's) 671.00 352.60
Pointer-driven copy test (bytes) 1849.40 734.00
Pointer-driven copy test (ints) 795.90 378.70
Pointer-driven copy test ('long long's) 637.10 365.00
Special 'modulo' copy test (bytes) 1790.80 698.80
Special 'modulo' copy test (ints) 795.10 366.40
Special 'modulo' copy test ('long long's) 667.40 363.50
Není to tak zřetelné, ale memcpy také propadá.
Tiskni
Sdílej: