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