Użytkownik "bartekltg" <b...@g...com> napisał:

> >>> Przed Cooleyem-Tukeyem roslo wykladniczo, a potem liniowo.
>
> Nie, nigdy nie rodło wykładniczo;>

Nie no jasne.
To byla takie sobie "beletrystyczne" moje powiedzenie, a nie jakies scisle
matematyczne podejscie. Naprawde kiedys znalem sie nieco (jak na niematematyka)
na transformatach okolo-Fourierowych bo temat mej niedoszlej pracy mgr
zawieral cus w rodzaju:
".. metotą rozplatania widm rentgenowskich narzędziami analizy widmowej..".
Oczywiscie masz racje, ze okolo-kwadratowo (w stosunku do ilosci probek).

> To prawda. Ale nigdy nie był on wykładniczy, więc
> myślałem, ze masz na myśli jeszcze co innego.

Nie nie. J/w . Zwykla moja niedokladnosc i "niedojezyczenie": :)

AK

do góry

Dnia Tue, 16 Apr 2013 01:47:41 -0700 po głębokim namyśle M.M. rzekł:
> W dniu poniedziałek, 15 kwietnia 2013 23:23:50 UTC+2 użytkownik Edek
> napisał:
>> A dlaczego ta ma być intuicjonistyczna? Kolejne słowo, które jednak
>> jest dość subiektywne.
> Właśnie mało ścisły temat, trudno powiedzieć co jest intuicyjne, co jest
> zepsute, a już w ogóle nie wiadomo co jest optymalne. Za tym ze ta jest
> intuicyjna przemawia fakt, że wielu programistów do problemu podeszło w
> podobny sposób. Potem każdy z nich dodał jakieś usprawnienia. W dalszej
> kolejności ktoś zebrał pomysły wielu ludzi i zaimplementował w jednym
> programie. Dopiero w jeszcze dalszej były próby reprezentacji bitowej, a
> z powodu znanych usprawnień do reprezentacji tablicowej, reprezentacja
> bitowa wypadała gorzej, zwłaszcza na 32bitowych komputerach. Różne
> sprytne usprawnienia do reprezentacji bitowej pojawiły się stosunkowo
> niedawno, a już naprawdę świeża jest próba zebraniach wszystkich
> usprawnień w jednym programie. Jeśli dla Ciebie, jako dla jednego
> programisty, jest to intuicyjny proces, to oznacza, że jesteś lepszy od
> tych wszystkich programistów razem wziętych, którzy przyczynili się do
> obecnego poziomu reprezentacji bitowej.

Jedyną metodą sprawdzenia byłoby poświęcenie mnóstwa czasu programom
szachowym, przeze mnie oczywiście. Nie planuję. Mówię to dlatego,
że strasznie się przyczepiłeś do tych szachów i na tej podstawie
generalizujesz na optymalizację każdego kodu. A tak nie jest,
i to nawet po odrzuceniu "przekładania dokumentów z kupki na kupkę"
czy "relacyjnego mapowania rzeczywistości na projektowanie obiektowe"
(czyli mamy dokumenty A, B i C i dzielimy na kupki A+B i C plus
dodatkowe ze stemplem i radzimy sobie z wykładniczą eksplozją kombinacji
myśląc wtedy w przerwie pomiędzy kodowaniem kolejnych kupek).

Ja na przykład aktualnie pracuję nad kodem analizującym dane (np. grafy)
i jedyną opcją jest optymalizowanie w obrębie Javy - np. kolekcje double
a nie Double, rozmieszczenie danych, itd. - i ewentualnie C++. A jest tak
dlatego, że nikt nie ma zamiaru pisać osobno kodu dla Win32, Win64,
SPARC, jakieś Power i potencjalnie innych. Już C++ wymaga odpowiedniego
wysiłku, żeby na wszystkim utrzymywać działający build. Powiedz mi
co w takim środowisku oznaczać miałoby określenie "optymalne".

> Rozumiem że "strasznie" używasz w znaczeniu "implementacja zepsuta".
> Wiele osób taką reprezentację podało jako pierwszy pomysł. Po
> zastanowieniu podali różne usprawnienia. A po próbach z reprezentacją
> bitową program działał wolniej...

Wiesz, kluski z serem też da się spaprać a nie są szczytem sztuki
kulinarnej.

