abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 21:33 | Nová verze

Sway, dlaždicový (tiling) správce oken pro Wayland kompatibilní s i3, byl vydán ve verzi 1.4. Do vývoje se zapojilo 52 vývojářů. Přehled novinek na GitHubu. Zdůraznit lze podporu VNC (wayvnc) nebo částečnou podporu Mate panelu.

Ladislav Hagara | Komentářů: 4
včera 19:55 | Nová verze

Dokumentační tým LibreOffice vydává aktualizovanou příručku pro LibreOffice Math pro verzi LibreOffice 6.4. Update příručky provedl ruský dobrovolník Roman Kuzněcov. Český překladatelský tým hledá další překladatele pro překlad příruček, detaily na wiki.

Zdeněk Crhonek | Komentářů: 0
včera 19:00 | Zajímavý projekt

CutiePi Shell (GitHub) je nové open source uživatelské rozhraní pro mobilní zařízení vytvořené pro tablet CutiePi postavený na Raspberry Pi.

joejoe | Komentářů: 0
včera 11:44 | Nová verze

Vyšla nová verze nástroje pro správu diskových oddílů GParted a distribuce GParted Live, která obsahuje tento a další nástroje pro zálohování či obnovu dat. GParted 1.1.0 aktualizuje překlady a opravuje chyby včetně v např. přesunu uzamknutých šifrovaných oddílů LUKS, výpočtu velikosti souborového systému JFS či rozpoznávání členů ATARAID a jejich stavu. GParted Live 1.1.0-1 pak obsahuje novou verzi GParted, Linux 5.4.13 a vůbec novější balíčky z Debianu Sid.

Fluttershy, yay! | Komentářů: 0
včera 09:55 | Zajímavý článek

Jiří Eischmann se v příspěvku /e/: Android bez Googlu na starém telefonu na svém blogu podělil o zkušenosti s mobilním operačním systémem /e/ (Wikipedie) na telefonu Samsung Galaxy S4 Mini: Pokud hledáte pro svůj androidí telefon systém bez závislosti na Googlu, je to asi ta nejlepší volba.

Ladislav Hagara | Komentářů: 10
21.1. 18:55 | Nová verze

Po roce vývoje od vydání verze 4.0 a více než 7 400 změnách byla vydána nová stabilní verze 5.0 softwaru, který vytváří aplikační rozhraní umožňující chod aplikací pro Microsoft Windows také pod GNU/Linuxem, Wine (Wikipedie). Z novinek lze zdůraznit moduly ve formátu PE, podporu více monitorů, reimplementaci XAudio2 anebo podporu Vulkanu 1.1. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 1
21.1. 15:11 | Zajímavý článek

Michal Altair Valášek publikoval na svém blogu návod MQTT server do kapsy: Mosquitto na Orange Pi Zero na postavení vlastního MQTT (MQ Telemetry Transport) serveru s brokerem Mosquitto postaveného na ARM klonu Debianu Armbian na jednodeskovém počítači za deset dolarů Orange Pi Zero a zabezpečeného pomocí TLS certifikátů od Let's Encrypt a uživatelských jmen a hesel.

Ladislav Hagara | Komentářů: 3
20.1. 17:11 | Nová verze

Vyšlo Pharo 8.0. Přináší lepší nástroje pro refactoring či spoluráci s Gitem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.

Pavel Křivánek | Komentářů: 5
20.1. 13:11 | Pozvánky

Ak pracujete na zaujímavom projekte, zaujíma Vás špecifická téma alebo sa vyznáte o novinkách a trendoch vo svete Pythonu, zdieľajte to s ostatnými. Možnosť prihlásiť sa so svojou témou na PyConSK 2020 je otvorená do 31. 1. 2020.

… více »
RicCo386 | Komentářů: 0
20.1. 10:55 | Komunita

Mozilla.cz informuje (en), že Firefox Preview (kódově Fenix) se blíží svému prvnímu ostřejšímu vydání. Tento zcela nový prohlížeč pro Android nahradí zítra 21. ledna noční verze stávajícího Firefoxu pro Android (kódově Fennec).

Ladislav Hagara | Komentářů: 18
Zdají se vám sny s IT tématikou?
 (9%)
 (1%)
 (13%)
 (17%)
 (53%)
 (7%)
Celkem 253 hlasů
 Komentářů: 10, poslední 18.1. 16:18
Rozcestník

www.AutoDoc.Cz


