REDGUY: Jo, sorry, tak jsem to i myslel a prislo mi, ze to tak myslite oba. Ten linkovany benchmark uz jsem v myslenkach uplne opustil.

KOJA: Kdyz rikam nanobenchmark tak myslim to, co tady bylo nalinkovany, cili opravdu nano vec, ktera v podstate testuje jednu jedinou funkci v dost trivialnich podminkach. V okamziku, kdy mluvis o "skladani benchmarku", tak uz to imho je neco jineho a k tomu jsem se nevyjadroval.

REDGUY, JANFROG: Myslim, ze to "podobne" asi implicitne myslite oba. Problem syntetickych benchmarku mi prijde dost slozity na to aby byl zajimavy sam o sobe. Nektere "low hanging fruit" jde asi pocesat obecne - napr. knihovna facebook folly ktera "nikdy neni pomalejsi a obvykle je rychlejsi" nez STL implementace v libstdc++. Ale namixovat synteticky benchmark tak, aby byl relevantni a pomohl zvolit statisticky vyhodny kompromis bude asi dost zajimave. Skladat treba benchmark na kterem se otestuji ruzne branch prediction algoritmy pri vyvoji noveho desktopoveho CPU muze byt dost dobra zabava.

XCHAOS: staci -m32

JANFROG: no, můžu se mrknout, co to dělá na noťasu :-)

XCHAOS: na jakou cílovou platformu to kompiluješ: to je dobra poznamka...i386.

Takže v roce 2014 ještě záporné číslo v Céčku bylo menší, než kladné.. a v roce 2016 už není? no to je jen další důkaz, že se světem to jde z kopce a end is near (unless declared far).

JANFROG: divný, použil jsem make bez jakýchkoliv optimalizací a extravuřtů, na téhle archaické platformě:

xchaos@hyperion:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 67
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
stepping : 2
cpu MHz : 2611.979
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 5223.95
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

sice porovnávání různých typů integerů, aniž člověk použije implicitní přetypování, je v C poněkud sázka do loterie (já právě implicitní přetypování čísel, než s nima vůbec začnu něco dělat, celkem i používám...), ale přeci jen: kdyby porovnání longu a unsigned intu nějak často dopadalo tak, jako u tebe, tak mi to přijde celkem nebezpečné (zvlášť pokud má být v céčku napsán třeba firmware pro samořídící auta :-))

K předchozímu:

xchaos@hyperion:~$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

JANFROG: mě to vypsalo tohle:
xchaos@hyperion:~$ ./pokus-compare
===
long a = -1;
unsigned int b = 1;
a == b // -> false
a < b // -> true
a > b // -> false
===
unsigned int a = 1;
long b = 1;
a == b // -> true
a < b // -> false
a > b // -> false

... což, ať se na to koukám z jakéhokoliv úhlu, je asi to, co bych intuitivně čekal, ne? :-)

REDGUY: Jo. sice ne ve vsem myslitelnem ale na (v danem kontextu) relevantnim vzorku. Dneska je dost rozdil mezi tim co napises v kodu a co se doopravdy pousti a je dobre vedet, co kdo dela aby to urychlil...a poucit se z chyb jinych :-)

JANFROG: Garantuji Ti, ze vetsina vyvojari runtimu tehle syntetickych nanobenchmarku pisou, pousti a ladi mraky. - ehm. Takovejch, ve kterejch pousti jednu funkci ve vsem od tcl/tk po c? Urcite?

Sam jsem meril dva systemy, dost podobne - myslim, ze klicove slovo je to "podobne".

REDGUY: Podivej, podobny synteticky nanobenchmarky maji jen mizivou hodnotu....

S tim zasadne nesouhlasim. Ty benchmarky maji zasadni vyznam a nedelat je velka chyba, byt delat zavery ktery system je lepsi je trosku na hlavu (ale to je na hlavu na zaklade jakychkoliv "dat") Garantuji Ti, ze vetsina vyvojari runtimu tehle syntetickych nanobenchmarku pisou, pousti a ladi mraky. Minimalne Oracle, Google a ja :-)

Je to jak rika XCHAOS - trik je v tom, ze tyhle "stupidni" operace se provadeji casto. Sam jsem meril dva systemy, dost podobne a jeden byl v rade bechmarku o pulky rychlejsi. GC velmi podobny, JIT velmiu podobny, rozdil byl v knihovne. Takove blbost jako inteligentni implementace String.indexOf() a podobnych veci muze udelat 30% celkem v klidu...

cim dal tim min podstatny meritko
No ja citim celkem presne opak. Jak v oblasti "velkych" pocitacu kdy SW je stale komplexnejsi a je nutne ho delat za kratsi dobu. Kodu co musi bezet je hodne. Naklady na datova centra a elektrinu jsou vysoke, efektivnejsi system snizuje naklady nebot umozni vetsi hustotu aplikaci.
Na strane druhe, v oblastim "malych"pocitacu je to podobne, but z jinych duvodu. S penetraci pocitacu temer do vseho a nastupem IOT bude cim dal vic SW bezet na chrastitkach co nemaji moc vykonu (ruzna Arduina, RPi, male ARMy). Ne kazda lednicka pobezi na T7.

KILLUA: Vždy mě právě fascinuje... :-) Za vsimnuti take stoji, ze nejvice do krve se hadaji ti programatori, kteri nikdy zadny production-ready jazyk (=compiler+runtime+zakladni knihovna) neimplementovali...mam dojem, ze tady je rovnez pekne videt...

Prostě když je něco 30x pomalejší tak to lepší není a nikdy nebude.
Opravdu?