>> czy taki kod szachowy uwzględnia domyślną liczbę bierek czy też głównym
>> nurtem idą różne nieco egzotyczne sytuacje typu - powiedzmy - trzy
>> wieże po jednej stronie?
> Trzy wieże po jednej stronie to akurat nie egzotyczna sytuacja - ale to
> mało ważne w naszej dyskusji. To jest po prostu kod rozsądny, jaki
> zaproponuje na początku wielu programistów. Niektórzy dodadzą jakieś
> usprawnienie, niektórzy kilka usprawnień, jedna osoba raczej nie dojdzie
> sama do wszystkich znanych technik.

Znajdź mi partię z trzema białymi wieżami na szachownicy.

To że w tej dziedzinie wiedza się akumuluje nie jest niczym nadzwyczajnym.
To że przy okazji akumulują się pośledniejsze pomysły też nie. Jak sam
zauważyłeś pośledniejsze z czasem okazują się czasami lepsze, bo
optymalizacja nie jest minimalizacją po gradiencie (niestety).

> Ale to jest malutki przykładzik. Z reprezentacją bitową są inne problemy
> i jest tych problemów znacznie więcej niż z reprezentacją tablicową.
> Naiwne zakodowanie na reprezentacji bitowej z powodu innych problemów
> działa gorzej niż wyśrubowana implementacja na tablicy pól/bierek.

Czyli: optymalizacja jednak algorytmiczna.

>> Patrząc na szchownicę widzi się właśnie całe formy ruchów a nie
>> kombinuje które pole jest które i czy wieża z damą się bronią nawzajem,
>> czy tylko król wraz z damą obstawia wieżę, ta pierwsza po przekątnej.
>> Podobnie z wymianami.
> Taki sam efekt daje zarówno iterowanie w jakimś kierunku szachownicy
> jaki i test maskami bitowymi. Chodzi o to, która implementacja jest
> szybsza.

Tobie o to chodzi, ja mówiłem o intuicyjności. W sensie "relacyjnego
mapowania sposobu myślenia na kod" ;).

Jasne, ostatecznie liczy się szybkośc działania a nie intuicyjność
kodu.

>> > Napiszę jeszcze raz to samo, może programistom często się tylko
>> > wydaje że są w okolicach tych 10% od optimum?
>>
>> Może Tobie się wydaje, że każdy kod można przyspieszyć 2-4x?
> Nie chodzi o to co mi się wydaje, tylko o to co widziałem. A widziałem
> jak wielu programistów podeszło do problemu. Ich podejście było na oko
> 2-4 razy gorsze niż optymalne.

Wiesz, widziałem takich, którzy na podwójne kseony napisali
program wielowątkowy tak, że jeden wątek działał a inne czekały.
Czy to czegoś tak ogólnie dowodzi? Bo ja "widziałem".

>> Cieszę się Twoim szczęściem, ale skąd pomysł, że wszyscy mają wciąż
>> oczy zamknięte? Używanie masek bitowych robię "z zamkniętymi oczami".
> To nie pomysł, to obserwacja. I nie na wszystkich, ale na pewnej próbie
> :) Każdy może wziąć jakieś zadanie programistyczne, napisać swoją
> implementację, a dopiero potem porównać z najlepszą znaną implementacją
> na świecie. Jaki odsetek programistów będzie w 10% od najlepszej znanej
> ( 10% od najlepszej znanej, to niekoniecznie 10% od optymalnej ).

Niemożliwe do sprawdzenia. Do sprzwdzenia możliwe tylko jeżeli M$
będzie porównywał .Net do reszty świata, czyli Perla, Pythona
i co tam jeszcze jest najwolniejsze na świecie - wtedy będzie
odpowiedni wynik badania.

> U mnie trening działał. Gdy regularnie grywałem, to z miesiąca na
> miesiąc grałem lepiej. Gdy odstawiałem szachy na dłuższy czas, to znowu
> grałem słabo. Potem interesowałem się tylko szachami komputerowymi.

Ja to faktycznie lubiłem, nie musiałem "trenować". Dzisiaj wciąż lubię,
ale preferuję rozgrywkę po łyskaczu :).

--
Edek

do góry

On Wednesday, April 17, 2013 12:36:30 AM UTC+2, Edek Pienkowski wrote:
> Jedyną metodą sprawdzenia byłoby poświęcenie mnóstwa czasu programom
> szachowym, przeze mnie oczywiście. Nie planuję. Mówię to dlatego,
> że strasznie się przyczepiłeś do tych szachów
Przyczepiłem się bo jest to działka w której dużo czasu poświęciłem na
poprawę implementacji i mini-algorytmów, ale także jest to taka działka, w
której mogłem się przyjrzeć jak to robiło wielu innych programistów - po
prostu dla tej działki mam dane.


> i na tej podstawie generalizujesz na optymalizację każdego kodu.
Wiem że taka generalizacja ma wady, ale nie mam danych z innych
dziedzin, nie mogę zrobić nic lepszego niż generalizowanie. Pytanie czy
te wady są istotne? Szachy to inny program niż np. symulowanie białek. Ale
czy w procesie optymalizowania kodu, szukania mikro-algorytmów,
kombinowania z alternatywnymi strukturami danych, programiści w innych
dziedzinach nie przebyli podobnej drogi? - To nie jest pytanie
retoryczne, mam nadzieję że ktoś coś napisze.


> A tak nie jest,
Właśnie nie wiem czy tak nie jest, może w dużym stopniu tak jest?


> i to nawet po odrzuceniu "przekładania dokumentów z kupki na kupkę"
> czy "relacyjnego mapowania rzeczywistości na projektowanie obiektowe"
> (czyli mamy dokumenty A, B i C i dzielimy na kupki A+B i C plus
> dodatkowe ze stemplem i radzimy sobie z wykładniczą eksplozją kombinacji
> myśląc wtedy w przerwie pomiędzy kodowaniem kolejnych kupek).
Hmmmm



> Ja na przykład aktualnie pracuję nad kodem analizującym dane (np. grafy)
> i jedyną opcją jest optymalizowanie w obrębie Javy - np. kolekcje double
> a nie Double, rozmieszczenie danych, itd. - i ewentualnie C++. A jest tak
> dlatego, że nikt nie ma zamiaru pisać osobno kodu dla Win32, Win64,
> SPARC, jakieś Power i potencjalnie innych. Już C++ wymaga odpowiedniego
> wysiłku, żeby na wszystkim utrzymywać działający build.
Czyli typowa sytuacja której nikt nie neguje, zwykle nie opłaca się
optymalizować, zwłaszcza gdy chodzi o optymalizowanie implementacji.


> Powiedz mi co w takim środowisku oznaczać miałoby określenie "optymalne".
Ja nie wiem, pisałem post wcześniej, że nikt w ogóle nie wie jaka
implementacja jest optymalna :) Ale... znaczenie tego słowa jest dość
proste - najszybszy kod danego zadania na danym zbiorze heterogenicznych
maszyn, czyli na każdą maszynę osobny kod.


> Wiesz, kluski z serem też da się spaprać a nie są szczytem sztuki
> kulinarnej.
Może mamy różny pogląd na to co jest implementacją rozsądną. Ty
nazywasz rozsądną taką, którą ja nazywam już lekko podrasowaną.


> Znajdź mi partię z trzema białymi wieżami na szachownicy.
Każda partia w której gracz dojechał pionkiem do linii promocji i wybrał
wieżę, często dla kaprysu tak gracze robią gdy partia jest na 100% wygrana.
Mało tego, czasami dla kaprysu programiści coś takiego implementują w
programach szachowy. Program zamienia pionka na laufra i daje w dwóch
ruchach mata. Widziałem wiele takich gier i są one zgodne z regulaminem.