Vložit další komentář
rADOn avatar 28.5.2007 15:58 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Zaver II:
kdyby si komentujici precetli neco k tematu ( treba http://www.lysator.liu.se/c/duffs-device.html ) mohlo byt na svete zase o par kilobyte zbytecnych reci mene.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
28.5.2007 16:04 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Zaver II:

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.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
28.5.2007 16:22 VM
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Zdravim, abyste mel ze sve prace malinko radost a ukojil Vasi touhu po rychlejsim stroji, tak zde jsou velmi rychle vysledky z PowerPC platformy(bez zadnych zmen v kodu).
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

28.5.2007 16:48 VM
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Prace kvapna malo platna(zajimavy je memcpy test). Vysledky z predchozi konfigurace:
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
28.5.2007 16:58 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()

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...

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
28.5.2007 20:14 VM
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Jsem rad, ze Vas to potesilo. Ano je to RISC 64 bit. IBM_P5. A musim rici ze Vas blog trosku rozpoutal muj zajem o tuto oblast OS, neb jsem timto neposkvrnen.
28.5.2007 18:18 kl
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
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
28.5.2007 22:04 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()

Překvapivé. U Vás není vítězem memcpy(). Jak je to možné?

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
28.5.2007 22:16 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
To nevím, ale je to tak :)
28.5.2007 22:32 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()

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.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
28.5.2007 23:27 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Tak to abychom udělali vlastní fork kernelu :)
29.5.2007 13:29 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
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. :-D

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á :-D

Je tu už i měření Michala Kubečka, kde memcpy() na AMD s drtivou převahou vítězí.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
28.5.2007 17:10 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Kernel poměrně často potřebuje "klonovat stránky" fyzické paměti po copy-on-write faultech. Proto je v něm kopírování delších bloků slušně optimalizováno (funkce copy_page). Kopírování přes 64-bit FPU registry je rychlejší, kopírování pomocí 128-bit SSE registrů je ještě lepší. Tady jsou nějaké benchmarky.

http://lwn.net/Articles/137994/
Táto, ty de byl? V práci, já debil.
Jiří Němec avatar 28.5.2007 20:30 Jiří Němec | skóre: 22 | blog: BluPix | Horní Smrčné
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Linux Oktavo 2.6.21-viper1 #9 SMP PREEMPT Mon May 21 16:36:17 CEST 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux

Nemám dual-channel paměti :-(
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


Spock: "Logic, logic, logic. Logic is the beginning of wisdom, not the end.
Jiří Němec avatar 28.5.2007 20:44 Jiří Němec | skóre: 22 | blog: BluPix | Horní Smrčné
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Omlouvám se, u prvního výsledku -O0 jsem ještě neměl vypnutý ondemand, místo 192 by tam mělo být 149-152. Těch 10 běhů je asi málo.
Spock: "Logic, logic, logic. Logic is the beginning of wisdom, not the end.
28.5.2007 22:16 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
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().

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
Jiří Němec avatar 28.5.2007 22:27 Jiří Němec | skóre: 22 | blog: BluPix | Horní Smrčné
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Tohle je kompletně 64bit.
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)
Spock: "Logic, logic, logic. Logic is the beginning of wisdom, not the end.
Jiří Němec avatar 28.5.2007 21:58 Jiří Němec | skóre: 22 | blog: BluPix | Horní Smrčné
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Má testovací mašina s defaultním debianem, Athlon XP 1700+, 1GB RAM

Linux Mrakoplas 2.6.18-4-k7 #1 SMP Wed Apr 18 10:37:40 UTC 2007 i686 GNU/Linux
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
Spock: "Logic, logic, logic. Logic is the beginning of wisdom, not the end.
28.5.2007 22:20 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()

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. :-D

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
29.5.2007 02:36 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Asi bude záležet na verzi gcc, u mne (gcc 4.1.2, 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).
29.5.2007 12:50 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()

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é. :-)

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
28.5.2007 22:01 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Sekec, mazec, BUM!

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;
}
ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
28.5.2007 23:06 Petr Zelenka | skóre: 24 | Semice/Stuttgart (Sindelfingen)
Rozbalit Rozbalit vše Re: Sekec, mazec, BUM!

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.

A teď si uvědomte, jaký je vztah mezi krychlí a motýlem.
29.5.2007 13:07 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše AMD Duron
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á.
29.5.2007 13:43 peter_h | blog: need4speed
Rozbalit Rozbalit vše Re: Jednoduchý benchmark pro memcpy()
Super test! Len by som chcel dodat k memcpy, ze pokial to nie je intrinsic (alebo ako sa to pise) alebo skompilovane priamo zo zdrojakov tak by bolo dobre vsetky ostatne testy porovnavat s rovnakymi prepinacmi kompilatora ako bola skompilovana libc. Aj tak je ale asi memcpy optibalizovane v asm (na pouzitie sse).

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.