bartekltg <b...@g...com> napisał(a):

> W dniu 2012-01-29 23:35, f...@g...pl pisze:
>
>
> >
> > jest to jakis temat: na czym polega roznica (co do
> > szybkosci w pisaniu i inn) w pisaniu programow np w
> > c# i okolicach kontra pisanie w c+asm
> >
> > osobiscie jakos 'nie chwytam' tej roznicy, co do szybkosci
> > pisania to wydaje mi sie (z grubsza) taka sama (bo mw
> > tyle samo wyrazen trzeba wklepac)
>
> A próbowałeś coś napisać?
>
> Pomińmy sprawy GUI, interfejsy... Jakieś proste
> zadanka algorytmiczne (wejscie i wyjście z konsoli)?
>
> http://potyczki.mimuw.edu.pl/user.phtml?op=zadania
>
> Mam napisane wie, pec, wsp, prz, sis
> oraz pal i plo z jakimiś głupim błędami.
>
> Ĺťadne z nich nie ma ponad 100 linii, sporo ma 30~40.
> Implementacja też nie trwała zbyt długo (choć
> rozwiązanie zadania nieraz wymagało zastanowienia:).
>
> Wybierz jakieś spokojniejsze zadanie i porównamy
> włożoną pracę.
>
> BTW, przyjemny konkursik, tylko czasu nigdy nie ma.
>