> To że w tej dziedzinie wiedza się akumuluje nie jest niczym nadzwyczajnym.
> To że przy okazji akumulują się pośledniejsze pomysły też nie. Jak sam
> zauważyłeś pośledniejsze z czasem okazują się czasami lepsze, bo
> optymalizacja nie jest minimalizacją po gradiencie (niestety).
Właśnie. Można na osi Y przyjąć skalę od zera do jeden oznaczającą postęp.
Na osi X można dać skalę czasu, albo skalę ilości włożonej pracy. Rzadko
zaczynamy od zera, zwykle coś wiadomo w danej dziedzinie. Więc nasz wykres
postępu startuje od... powiedzmy 0.3. Potem dużo badaczy-mrówek
wkłada w zadanie dużo pracy i osiągają minimalny postęp, zwiększa się on
powiedzmy do 0.33. Potem ktoś odkrywa coś ważnego, mamy przełom, postęp
pionowo skacze do 0.45. Znowu pojawia się mrówcza praca wielu badaczy i
dochodzą do 0.5. Para mrówcza praca i przełom może powtórzyć się wiele
razy. Nie wiemy czy w danej dziedzinie jesteśmy gdzieś w okolicach 0.5
czy w okolicach 0.9. Jeśli jesteśmy w okolicach 0.9, to racja jest po
Twojej stronie - mamy program w okolicach 10% od optimum. Jeśli jesteśmy w
okolicach 0.5 to racja jest po mojej stronie.



> Czyli: optymalizacja jednak algorytmiczna.
Oczywiście że stosujemy optymalizację algorytmiczną jeśli tylko taka jest
możliwa. Jeśli nie jest możliwa, to stosujemy optymalizację implementacyjną.
Ale w procesie optymalizowania pojawia się jeszcze coś, co nazywam optymalizacją
mikro-algorytmiczną. W takich szachach jest główny algorytm: przeszukiwanie
drzewa gry i kilkadziesiąt algorytmów pobocznych. Algorytmy poboczne to np.
znajdowanie ruchów w węzłach, liczenie ilości ataków, liczenie odległości
pionków od linii promocji, liczenie różnych hash-key, różnych statystyk,
spamiętywanie częściowych wyników, itd. Zwykle jak się zmieni strukturę danych
żeby np. szybciej znajdować ruchy, to wolniej działa jakiś inny fragment.
Dlatego implementacja w szachach była tak trudna, trzeba było znaleźć
strukturę danych na które będzie działał wydajnie główny algorytm i wszystkie
algorytmy poboczne.


> Tobie o to chodzi, ja mówiłem o intuicyjności. W sensie "relacyjnego
> mapowania sposobu myślenia na kod" ;).
Hmmm... relacyjne mapowanie sposobu myślenia na kod... ładnie brzmi,
sprzedam to dalej :)

> Jasne, ostatecznie liczy się szybkośc działania a nie intuicyjność
> kodu.


> Wiesz, widziałem takich, którzy na podwójne kseony napisali
> program wielowątkowy tak, że jeden wątek działał a inne czekały.
> Czy to czegoś tak ogólnie dowodzi? Bo ja "widziałem".
No mamy problem z ustaleniem co jest implementacją rozsądną :)


> Niemożliwe do sprawdzenia. Do sprzwdzenia możliwe tylko jeżeli M$
> będzie porównywał .Net do reszty świata, czyli Perla, Pythona
> i co tam jeszcze jest najwolniejsze na świecie - wtedy będzie
> odpowiedni wynik badania.
Byśmy musieli wiedzieć na krzywej postępu leży dany program wraz
zastosowanymi w nim optymalizacjami algorytmicznymi i impementacyjnymi.
Jeśli leży w okolicach 0.9, to jest jak piszesz i każda próba
polepszenia nie ma sensu. Problem w tym, że nie wiemy czy jesteśmy w
okolicach 0.3 czy 0.9.

> Ja to faktycznie lubiłem, nie musiałem "trenować". Dzisiaj wciąż lubię,
> ale preferuję rozgrywkę po łyskaczu :).
Ja lubię patrzyć jak po implementacji jakiegoś algorytmu uczącego
mój program w każdym turnieju zdobywa więcej punktów :)

Pozdrawiam

do góry

>
> Może mamy różny pogląd na to co jest implementacją rozsądną. Ty
> nazywasz rozsądną taką, którą ja nazywam już lekko podrasowaną.
>

ja za implementacje rozsądną (bo tez uzywam
mw podobnego pojecia) nazywam taką która nie
ma w sobie zaodowanych jakichs specjalnych
'baboli' (typu wywolywanie jakiegos
niepotrzebnego loopa w loopie) ale tez nie jest optymalizowana, np w sensie
minimalizowania ilosci dzieleń itp - innymi
slowy w takiej implementacji rządzi
bezposredniosc i czytelnosc zapisu np
w omawianym przykladzie z mandelbrotem

for(int n=0; n<MAXITER; n++)
{
if( re * re + im * im > 4 ) return n;

re_n = re * re - im * im + cRe;
im_n = 2 * re * im + cIm;

re = re_n;
im = im_n;
}

podobny kod uwazam ze poprwany ale nie
optymalizowany natomiast wyrugowanie re_n
im_n, skeszowanie kwadratów, rozwiniecie
petli itd (przepisanie na asma) nalezy juz
do optymalizacji - w moim przypadku
optymalizacja przyniosła przyspieszenie
ponad 15 X (z okolo 300 ms dla kodu jak
wyzej do okolo 16 ms w obecnej wersji
zoptymalizowanej) (ale warunki do tej
optymalizacji okazaly sie wyjatkowo sprzyjajace bo taki ciezki kod dobrze
optymalizuje sie na sse a kod generowany
przez moj kompilator jest poprawny ale
slabej wydajnosci)

do góry

On Wednesday, April 17, 2013 10:30:52 AM UTC+2, firr kenobi wrote:
> ja za implementacje rozsądną (bo tez uzywam
> mw podobnego pojecia) nazywam taką która nie
> ma w sobie zaodowanych jakichs specjalnych
> 'baboli' (typu wywolywanie jakiegos
> niepotrzebnego loopa w loopie) ale tez nie jest
> optymalizowana, np w sensie minimalizowania ilosci dzieleń itp
Ja bym powiedział, ze rozsądna to jest taka, która nie ma
optymalizacji zwiększających szanse na błędy. A że błędy
robi się łatwo, często i nawet w prostych procedurach, to
implementacja rozsądna według tych kryteriów, jest
implementacją bardzo toporną :D


Sorry że uczepiłem się szachów. Ale mamy np. zasadę jednego
źródła danych. Czyli mamy tę tablicę:
Pole plansza[64],

Chcemy policzyć ile jest białych pionków, musimy zrobić 64 pętle:
for( i=0 ; i<64; i++ )
sum += plansza[i] == pionek_bialy;

Możemy złamać zasadę jednego źródła danych:
Pole plansza[64];
int sums[12];

Po każdym dodaniu bierki:
plansza[sqr] = bierka;
sums[ to12( bierka ) ] ++ ;

Po każdym usunięciu odwrotnie:
sums[ to12( plansza[sqr] ) ] -- ;
plansza[sqr] = null;


W drugiej wersji o wiele łatwiej można się pomylić i trzeba
dbać o spójność dwóch tablic. Jednak oszczędzamy aż 64 pętle,
kosztem rzadkich i szybkich uaktualnień. Dla mnie wersja z
dwiema tablicami jest już nawet mocno optymalizowana.


> - innymi
> slowy w takiej implementacji rządzi
> bezposredniosc i czytelnosc zapisu np
> w omawianym przykladzie z mandelbrotem
No tak, o to samo mam na myśli. Czytelny kod i prosty w udowodnieniu
poprawności.


> podobny kod uwazam ze poprwany ale nie
> optymalizowany natomiast wyrugowanie re_n
> im_n, skeszowanie kwadratów, rozwiniecie
> petli itd (przepisanie na asma) nalezy juz
> do optymalizacji - w moim przypadku
> optymalizacja przyniosła przyspieszenie
> ponad 15 X
Ładny wynik.


> (z okolo 300 ms dla kodu jak
> wyzej do okolo 16 ms w obecnej wersji
> zoptymalizowanej) (ale warunki do tej
> optymalizacji okazaly sie wyjatkowo sprzyjajace bo taki ciezki kod dobrze
> optymalizuje sie na sse a kod generowany
> przez moj kompilator jest poprawny ale
> slabej wydajnosci)
Może stary kompilator? Jakiego używasz?


Pozdrawiam

do góry

>
>
> W drugiej wersji o wiele łatwiej można się pomylić i trzeba
>
> dbać o spójność dwóch tablic. Jednak oszczędzamy aż 64 pętle,
>

to jest inny rodzaj optymalizacji (cos w
rodzaju optymalizacji przez cacheowanie - o
tyle nawet specjalny rozny od zwyklej
algorytmicznej ze dodaje sie pomocnicze
struktury danych (o tyle jest to
troche cięzkie, zgadza sie)
- daawno tego nie uzywalem o tyle nie
mam jakichs specjalnych spostrzezen na ten
temat, moze za niedlugo wroce do klepania
swojej strzelanki i zajdzie potrzeba, nie
wiem

do góry

>
> Może stary kompilator? Jakiego używasz?
>
>
teraz uzywam czterech bcc/lcc/dmc/mingw
zwykle najczesciej bcc + nasm przez
zasiedzenie i dlatego ze lubie/lubilem go,
jak sie przeniose na 64bity to pewnie
przesiade sie na mingw (ktory tez podobal
mi sie pod pewnymi wzgledami np ma
dobrze dzialajace opcje pomocne przy zmniejszaniu rozmiaru exe)

do góry

On Wednesday, April 17, 2013 12:29:14 PM UTC+2, firr kenobi wrote:
> > Może stary kompilator? Jakiego używasz?
> teraz uzywam czterech bcc/lcc/dmc/mingw
> zwykle najczesciej bcc + nasm przez
> zasiedzenie i dlatego ze lubie/lubilem go,
> jak sie przeniose na 64bity to pewnie
> przesiade sie na mingw (ktory tez podobal
> mi sie pod pewnymi wzgledami np ma
> dobrze dzialajace opcje pomocne przy zmniejszaniu rozmiaru exe)

Ciekawe jakby wypadł najnowszy gcc, może różnica względem
wersji zoptymalizowanej byłaby nieznaczna? W końcu to bardzo
prosta pętelka, kompilator powinien sobie z nią poradzić.

Ja najczęściej używam tego:
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1

Pozdrawiam

do góry

W dniu środa, 17 kwietnia 2013 13:01:16 UTC+2 użytkownik M.M. napisał:
> On Wednesday, April 17, 2013 12:29:14 PM UTC+2, firr kenobi wrote:
>
> > > Może stary kompilator? Jakiego używasz?
>
> > teraz uzywam czterech bcc/lcc/dmc/mingw
>
> > zwykle najczesciej bcc + nasm przez
>
> > zasiedzenie i dlatego ze lubie/lubilem go,
>
> > jak sie przeniose na 64bity to pewnie
>
> > przesiade sie na mingw (ktory tez podobal
>
> > mi sie pod pewnymi wzgledami np ma
>
> > dobrze dzialajace opcje pomocne przy zmniejszaniu rozmiaru exe)
>
>
>
> Ciekawe jakby wypadł najnowszy gcc, może różnica względem
> wersji zoptymalizowanej byłaby nieznaczna? W końcu to bardzo
> prosta pętelka, kompilator powinien sobie z nią poradzić.
>
>
wersja z rozszerzeniami wektorowymi to
moze tak ale ta zwykla co podana to raczej
nie ;-)

mozesz to skompilowac i zapostowac wynik
w asmie na grupe (wtedy ew moge to
zasemblowac nasmem i zmierzyc) ale
sam testowac tego (przerzucajac
projekt na mingw) nie mam teraz checi bo
to z godzina roboty a nie jest mi to
potrzebne ;/

chetniej pomierzylbym startupy progsa
(o czym bylo wspomniana na p.c.l.c.
a nieststy nie znalazlem nigdzie info
jak odczytac z poziomu programu wlasciwy moment jego odpalenia)

do góry

On Wednesday, April 17, 2013 3:07:10 PM UTC+2, firr kenobi wrote:

> chetniej pomierzylbym startupy progsa
> (o czym bylo wspomniana na p.c.l.c.
> a nieststy nie znalazlem nigdzie info
> jak odczytac z poziomu programu wlasciwy moment jego odpalenia)


Wziąłem taką wersję:
http://pastebin.com/JBhgCNLr


Kompilacja:
g++ -O3 main.cpp -o mb


Uruchomienie:
time ./mb 1000 1000
test = 1423724113.000000
real 0m8.968s
user 0m8.945s
sys 0m0.004s

Jak to należy zoptymalizować?

Pozdrawiam
P.S.
Procesor:

cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
stepping : 5
cpu MHz : 933.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni
dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm
arat dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 4787.77
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
stepping : 5
cpu MHz : 933.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni
dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm
arat dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 4787.90
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
stepping : 5
cpu MHz : 933.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni
dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm
arat dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 4787.89
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
stepping : 5
cpu MHz : 933.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni
dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm
arat dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 4787.91
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual

do góry