Jeszcze o mikrooptymalizacji

Wojciech Muła

unread,

Dec 29, 2009, 5:45:17 PM12/29/09

to

Parę tygodni temu trafiłem na taką procedurę, nasycającą wartość całkowitą do
przedziału [0, n]:

#define n jakaś_liczba
int clamp(int x) {
if ((unsigned int)x > n) {
if (x < 0) return 0;
if (x > n) return n; // XXX
}
else
return x;
}

Stwierdziłem, że drugi if, oznaczony XXX, jest zbędny i lepiej tam
wrzucić else

if (x < 0) return 0;
else return n;

Gcc 3.4.4 po tej modyfikacji wyprodukował zdecydowanie krótszy kod. Dziś
sprawdziłem w gcc 4.4.cośtam - dla obu wersji kod wynikowy był identyczny
i odpowiadał temu lepszemu z 3.4.4. Jeszcze z ciekawości zamieniłem na
zwykłe porównania ten hack z rzutowaniem:

if (x < 0 || x > n) {
if (x < 0) return 0;
else return n;
}
return x;

Kod wynikowy bez zmian. Dopiero nieco gorzej poszło dla naiwnego:

if (x < 0) return 0;
else if (x > n) return n;
else return x;

w.

PS. zobaczcie, jak gcc realizuje operację x % stała.

--
Z humoru absurdalnego to już wolę Pietrzaka

Maciej Pilichowski

unread,

Dec 30, 2009, 2:30:39 AM12/30/09

to

On Tue, 29 Dec 2009 23:45:17 +0100, Wojciech Muła
<wojcie...@poczta.null.onet.pl.invalid> wrote:

>Kod wynikowy bez zmian. Dopiero nieco gorzej poszło dla naiwnego:
>
> if (x < 0) return 0;
> else if (x > n) return n;
> else return x;

W jakim sensie gorzej? Bo "naiwnie" ;-) patrzac jest tu jeden warunek
mniej.

milego dnia, hej

Sebastian Kaliszewski

unread,

Dec 30, 2009, 5:19:51 AM12/30/09

to

Zapewne dlatego, że najczęstszy przypadek (x zwracany bez zmian)
przechodzi przez dwa warunki a nie jeden. Bez optymalizacji kierowanych
profilowaniem (PGO) kompilator się raczej nie domyśli, że coś z drugiego
else jest przypadkiem najczęstszym.

pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)

twardy C

unread,

Dec 30, 2009, 11:49:44 AM12/30/09

to

‟Wojciech Muła” silnie zaprogramował/a:

nie chce mi się z tym wszystkim męczyć, bo
‣jeśli nie zmuszę kompilatora do pozostawienia ‘statements’ ‟C” w języku
procesora, to je usunie jako zbędne i nic nie zobaczę
‣jeśli wymuszę przy pomocy co najmniej podania jako argumentu jakiejś
stałej i np. wypisania wyniku funkcji, to zoptymalizuje inaczej niż
dla twojej metody wymuszenia pozostawienia funkcji.
ale przy włączonej optymalizacji powinna być wybrana ta sama ścieżka
wykonania, jednak niekoniecznie identyczna, więc niezbyt wierzę w twoje
wywody. ;-)

> PS. zobaczcie, jak gcc realizuje operację x % stała.

tak jak jest optymalniej dla danych parametrów…
--
qo |) CPL<=dataDPL CPL==/>=codeDPL:conform'/nc';max=CPL! AV0ID bHp
_x/ , CPL<=TSS,gateDPL CPL>=/==dest_DPL:/(jmp&nc') ,RPL!- #GP -o0o
| ng __ -- __ -- __ -- __ -- __ -- __ -- __ -- __ -x86-, EV3RY o0o
,__ -- __ -- Current/Requested/DescriptorPrivilegeLevel C/R/DPL , d4y m:#=

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

Paweł

unread,

Dec 30, 2009, 12:15:20 PM12/30/09

to

Wojciech Muła wrote:

> Kod wynikowy bez zmian. Dopiero nieco gorzej poszło dla naiwnego:
>
> if (x < 0) return 0;
> else if (x > n) return n;
> else return x;

gorzej w jakim sensie? ja otrzymalem kod bez skokow.

$ cat clamp.c
int const n = 13;
int clamp( int x)
{
if ( x < 0 ) return 0;
else if ( x > n ) return n;
else return x;
}

$ gcc clamp.c -O2 -S -Wall
$ cat clamp.s
(...)
clamp:
cmpl $13, %edi
movl $13, %edx
cmovle %edi, %edx
xorl %eax, %eax
testl %edx, %edx
cmovns %edx, %eax
ret

gcc-4.4.2-20091026 (x86_64)

Michal

unread,

Dec 30, 2009, 1:36:58 PM12/30/09

to

On Wed, 30 Dec 2009 11:19:51 +0100
Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
wrote:

> Zapewne dlatego, że najczęstszy przypadek (x zwracany bez zmian)

a jak do tego doszedles? Bo jezeli kazda liczba jest rownoprawdopodobna
to to jest najzadszy przypadek.

Wojciech Muła

unread,

Dec 30, 2009, 1:47:58 PM12/30/09

to

Paweł <ro...@127.0.0.1> wrote:

> Wojciech Muła wrote:
>
> > Kod wynikowy bez zmian. Dopiero nieco gorzej poszło dla naiwnego:
> >
> > if (x < 0) return 0;
> > else if (x > n) return n;
> > else return x;
>
> gorzej w jakim sensie? ja otrzymalem kod bez skokow.

Dwa skoki, a w lepszej wersji tylko jeden. Coś mam chyba spieprzoną
konfigurację gcc pod linuxem, bo rzeczywiście to powinno się ładnie
zoptymalizować do przesłań warunkowych.

w.

Paweł

unread,

Dec 30, 2009, 1:55:31 PM12/30/09

to

Wojciech Muła wrote:

hmm, widze, ze -m32/-m64 robi roznice (1 skok )dla kodu,
ktory wrzucilem. wyglada na babol w gcc-u...

Michal

unread,

Dec 30, 2009, 2:09:27 PM12/30/09

to

On Wed, 30 Dec 2009 19:55:31 +0100
Paweł <ro...@127.0.0.1> wrote:

> hmm, widze, ze -m32/-m64 robi roznice (1 skok )dla kodu,
> ktory wrzucilem. wyglada na babol w gcc-u...
>

zglos bug report, a udziele ci bardzo cennej rady(sic!) :)

--

Paweł

unread,

Dec 30, 2009, 2:16:28 PM12/30/09

to

Michal wrote:

kiedys cos mi sie obilo o uszy (@gcc-mailinglist), ze krotki skok @32
na aktualnych prockach jest szybszy od dluzszego szeregu instrukcji.
czyzby, to bylo to?

Michal

unread,

Dec 30, 2009, 2:40:05 PM12/30/09

to

nie to nie to, cos co moze sie skonczyc dla ciebie duzo bardziej
bolesnie.
--

Sebastian Kaliszewski

unread,

Dec 31, 2009, 7:56:04 AM12/31/09

to

Michal wrote:
> On Wed, 30 Dec 2009 11:19:51 +0100
> Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
> wrote:
>
>

>> Zapewne dlatego, ďż˝e najczďż˝stszy przypadek (x zwracany bez zmian)

> a jak do tego doszedles?

Prosto. Taka jest typowa praktyka uďż˝ycia tegotypu konstrukcji.

> Bo jezeli kazda liczba jest rownoprawdopodobna
> to to jest najzadszy przypadek.

Wiesz, najpierw to ta "kaďż˝da liczba" musiaďż˝aby byďż˝ reprezentowalna w
komputerze.

Michal

unread,

Jan 1, 2010, 8:20:42 AM1/1/10

to

On Thu, 31 Dec 2009 13:56:04 +0100
Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
wrote:

> Michal wrote:
> > On Wed, 30 Dec 2009 11:19:51 +0100
> > Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
> > wrote:
> >
> >

> >> Zapewne dlatego, że najczęstszy przypadek (x zwracany bez zmian)

> > a jak do tego doszedles?
>

> Prosto. Taka jest typowa praktyka użycia tegotypu konstrukcji.

Glupie jakies to wytlumaczenie

>
> Wiesz, najpierw to ta "każda liczba" musiałaby być reprezentowalna w
> komputerze.

Jakbys troche pomyslal i obejrzal sygnaturke funkcji to wiedzialbys,
jaka jest dziedzina funkcji, o ktorej mowimy i nie wypisywal bys glupot.

mrbawana2u

unread,

Jan 1, 2010, 11:18:37 PM1/1/10

to

On Dec 30 2009, 1:55 pm, Paweł <r...@127.0.0.1> wrote:
> the turdtapper is never getting out

Sebastian Kaliszewski

unread,

Jan 6, 2010, 5:24:53 AM1/6/10

to

Michal wrote:
> On Thu, 31 Dec 2009 13:56:04 +0100
> Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
> wrote:
>
>> Michal wrote:
>>> On Wed, 30 Dec 2009 11:19:51 +0100
>>> Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
>>> wrote:
>>>
>>>

>>>> Zapewne dlatego, ďż˝e najczďż˝stszy przypadek (x zwracany bez zmian)

>>> a jak do tego doszedles?

>> Prosto. Taka jest typowa praktyka uďż˝ycia tegotypu konstrukcji.
>
> Glupie jakies to wytlumaczenie

Jak doroďż˝niesz programistycznie to moďż˝emy do tej rozmowy wrďż˝ciďż˝.

>
>> Wiesz, najpierw to ta "kaďż˝da liczba" musiaďż˝aby byďż˝ reprezentowalna w

>> komputerze.
>
> Jakbys troche pomyslal i obejrzal sygnaturke funkcji to wiedzialbys,
> jaka jest dziedzina funkcji, o ktorej mowimy i nie wypisywal bys glupot.

Misiu, co ma sygnaturka do twojej "kaďż˝ej liczby".

zatem j.w.

Michal

unread,

Jan 6, 2010, 2:04:28 PM1/6/10

to

On Wed, 06 Jan 2010 11:24:53 +0100
Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
wrote:

> Michal wrote:
> > On Thu, 31 Dec 2009 13:56:04 +0100
> > Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
> > wrote:
> >
> >> Michal wrote:
> >>> On Wed, 30 Dec 2009 11:19:51 +0100
> >>> Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
> >>> wrote:
> >>>
> >>>

> >>>> Zapewne dlatego, że najczęstszy przypadek (x zwracany bez zmian)

> >>> a jak do tego doszedles?

> >> Prosto. Taka jest typowa praktyka użycia tegotypu konstrukcji.
> >
> > Glupie jakies to wytlumaczenie
>
> Jak dorośniesz programistycznie to możemy do tej rozmowy wrócić.

lol, jak nauczysz sie podstaw matematyki to mozesz zaczac bawic sie
BASICiem a pozniej moze nawet jakies skrypty w exelcu.

>
> >
> >> Wiesz, najpierw to ta "każda liczba" musiałaby być reprezentowalna w

> >> komputerze.
> >
> > Jakbys troche pomyslal i obejrzal sygnaturke funkcji to wiedzialbys,
> > jaka jest dziedzina funkcji, o ktorej mowimy i nie wypisywal bys glupot.
>

> Misiu, co ma sygnaturka do twojej "każej liczby".

Jak nauczysz juz sie pisac jakies hello worldy to zainteresuj sie tym
co zwraca funkcja main.

Sebastian Kaliszewski

unread,

Jan 7, 2010, 7:46:29 AM1/7/10

to

Michal wrote:
>>>>>> Zapewne dlatego, ďż˝e najczďż˝stszy przypadek (x zwracany bez zmian)

>>>>> a jak do tego doszedles?

>>>> Prosto. Taka jest typowa praktyka uďż˝ycia tegotypu konstrukcji.
>>> Glupie jakies to wytlumaczenie

>> Jak doroďż˝niesz programistycznie to moďż˝emy do tej rozmowy wrďż˝ciďż˝.

[szczeniackie pohukiwania ciach]

Po prostu ROTFLMAO, kolego bez nazwiska

Widzisz, jakbyďż˝ miaďż˝ jakieďż˝ sensowne doďż˝wiadczenie to byďż˝ wiedziaďż˝, ďż˝e
niezwykle rzadko wykorzystuje siďż˝ peďż˝en zakres danego typu liczbowego, a
zwďż˝aszcza tego najczďż˝ciej w C/C++ uďż˝ywanego, czyli int.

Po drugie, jeďż˝li mďż˝wiďż˝c o rďż˝wnym prawdopodobieďż˝stwie wystďż˝powania liczb
miaďż˝eďż˝ na myďż˝li jakikolwiek ograniczony typ to napisaďż˝eďż˝ bzdurďż˝ -- dla n
bliďż˝szych koďż˝ca zakresu typu niďż˝ 0, przy jednostajnym rozkďż˝adzie
przypadek z ostatniego else wcale nie jest najrzadszy

Po trzecie, to sobie poszukaj hasďż˝a "Prawo Benforda" (to apropos
znajomoďż˝ci matematyki).

Michal

unread,

Jan 7, 2010, 2:13:36 PM1/7/10

to

On Thu, 07 Jan 2010 13:46:29 +0100
Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
wrote:

> napisałeś bzdurę -- dla n
> bliższych końca zakresu typu niż 0, przy jednostajnym rozkładzie

> przypadek z ostatniego else wcale nie jest najrzadszy

Pekam wlasnie ze smiechu.

--

Michoo

unread,

Jan 7, 2010, 5:15:32 PM1/7/10

to

Michal pisze:

> On Thu, 07 Jan 2010 13:46:29 +0100
> Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
> wrote:
>

>> napisaďż˝eďż˝ bzdurďż˝ -- dla n
>> bliďż˝szych koďż˝ca zakresu typu niďż˝ 0, przy jednostajnym rozkďż˝adzie

>> przypadek z ostatniego else wcale nie jest najrzadszy
>
> Pekam wlasnie ze smiechu.
>

Czy mďż˝gďż˝byďż˝ wyjaďż˝niďż˝ "dowcip" teďż˝ tym mniej bystrym grupowiczom? Nie
rozumiem jaki bďż˝ďż˝d popeďż˝niďż˝ Sebastian, a jak wyjaďż˝nisz to moďż˝e bym siďż˝
czegoďż˝ nauczyďż˝?

--
Pozdrawiam
Michoo

Maciej Pilichowski

unread,

Jan 8, 2010, 2:24:13 AM1/8/10

to

On Thu, 07 Jan 2010 13:46:29 +0100, Sebastian Kaliszewski
<s.bez...@remove.this.informa.and.that.pl> wrote:

>Po drugie, je¶li mówi±c o równym prawdopodobieństwie występowania liczb
>miałe¶ na my¶li jakikolwiek ograniczony typ to napisałe¶ bzdurę -- dla n

>bliższych końca zakresu typu niż 0, przy jednostajnym rozkładzie

>przypadek z ostatniego else wcale nie jest najrzadszy

Troche nie rozumiem, bo malo po polsku napisane, ale to nie ma akurat
znaczenia. Nie znamy n, i nie znamy testowanej liczby. Oba przypadki
(2 i 3) sa tak samo mozliwe.

milego dnia, hej

Sebastian Kaliszewski

unread,

Jan 8, 2010, 5:41:24 AM1/8/10

to

Maciej Pilichowski wrote:
>> Po drugie, je¶li mówi±c o równym prawdopodobieństwie występowania liczb
>> miałe¶ na my¶li jakikolwiek ograniczony typ to napisałe¶ bzdurę -- dla n
>> bliższych końca zakresu typu niż 0, przy jednostajnym rozkładzie
>> przypadek z ostatniego else wcale nie jest najrzadszy
>
> Troche nie rozumiem, bo malo po polsku napisane, ale to nie ma akurat
> znaczenia. Nie znamy n, i nie znamy testowanej liczby. Oba przypadki
> (2 i 3) sa tak samo mozliwe.

Przeczytaj założenia kolegi bez nazwiska, cytuję:

[...]jezeli kazda liczba jest rownoprawdopodobna

to to jest najzadszy przypadek.

Dla przypomnienia "dyskutowany" kawałek kodu:

if (x < 0) return 0;
else if (x > n) return n;
else return x;

n jest ustalone. Niech x jest typu T.
Jeśli n >= std::numeric_limits<T>::max() a ponadto mamy powyższe
założenie kolegi bez nazwiska, to przypadek z ostatniego else nie jest
najrzadszy z oczywistego powodu.

Tu warto jeszcze przypomnieć, że w rzeczywistej rzeczywistości założenie
kolegi bez nazwiska zwykle nie jest spełnione. Jaki jest na prawdę
rozkład x to może wie (a może nie) programista, może też uda się lepiej
wcelować używając profilowania. Jeśli zaś z góry wiadomo, że nie wiadomo
(np. piszemy optymalizujący kompilator który m.in taki kod ma
optymalizować i wiemy że PGO nie ma -- bo go nie robimy, albo piszemy
obsługę dla wyłączonej opcji PGO) to statystycznie lepszym wyjściem niż
zakładanie rozkładu jednostajnego po całym zakresie typu jest
skorzystanie z prawa Benforda.
Oczywiście, kiedy mamy PGO (Profile Guided Optimizations) to lepiej
sięgnąć do danych z profilowania.

pzdr

Michal

unread,

Jan 8, 2010, 12:56:28 PM1/8/10

to

On Thu, 07 Jan 2010 23:15:32 +0100
Michoo <micho...@vp.pl> wrote:

> Michal pisze:
> > On Thu, 07 Jan 2010 13:46:29 +0100
> > Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
> > wrote:
> >

> >> napisałeś bzdurę -- dla n
> >> bliższych końca zakresu typu niż 0, przy jednostajnym rozkładzie

> >> przypadek z ostatniego else wcale nie jest najrzadszy
> >
> > Pekam wlasnie ze smiechu.
> >

> Czy mógłbyś wyjaśnić "dowcip" też tym mniej bystrym grupowiczom? Nie
> rozumiem jaki błąd popełnił Sebastian, a jak wyjaśnisz to może bym się
> czegoś nauczył?

kod
int fun(int x, int n)
{

if (x < 0) return 0;
else if (x > n) return n;
else return x;
}

max(int) to maksymalna liczba jaka moze przyjac int
min(int) = -(max(int) + 1) to minimalna liczba jaka moze przyjac int
count(int) = 2 * max(int) + 1

Liczb nieujemnych jest wiec tyle co ujemnych.
n -- bedzie zwykle mniejsze od max(int) bo inaczej nie miala by ta
funkcja zadnego sensu. Tak, wiec zakladajac rozklad rownomierny
zmiennej x lub Benforda, ktorym bezmyslnie probowal wytlumaczys swoj
blad Sebastian Kaliszewski, pierwszy przypadek jest najczestszy, drugi
lub trzeci zalezy od liczby n.

--

Michoo

unread,

Jan 10, 2010, 6:12:56 PM1/10/10

to

Michal pisze:
> On Thu, 07 Jan 2010 23:15:32 +0100
> Michoo <micho...@vp.pl> wrote:
>
>> Michal pisze:
>>> On Thu, 07 Jan 2010 13:46:29 +0100
>>> Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
>>> wrote:
>>>

>>>> napisaďż˝eďż˝ bzdurďż˝ -- dla n
>>>> bliďż˝szych koďż˝ca zakresu typu niďż˝ 0, przy jednostajnym rozkďż˝adzie

>>>> przypadek z ostatniego else wcale nie jest najrzadszy
>>> Pekam wlasnie ze smiechu.
>>>

>> Czy mďż˝gďż˝byďż˝ wyjaďż˝niďż˝ "dowcip" teďż˝ tym mniej bystrym grupowiczom? Nie
>> rozumiem jaki bďż˝ďż˝d popeďż˝niďż˝ Sebastian, a jak wyjaďż˝nisz to moďż˝e bym siďż˝
>> czegoďż˝ nauczyďż˝?
>

> kod
> int fun(int x, int n)
> {
> if (x < 0) return 0;
> else if (x > n) return n;
> else return x;
> }
>
> max(int) to maksymalna liczba jaka moze przyjac int
> min(int) = -(max(int) + 1) to minimalna liczba jaka moze przyjac int

Gwoli ďż˝cisďż˝oďż˝ci - to nie musi byďż˝ prawda. Liczby bez znaku nie muszďż˝ byďż˝
zapisane w dopeďż˝nieniu dwďż˝jkowym.

> count(int) = 2 * max(int) + 1
>
> Liczb nieujemnych jest wiec tyle co ujemnych.

W dziedzinie typu int - tak. Ty zapostulowaďż˝eďż˝ rozkďż˝ad jednostajny w
dziedzinie problemu co jest nieuprawnione. Sebastian Kaliszewski piszďż˝c
o najczďż˝stszym przypadku miaďż˝ na myďż˝li dziedzinďż˝ problemu co ďż˝rednio
inteligentny programista jest w stanie zrozumieďż˝ z kontekstu:
"Bez optymalizacji kierowanych profilowaniem (PGO) kompilator siďż˝ raczej
nie domyďż˝li, ďż˝e coďż˝ z drugiego else jest przypadkiem najczďż˝stszym."

> n -- bedzie zwykle mniejsze od max(int) bo inaczej nie miala by ta
> funkcja zadnego sensu.

Tu juďż˝ sam przyjmujesz jakieďż˝ zaďż˝oďż˝enia co do dziedziny problemu.

> Tak, wiec zakladajac rozklad rownomierny
> zmiennej x lub Benforda, ktorym bezmyslnie probowal wytlumaczys swoj
> blad Sebastian Kaliszewski, pierwszy przypadek jest najczestszy,

Tak.

> drugi lub trzeci zalezy od liczby n.

Tak,ale na argument Sebastiana:

>> Zapewne dlatego, ďż˝e najczďż˝stszy przypadek (x zwracany bez zmian)

Sam napisaďż˝eďż˝:
> a jak do tego doszedles? Bo jezeli kazda liczba jest rownoprawdopodobna

> to to jest najzadszy przypadek.

Co jest nieuprawione. Najrzadszy przypadek przy rozkďż˝adzie jednostajnym to:
drugi dla n > 0
drugi gdy n > max(int)/2
trzeci gdy n < max(int)/2

Wiďż˝c w sumie dowcipu nadal nie dostrzegam.

--
Pozdrawiam
Michoo

Sebastian Kaliszewski

unread,

Jan 11, 2010, 8:06:13 AM1/11/10

to

Michal wrote:
> On Thu, 07 Jan 2010 23:15:32 +0100
> Michoo <micho...@vp.pl> wrote:
>
>> Michal pisze:
>>> On Thu, 07 Jan 2010 13:46:29 +0100
>>> Sebastian Kaliszewski <s.bez...@remove.this.informa.and.that.pl>
>>> wrote:
>>>

>>>> napisaďż˝eďż˝ bzdurďż˝ -- dla n
>>>> bliďż˝szych koďż˝ca zakresu typu niďż˝ 0, przy jednostajnym rozkďż˝adzie

>>>> przypadek z ostatniego else wcale nie jest najrzadszy
>>> Pekam wlasnie ze smiechu.
>>>

>> Czy mďż˝gďż˝byďż˝ wyjaďż˝niďż˝ "dowcip" teďż˝ tym mniej bystrym grupowiczom? Nie
>> rozumiem jaki bďż˝ďż˝d popeďż˝niďż˝ Sebastian, a jak wyjaďż˝nisz to moďż˝e bym siďż˝
>> czegoďż˝ nauczyďż˝?
>

> kod
> int fun(int x, int n)
> {
> if (x < 0) return 0;
> else if (x > n) return n;
> else return x;
> }
>
> max(int) to maksymalna liczba jaka moze przyjac int
> min(int) = -(max(int) + 1) to minimalna liczba jaka moze przyjac int
> count(int) = 2 * max(int) + 1
>
> Liczb nieujemnych jest wiec tyle co ujemnych.
> n -- bedzie zwykle mniejsze od max(int) bo inaczej nie miala by ta
> funkcja zadnego sensu. Tak, wiec zakladajac rozklad rownomierny
> zmiennej x lub Benforda, ktorym bezmyslnie probowal wytlumaczys swoj
> blad Sebastian Kaliszewski, pierwszy przypadek jest najczestszy, drugi
> lub trzeci zalezy od liczby n.

Przeczytaj jeszcze raz co sam napisaďż˝eďż˝... Dla uďż˝atwienia cytujďż˝:

"Bo jezeli kazda liczba jest rownoprawdopodobna to to jest najzadszy
przypadek."

Jak widzisz, sam (w koďż˝cu, po blisko dwu tygodniach, brawo!) doszedďż˝eďż˝,
ďż˝e to nie jest prawda, nawet przy zaďż˝oďż˝eniu ďż˝e "kaďż˝da liczba jest
rďż˝wnoprawdopodobna".

Ja napisaďż˝em...

"Zapewne dlatego, ďż˝e najczďż˝stszy przypadek (x zwracany bez zmian)

przechodzi przez dwa warunki a nie jeden. Bez optymalizacji kierowanych

profilowaniem (PGO) kompilator siďż˝ raczej nie domyďż˝li, ďż˝e coďż˝ z drugiego
else jest przypadkiem najczďż˝stszym. "

I na pytanie skďż˝d wiem odpisaďż˝em:

"Taka jest typowa praktyka uďż˝ycia tegotypu konstrukcji. "

Otďż˝, dzieciďż˝ drogie, dyskutowana konstrukcja to typowe "nasycenie
arytmetyczne" -- w praktyce tak siďż˝ to stosuje by gross wynikďż˝w trafiaďż˝a
pomiďż˝dzy kraďż˝ce przedziaďż˝u a nie byďż˝a obcinana. Wyniki obciďż˝te niosďż˝
tylko takďż˝ informacjďż˝, ďż˝e sďż˝ obciďż˝te -- sďż˝ wiďż˝c maďż˝o ciekawe. Zwykle
sytuacja gdy wiďż˝kszoďż˝ďż˝ wynikďż˝w jest obcinanna jest sytuacjďż˝
patologicznďż˝. W niepatologicznym przypadku to wďż˝aďż˝nie zwykle drugi else
jest tym przypadkiem najczďż˝stszym.

No, ale ďż˝eby to wiedzieďż˝, trzeba trochďż˝ w ďż˝yciu kodu napisaďż˝ i jescze
trochďż˝ zobaczyďż˝