szczerze mowiac to malo zajmuje sie matematyka i np
nie bardzo podzielam co poniektorych tutaj zainteresowania
tymi tematami obecnie - nie chce za bardzo skakac po
tematach z mat phys, ew interesuje mnie kwestia symulacji
w 2d * (lubie algebre i na studiach dostawalem dobre noty
z algebry ale to co obecnie robie ma malo wspolnego
z matematyka - nawet zastanawialem sie ostatnio czy
algorytmy to tak naprawde matematyka, bo akurat te ktore
znam - sortowania czy A* to mz wogole nie matematyka

pracujesz moze na jakiejs uczelni jako wykladowca - ?

* chcialbym zrobic ew prosty model fizyki punktow
z polaczeniami itp



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

W dniu 1/29/2012 10:56 PM, Edek wrote:
> On 01/29/2012 09:54 PM, f...@g...pl wrote:
>> bartekltg<b...@g...com> napisał(a):
>
>
> Widzisz, programowanie w assemblerze było wyzwaniem w czasach Atari,
> Commodore'a czy może DOSa, gdzie można było tylko w ten sposób wyjść
> poza ograniczenia systemowe. Nie, nie było tam nawet hexedytora
> (ręki sobie nie dam uciąć, dawno to było, czy był na DOSie).

E tam nie było. Na 8-bitowym Atari pisałem w asemblerze. I to całkiem
wygodnym, bo z makrami. A heksedytorów to do woli było, bo jak inaczej
by się nieśmiertelność do gier wprowadzało. To były czasy...

Pozdrawiam,
Arkadesh

do góry

Borneq <b...@a...hidden.pl> napisał(a):

> W dniu 2012-01-30 02:25, M.M. pisze:
> > Ostatnio wzialem pod lupe pewien programik do generowania lasow drzew
> > regresyjnych. Program jest napisany bardzo intuicyjnie, np. kazdy
> > rekord z pliku jest alokowany przez new i sa listy rekordow (a nie tablice
> > liniowe). Program uzywa (chyba) dobrego algorytmu ale ma kiepska
> > implementacje. Nie ma zoptymalizowanej pamieci cache i nie jest
> > zrownoleglony ani nie ma jednej globalnej struktury danych przyjaznej
> > dla wszystkich procedur, tylko robi konwersje.
>
> Czy alokowanie przez new rzeczywiście tak nieefektywne? W C# i Javie
> chyba nie można się bez tego obyć, tylko że tam new jest szybsze.
> Listy rekordów chyba są dość szybkie

Problem polega na czym innym. Sama alokacja przy pomocy new nie musi
byc problemem, wszystko zalezy od tego jak czesto alokujemy w stosunku
do innych operacji.

Chodzi o to, ze mam liste rekordow, zwykla struktura:
struct NodeList {
void *dane;
NodeList *next;
};
Wczytuje dane z pliku i za kazdym razem mam dwa wywolania new, jedno
dla utworzenia wezla, a drugie dla utworzenia danych. Potem lista
jest przegladana. Wyglada na to ze new podaje w miare mozliwosci
sekwencyjne adresy i pierwszy przeglad trwa krotko. Potem jedna lista
jest rozbijana na dwie listy. Do kazdej trafiaja przypadkowe elementy.
Takich podzialow robie wiecej, w koncu wszystkie listy sa skladane z
powrotem w jedna i z powrotem sa dzielone. Po okolo dwoch-trzech takich
przebiegach algorytmu uzyskuje praktycznie losowy dostep do pamieci i
to jest glownym problemem. Po upakowaniu tego w sekwencyjne adresy i
zrownoleglenie (na listach ciezko zrownoleglac) przyspieszenie jest
ogromne, przewiduje ze okolo 200 razy.


Pozdrawiam.


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Mon, 30 Jan 2012 11:01:11 +0100, Arkadiusz Dymek napisał(a):

> W dniu 1/29/2012 10:56 PM, Edek wrote:
>> On 01/29/2012 09:54 PM, f...@g...pl wrote:
>>> bartekltg<b...@g...com> napisał(a):
>>
>>
>> Widzisz, programowanie w assemblerze było wyzwaniem w czasach Atari,
>> Commodore'a czy może DOSa, gdzie można było tylko w ten sposób wyjść
>> poza ograniczenia systemowe. Nie, nie było tam nawet hexedytora
>> (ręki sobie nie dam uciąć, dawno to było, czy był na DOSie).
>
> E tam nie było. Na 8-bitowym Atari pisałem w asemblerze. I to całkiem
> wygodnym, bo z makrami. A heksedytorów to do woli było, bo jak inaczej
> by się nieśmiertelność do gier wprowadzało. To były czasy...
>
> Pozdrawiam,
> Arkadesh

No to ja dodam Commodore Plus 4, ktory to mial wbudowany w ROM Assembler i
edytor hex. Wystaczylo zaladowac gre, wcisnac magiczny przycisk i mialo sie
wglad do kodu. Pozmieniac zawartosc i wrocic do gry.

do góry

Jacek <a...@o...pl> napisał(a):

> Dnia Mon, 30 Jan 2012 11:01:11 +0100, Arkadiusz Dymek napisał(a):
>
> > W dniu 1/29/2012 10:56 PM, Edek wrote:
> >> On 01/29/2012 09:54 PM, f...@g...pl wrote:
> >>> bartekltg<b...@g...com> napisał(a):
> >>
> >>
> >> Widzisz, programowanie w assemblerze było wyzwaniem w czasach Atari,
> >> Commodore'a czy może DOSa, gdzie można było tylko w ten sposób wyjść
> >> poza ograniczenia systemowe. Nie, nie było tam nawet hexedytora
> >> (ręki sobie nie dam uciąć, dawno to było, czy był na DOSie).
> >
> > E tam nie było. Na 8-bitowym Atari pisałem w asemblerze. I to całkiem
> > wygodnym, bo z makrami. A heksedytorów to do woli było, bo jak inaczej
> > by się nieśmiertelność do gier wprowadzało. To były czasy...
> >
> > Pozdrawiam,
> > Arkadesh
>
> No to ja dodam Commodore Plus 4, ktory to mial wbudowany w ROM Assembler i
> edytor hex. Wystaczylo zaladowac gre, wcisnac magiczny przycisk i mialo sie
> wglad do kodu. Pozmieniac zawartosc i wrocic do gry.

dzis tez mozna - o ile sie czesciowo orientuje, otworzyc program
w hexedytorze i mozna zmieniac bajty i wstawiac 'poke' , albo
podlaczyc olldebug i mw to samo w obrazie procesu w pamieci




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

>> No to ja dodam Commodore Plus 4, ktory to mial wbudowany w ROM Assembler i
>> edytor hex. Wystaczylo zaladowac gre, wcisnac magiczny przycisk i mialo sie
>> wglad do kodu. Pozmieniac zawartosc i wrocic do gry.
>
> dzis tez mozna - o ile sie czesciowo orientuje, otworzyc program
> w hexedytorze i mozna zmieniac bajty i wstawiac 'poke' , albo
> podlaczyc olldebug i mw to samo w obrazie procesu w pamieci

A pewnie że można, tutaj prosta ciekawostka na temat -
http://zine.net.pl/blogs/mgrzeg/archive/2012/01/22/p
rotectedprocess-czyli-s-w-kilka-o-ochronie-procesu.a
spx

--
Mateusz Bogusz

do góry

> Problem polega na czym innym. Sama alokacja przy pomocy new nie musi
> byc problemem, wszystko zalezy od tego jak czesto alokujemy w stosunku
> do innych operacji.

Dokładnie, ale największym grzechem który aktualnie widzę, są bardzo
duże braki w dobieraniu odpowiednich klas obiektów, tudzież struktur.

Ostatnio wpadł mi w ręce program znajomego, który poprzez sieci
neuronowe wyliczał przynależności badanych dokumentów (tekstów)
do języka.

Namiętnie w jednej z pętli - ponieważ potrzebował posortowanej listy -
używał List.Sort() co dodanie elementu. Zbiór danych analizował się
około 4-5h. To pierwsza rzecz, która mi się rzuciła w oczy przy
pobieżnym przeglądaniu kodu. Zamiana na SortedList (C#) i zakomentowanie
linii List.Sort, sprawiło że analiza wykonywała się w 400-500 ms. Na tym
poprzestałem dalsze sprawdzanie kodu.

Jak widać asembler w zdecydowanej większości przypadków nie jest dzisiaj
potrzebny. Dostatecznie dużo oferują języki wyższego poziomu i
dostatecznie dużo jest ciągle tutaj do uczenia się dla większości.

--
Mateusz Bogusz
By pisać łatwo i przyjemnie,
a aplikacje działały szubko i stabilnie!

do góry

Am 30.01.12 19:15, schrieb Karol Y:

> Jak widać asembler w zdecydowanej większości przypadków nie jest dzisiaj
> potrzebny. Dostatecznie dużo oferują języki wyższego poziomu i
> dostatecznie dużo jest ciągle tutaj do uczenia się dla większości.

Do tego jeszcze dochodzi niechlujstwo programistow. Ostatnio sprawdzalem
program kolegi - w dosc duzej petli odwolywal sie co iteracje do
wlasciwosci ComboBox.SelectedItem (ktora z zalozenia miala sie nie
zmieniac w trakcje pracy petli). Poprawienie tego jednego byka dalo
400-krotne przyspieszenie...

Assembler jest fajny, ale duzo wiecej daje napisanie dobrze
przemyslanego kodu w jezyku wyzszego poziomu.

--
Michal Schulz

do góry

W dniu 2012-01-30 19:15, Karol Y pisze:
>> Problem polega na czym innym. Sama alokacja przy pomocy new nie musi
>> byc problemem, wszystko zalezy od tego jak czesto alokujemy w stosunku
>> do innych operacji.
>
> Dokładnie, ale największym grzechem który aktualnie widzę, są bardzo
> duże braki w dobieraniu odpowiednich klas obiektów, tudzież struktur.
>
> Ostatnio wpadł mi w ręce program znajomego, który poprzez sieci
> neuronowe wyliczał przynależności badanych dokumentów (tekstów)
> do języka.
>
> Namiętnie w jednej z pętli - ponieważ potrzebował posortowanej listy -
> używał List.Sort() co dodanie elementu. Zbiór danych analizował się
> około 4-5h. To pierwsza rzecz, która mi się rzuciła w oczy przy


To nie jest grzech. To totalna ignorancja. Jeśli gość
poległ na sortowaniu, to nie wróże nic dobrego
tej 'sieci neuronowej':(

pzdr
bartekltg

do góry

Karol Y <k...@o...pl> napisał(a):

> Namiętnie w jednej z pętli - ponieważ potrzebował posortowanej listy -
> używał List.Sort() co dodanie elementu. Zbiór danych analizował się
> około 4-5h. To pierwsza rzecz, która mi się rzuciła w oczy przy
> pobieżnym przeglądaniu kodu. Zamiana na SortedList (C#) i zakomentowanie
> linii List.Sort, sprawiło że analiza wykonywała się w 400-500 ms. Na tym
> poprzestałem dalsze sprawdzanie kodu.

Najczesciej jest tak jak mowisz. Jakis blad i to nie implementacyjny, ale
algorytmiczny. Wystarczy go poprawic i program dziala w zadowalajacy sposob.
Co wiecej, czasami wystarczy kupic nowszy komputer i nic nie trzeba
poprawiac w kodzie. Niestety ja tak nie mam. Obojetnie o ile przyspiesze
program to znajdzie sie wiecej danych do analizy.

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry