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