2009-11-19 00:08:28
Najniższy obsługiwany system operacyjny

Najniższy obsługiwany przez HCMa (o ile można to tak nazwać, bo raczej powinno być odwrotnie) system operacyjny to Windows 95. Windows 3.11 i starsze z tej linii z oczywistych względów nie zadziałają, natomiast pod Windows NT 3.51 Workstation są problemy z menu i niektórymi oknami:

2009-11-17 07:52:03
DualCoreSort

Nie jest to żaden nowy algorytm ani nowe informatyczne odkrycie, a jedynie przykład, jak, mając dwa logiczne procesory i dwa proste algorytmy sprawić, by zajmująca najwięcej czasu operacja wykonywała się szybciej. O ile prezentuję tu przykład sortowania dwoma rdzeniami, to spokojnie można to rozbić na większą liczbę rdzeni. Motywacją do tego wpisu (i kodu) było to, że "uwielordzeniowanie" programów - nawet, a może raczej: głównie - w środowiskach RAD jest uznawane za jakąś alchemię. Wiele osób po prostu nie wie "co to jest" i "jak to się robi" (swoją drogą, to rozbawiła mnie prośba jednego kodera, by twórcy jakiejś biblioteki zoptymalizowali jedną, maluteńką - kilkadziesiąt instrukcji x86 - funkcyjkę do korzystania z wielu rdzeni). Może po tym wpisie niektórym się rozjaśni.

2009-11-12 05:38:14
Nie ma to jak wpieprzyć atomówką

Męczenia Supreme Commandera ciąg dalszy, a jak. Po przejściu wszystkich trzech kampanii na wszystkich trzech poziomach trudności (tak, jest to wykonalne) można zacząć grać po raz dziesiąty w to samo albo... Użyć opcji "Skirmish". I tu się zaczynają jaja :)

2009-11-06 12:24:48
Benchmarków mailerów nie będzie

Nie chce mi się ich robić.

Niektóre programy nie zmieniają się, inne zmieniają za szybko, do tego dochodzą różnice w konfiguracji sprzętu i oprogramowania (w praktyce ten sam program na tym samym komputerze pod różnymi systemami działa inaczej - HCM na Pentium 200 uruchamia się trochę wolniej na Windows 2000 niż na Windows 95, ale z kolei na Windows 95 ma niższą maksymalną przepustowość podczas wysyłania i pobierania wiadomości niż na Windows 2000 - widać, że jednak usprawnili stos TCP/IP w Win2k). Żeby benchmarki były w 100% wiarygodne, musiałbym praktycznie co miesiąc-dwa je aktualizować, a bez tego mam za dużo na głowie.

Inna sprawa, że zaraz na karku miałbym bandę wyznawców innych klientów, którzy doczepiliby się do metodologii lub (w ich mniemaniu) fałszowania wyników. To z kolei na bank skończyłoby się niekończącym się flejmem. Bez sensu.

Wraz z HCMem 0.6 pojawią się benchmarki na Atomie 330 i Core 2 Duo E4400, jeśli ktoś chce, będzie mógł sobie sam porównać ze swoim obecnie używanym programem ;-) Ale ja myślę, że HCM w tym miejscu nie wymaga specjalnej reklamy, wszystkie programy dążą do przebloatowania, co prowadzi do budzenia się z ręką w nocniku, a co za tym idzie - strzelaniem sobie w stopy. Genialnym przykładem takiego podejścia jest The Bat, który z maleńkiego mailerka rozrósł się do kobyły niewiele mniejszej od Opery. Zamiast zoptymalizować kod, to twórcy tego programu upiekli dwie pieczenie na jednym ogniu - problemem dla RIT Labs byli crackerzy którzy okresowo wypuszczali pokrakowane wersje albo kraki i/lub keygeny. Co zrobili? Zabezpieczyli przed pokrakowaniem za pomocą Themidy. Jedną z opcji Themidy jest kompresowanie wykonywalnego pliku - a to, jak wiadomo, źle odbija się na użyciu pamięci, ponieważ skompresowane programy muszą być wczytane do pamięci w całości (normalnie system Windows wczytuje tylko potrzebne fragmenty plików wykonywalnych i potrafi je współdzielić między uruchomionymi instancjami; przy skompresowanych programach żadna z tych optymalizacji nie może być zastosowana). Efekt był bardzo śmieszny, ludzie niemalże skakali z radości, że "z dnia na dzień" wielkość pliku wykonywalnego The Bata spadła z ~14 do ~6MB (niektórzy The Batowi ewangeliści przypisywali to niezwykłemu zoptymalizowaniu kodu), ale jakoś mało kto zwrócił uwagę, że przez tę kompresję The Bat zaczął zjadać więcej pamięci (ok. 40MB - więcej nawet niż "goły" Thunderbird). W ostatniej wersji wycofali się z tego kompresowania wobec czego minimalne użycie pamięci spadło do akceptowalnego poziomu, ale wielkość pliku wykonywalnego znowu przekracza 10MB (nieskompresowany plik wykonywalny HCMa, dla porównania, zajmuje 2,14MB).

2009-11-02 10:12:30
GrayForm

This article is also available in english language

Kiedyś na pl.comp.lang.delphi pojawił się wątek, w którym pytacz chciał wyróżnić niedostępne okienka poprzez wyszarzenie ich. Padło m. in. rozwiązanie z Alpha Blendingiem - jeśli ma się Delphi 7, to nawet da się to szybko zaimplementować, ale jest to szalenie nieefektywne. Teraz, dla odmiany, napisałem to po swojemu - i działa szybko, nie wymaga dużo pamięci, Windows 2000 ani Delphi 7 (lub nowszych). Działąjący moduł GrayForm.pas wrzuciłem na BranchWare, kod jest na licencji BSD. W module zademonstrowałem w jaki sposób szybko przetwarzać bitmapy - GrayForm potrzebuje ~55ms na samą konwersję bitmapy 24bpp o wymiarach 1920x1200 na odcienie szarości (bez stosowania assemblera) - i to na Atomie 330. Dla bitmap spaletyzowanych wykonuje to samo w czasie prawie że rzeczywistym (modyfikowanie samej palety).

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