Mariusz Marszałkowski pisze:
> On 18 Lut, 10:20, Qbab <b...@p...onet.pl> wrote:
>> W dniu 2010-02-11 08:57, Wojciech "Spook" Sura pisze:
>>
>>> Bastion wrote:
>>>> Kolego, ja tak nie pisze tylko przedstawiam rozwiazanie pewnego
>>>> problemu. Laskawie pochyl glowe i zastanow sie jak w 5 linijkach kodu
>>>> lepiej mozna zwizualizowac rozwiazanie. Czekam na kod...
>>> Zacznijmy od tego, że nawet nie zabierałbym się do projektowania aplikacji
>>> myśląc panicznie, żeby zmieścić się w n linijkach. Płacisz podatek od każdej
>>> napisanej linii kodu? Jeśli radość sprawia Ci upychanie programu w
>>> niewielkiej przestrzeni, to raczej wyślij Twój pomysł na IOCCC niż chwal się
>>> na grupach.
>> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
>> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
>> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował w
>> czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)
>
> Koniecznosc upychania danych w bity jest caly czas akualna. Oczywiscie
> tylko tam, gdzie wazna jest wydajnosc. Propoponuje zmierzenie czasu
> wykonania tego kodu dla roznych wielkosci S. Parametr N zostaje taki
> sam, wiec ilosc operacji nie ulega zmianie, zmianie ulega tylko
> rozmiar
> danych. Duze S oznacza dane nie upakowane, male S oznacza dane
> upakowane do malej tablicy.

Tu czytasz dane i to w najgorszy możliwy sposób - dostęp losowy. Odwrócę
kota ogonem - na 8 Xeonach:
$time ./kolo_siebie
real 0m16.903s
user 1m52.579s
sys 0m0.188s
$ time ./oddalone
real 0m1.955s
user 0m7.848s
sys 0m0.000s

To jest dokładnie ten sam kod, ale w jednym wypadku dane upakowane i
false-sharing daje o sobie znać, w drugim nie.


--
Pozdrawiam
Michoo