2011-10-20 23:05:13
Pora na zmianę IDE

Jako die-hard Delphi developer, trzymałem się kurczowo swojego Delphi 3. Czasy się pozmieniały, i nowe projekty piszę albo w C# albo C++. Delphi jako takie jest niestety bez przyszłości, nawet jeśli ma niepodważalne zalety względem obu wyżej wymienionych - jest to narzędzie typu RAD (jak C# z WinForms i VSowym Form Designerem) zintegrowane z bardzo szybkim, kompilującym do kodu natywnego kompilatorem (jak C/C++). Bez przyszłości dlatego, że powyższe zalety z każdą nową wersją tracą na wadze. Miałem okazję przyjrzeć się Delphi XE2, z 64-robitowym kompilatorem (tak, produkuje natywne, 64-bitowe aplikacje) i jestem przerażony. Okienko, button, kilkadziesiąt linijek kodu - wynikowy exe ma 1,8MB. Delphi 3 - ~200KB. Pardon...? Poza tym, nowe Delphi wygląda jak dziwna hybryda Visual Studio 2008 i Delphi 7 - do tego jest ociężałe (szczególnie uruchamianie) i pamięciożerne. No i w końcu - na nowsze Delphi mnie nie stać, a żebrać nie zamierzam, więc stoję przy D3. Teraz właśnie przerabiam część kodu HCMa, bo D3... nie zna 32-bitowych liczb całkowitych bez znaku (najlbliżej jest 31-bitowa liczba całkowita bez znaku). Zna 64-robitowe liczby całkowite ze znakiem, tu jednak jest mały problem - każda wartość idzie przez FPU (jednostkę zmiennoprzecinkową), wobec czego trzeba magii, by osiągnąć sensowną wydajność. Na przykład, liniowe wyszukiwanie każdej liczby ze zbioru 131072 liczb na Atomie 330 trwa 147 sekund, zaś wyszukiwanie binarne trwa 0,2 sekundy. Zoptymalizowanie tego pierwszego nie jest straszną filozofią, w końcu to porównywanie 8-miobajtowych bloków pamięci. Po zoptymalizowaniu, czas spada do 35 sekund - i to już ma sens. Z optymalizowaniem tego drugiego musiałem się uciec do... Języka C. Dlaczego? Otóż, teoretycznie Delphi 3 ma coś takiego jak TLargeInteger, struktura ta ma trzy pola - HighDword, LowDword i QuadPart, dwa pierwsze dzielą pamięć z tym trzecim. Teoretycznie więc wystarczy najpierw porównać HighDwordy elementu bieżącego i szukanego, a potem LowDwordy. Problem w tym, że jeśli LowDword przekroczy 31 bitów (tj. >=$80000000) - a przekroczy na bank - to LowDword będzie widziany jako ujemny (najstarszy bit wartości będzie rozumiany jako znak) i algorytm będzie zwracał bzdury totalne. Na szczęście typ Comp jest identyczny jak __int64, więc wystarczyło stworzyć nową bibliotekę, skompilować ją do pliku .obj, zlinkować ({$L nazwa.obj}) i mamy kod z różnych kompilatorów w jednej binarce. Zoptymalizowane (w C) wyszukiwanie binarne potrzebuje 0,06 sekundy, czyli ok. 3x mniej. A że zaczyna to być skomplikowane... No cóż. Może jednak pora uzbierać na XE2. Albo przepisać całość na C++...

A czemu C a nie assembler? Bo wyklikanie tego w C to dwie minuty, zaś w asemblerze trochę więcej, a i tak nie mam gwarancji, że nie zrobiłem jakiegoś idiotycznego błędu (a o te w asmie bardzo łatwo). Wydajność będzie ta sama, ew. nieznacznie lepsza w przypadku asma, więc...

2011-10-17 15:00:23
Psują Fabryczny

Ech. W sobotę z Fabrycznego odjechał ostatni pociąg, a dzisiaj miałem okazję, to po raz ostatni popatrzyłem na ten dworzec - póki jeszcze stał. Nie wiadomo ile będzie trwała przebudowa, mam nadzieję że dożyję tego momentu - niemniej, z jednej strony, trochę żal. Miał swój klimat - odrapany, zimny, pamiętający PRL,... Nowy będzie sterylny, "nowoczesny" i ogólnie nie będzie taki sam.

Z drugiej strony, nie można żyć cały czas erą PRLu i wczesnym postkomunizmem. A wspomnienia z wszystkich tour de Pologne (i porannych biegów za pociągami :D) i przyjazdów wszystkich Kaś, Ilon, Mart, i innych osobników (niektórzy nie wracali tak szybko :P), ... To moje i żaden remont tego nie zabierze. ;-) (taaa, potem usiądę przy kominku i będę opowiadał wnukom niestworzone historie o jakimś odrapanym dworcu... HAHAHA).

2011-10-17 11:27:40
zlibsuballoc - lepsze zarządzanie pamięcią dla biblioteki zlib

Drobnica przygotowana na potrzeby Hellcore Mailera i paru innych moich projektów.

Problem jest błahy - zlib, rozpoczynając (de)kompresję, alokuje pewną ilość pamięci i dealokuje ją, gdy skończy. Pomnożyć to razy kilka tysięcy i wydajnościowa katastrofa gotowa. zlibsuballoc ma za zadanie tej katastrofie jeśli nie zapobiec, to przynajmniej zredukować ją do akceptowalnego poziomu, bez wpływania na cały program.

2011-10-14 02:39:53
Dennis M. Ritchie też kopnął w kalendarz

Świat ciągle masturbuje się wieścią o śmierci Jobsa, a tymczasem umiera ktoś pierdyliardy razy bardziej zasłużony światu i nie widać za specjalnie, by ktoś się tym przejął. Ostatecznie, Ritchie nie był tak popularny jak Jobs. Jobs to, Jobs tamto, Jobs sramto i owamto, a gdyby nie Ritchie i jego współpracownicy, to nie powstałby ani Unix, ani C (a przynajmniej nie takie, jakie znamy obecnie) i bardzo możliwe, że dzisiaj iOS nie byłby dokładnie tym, czym jest teraz. O ile w ogóle by był.

To wkurwiające widzieć, gdy jakiś obwarowany marketingowcami i prawnikami buraczyna, który "zasłynął" tylko bajerzastym telefonem oraz komputerem i systemem operacyjnym dla laluń i gejów, częściej jest wymieniany jako innowator i przodownik informatyki niż ktoś, kto de facto informatykę tworzył. Z drugiej strony, Von Neumanna też niewielu kojarzy - a jego model jest podstawą wszystkich dzisiejszych komputerów.

No cóż. Niemniej - miejmy nadzieję, że Ritchie na tamtym świecie nie narzeka.

Powered by:
Hellcore Mailer - polski program pocztowyOpera Web BrowserFreeBSD - The Power to Serve!Slackware
RSSy:
Sidekick:
Projekty:
O autorze:
Zobacz:
Kategorie:
Archiwum:
Szukaj: