kiedys (jakis kwartal temu) wymyslilem
sentencje 'prawdziwy asemblerowiec
pisze 365 razy dluzej 365 razy szybsza
aplikacje' (notabene w dokach ktore dzis
czytalem asembler jest okreslany mianem
'dark art')
mimochodem
powstalo pytanie w jakich przypadkach
moze warto miec 365 razy szybsza aplikacje
kosztem 365 razy dluzszego czasu jej
pisania - gdyby przyjac ze godzina uzywania
365 razy szybszej aplikacji(zysk uzytkownika)
rownowazy godzine jej
365 razy wolniejszego pisania (strata programisty)
to zero osiagneloby sie przy czasie uzywania
rownym czasu pisania - oczywiscie klu tych
(swoiscie dosyc glupich ale nie zupelnie
nieciekawych) rozwazan sprowadza sie do
uwzglednienia faktu ze programista jest jeden
a uzytkownikow miliony wiec generalnie warto
pisac 100 razy dluzej100 razy lepsza aplikacje
#######
pytanie: jakie moga byc sumaryczne czasy uzycia
roznych aplikacji liczone w czlowiekogodzinach?

np jesli gra sprzeda sie w milionie egzemplarzy a kazdy
bedzie grac w nia 5 godzin to wychodzi mi z kalkulatora
ze jej sumaryczny czas uzycia wynosi ok 600 lat

(sorki ew za glupi temat)

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On 3 Kwi, 21:12, "kenobi" <p...@p...onet.pl> wrote:
> kiedys (jakis kwartal temu) wymyslilem
> sentencje 'prawdziwy asemblerowiec
> pisze 365 razy dluzej 365 razy szybsza
> aplikacje' (notabene w dokach ktore dzis
> czytalem asembler jest okreslany mianem
> 'dark art')
> mimochodem
> powstalo pytanie w jakich przypadkach
> moze warto miec 365 razy szybsza aplikacje
> kosztem 365 razy dluzszego czasu jej
Z jednej mojej aplikacji bedzie zysk okolo 50-200tys usd jesli
by sie udalo ja przyspieszyc 300 razy.
Pozdrawiam

do góry

> On 3 Kwi, 21:12, "kenobi" <p...@p...onet.pl> wrote:

> > kiedys (jakis kwartal temu) wymyslilem
> > sentencje 'prawdziwy asemblerowiec
> > pisze 365 razy dluzej 365 razy szybsza
> > aplikacje' (notabene w dokach ktore dzis
> > czytalem asembler jest okreslany mianem
> > 'dark art')
> > mimochodem
> > powstalo pytanie w jakich przypadkach

> Z jednej mojej aplikacji bedzie zysk okolo 50-200tys usd jesli
> by sie udalo ja przyspieszyc 300 razy.
> Pozdrawiam

jesli jest w miare dobrze napisana (i nie
w jakims 'wysokopoziomowym' smietniku) to tyle
razy nie przyspieszysz - na twoim miejscu
na pewno rzucilbym c++ i przesiadl sie na statyczne c
ze wstawkami w asmie (duzo inline itp)- moze byloby ze 3 razy
szybciej; moze jakies sprytne algorytmy? takie
rzeczy potrafia tez przyspieszyc rzedu kilkunastu razy o ile
wiem - interesuje sie szybkoscia kodu ale ciagle
dorastam do tematu


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 2011-04-03 21:46, Mariusz Marszałkowski pisze:

> Z jednej mojej aplikacji bedzie zysk okolo 50-200tys usd jesli
> by sie udalo ja przyspieszyc 300 razy.


Dalej próbujecie zastąpić wyniki skomplikowanych obliczeń
funkcjonałem liniowym na paru prostszych funkcjach danych
wejściowych?
Doradzałem kiedyś, że Wam matematyk/prawdziwy numery potrzebny,
poza programistami;)

pozdrawiam
bartekltg

do góry

On 3 Kwi, 22:16, bartekltg <b...@g...com> wrote:
> W dniu 2011-04-03 21:46, Mariusz Marszałkowski pisze:
>
> > Z jednej mojej aplikacji bedzie zysk okolo 50-200tys usd jesli
> > by sie udalo ja przyspieszyc 300 razy.
>
> Dalej próbujecie
Teraz to juz tylko copy-paste wynikow i test.

> zastąpić wyniki skomplikowanych obliczeń
> funkcjonałem liniowym na paru prostszych funkcjach danych
> wejściowych?
Mniej / wiecej, to byla jedna z wielu prob, ale wszystkie sprytne
metody zawiodly.
Najlepsze wyniki byly gdy po prostu zrzucilem stany programu wraz z
potencjalnymi zyskami gdyby program nie tracil czasu na
obliczenia i silowo testowalem warunki. Potem najlepsze
wpisywalem do programu i sprawdzenie na zywych danych. Bardzo dobrze
dzialaly sztuczne sieci neuronowe, dobrze zapobiegaly liczeniu
tego co i tak nie przyniesie korzysci, ale co z tego ze dzialaly
jeszcze wolniej niz algorytm ktory mial dzieki nim przespieszyc :)

> Doradzałem kiedyś, że Wam matematyk/prawdziwy numery potrzebny,
> poza programistami;)
Tu jest problem z poufnoscia, latwo mozna na lewo zarobic a udowodnic
ciezko. Nie mozna zgromadzic zespolu i tak po prostu dac ludziom dane
do
zabawy. Z poprzednimi dwoma pracownikami jeszcze sie ciagna sprawy po
sadach.

Pozdrawiam

do góry

On Sun, 3 Apr 2011 12:46:27 -0700 (PDT), Mariusz Marszałkowski
<m...@g...com> wrote:

>On 3 Kwi, 21:12, "kenobi" <p...@p...onet.pl> wrote:
>> kiedys (jakis kwartal temu) wymyslilem
>> sentencje 'prawdziwy asemblerowiec
>> pisze 365 razy dluzej 365 razy szybsza
>> aplikacje'

To jest kompletny idiotyzm

A.L.

do góry

W dniu 2011-04-04 00:13, Mariusz Marszałkowski pisze:
> On 3 Kwi, 22:16, bartekltg<b...@g...com> wrot

>> zastąpić wyniki skomplikowanych obliczeń
>> funkcjonałem liniowym na paru prostszych funkcjach danych
>> wejściowych?
> Mniej / wiecej, to byla jedna z wielu prob, ale wszystkie sprytne
> metody zawiodly.

:)

> Najlepsze wyniki byly gdy po prostu zrzucilem stany programu wraz z
> potencjalnymi zyskami gdyby program nie tracil czasu na
> obliczenia i silowo testowalem warunki. Potem najlepsze
> wpisywalem do programu i sprawdzenie na zywych danych. Bardzo dobrze
> dzialaly sztuczne sieci neuronowe, dobrze zapobiegaly liczeniu
> tego co i tak nie przyniesie korzysci, ale co z tego ze dzialaly
> jeszcze wolniej niz algorytm ktory mial dzieki nim przespieszyc :)

:-)

>> Doradzałem kiedyś, że Wam matematyk/prawdziwy numery potrzebny,
>> poza programistami;)
> Tu jest problem z poufnoscia, latwo mozna na lewo zarobic a udowodnic
> ciezko. Nie mozna zgromadzic zespolu i tak po prostu dac ludziom dane
> do
> zabawy. Z poprzednimi dwoma pracownikami jeszcze sie ciagna sprawy po
> sadach.

Prawnik, co zrobi rozsądna umowę też kosztuje;)
Projekt poważniejszy niż studenckie pospolite ruszenia
a wszystko jakoś sznurkiem do snopowiązałki wiązane..
W nauce to bym rozumiał, ale przemysł;-)


pozdrawiam
bartekltg

do góry

On 4 Kwi, 00:58, bartekltg <b...@g...com> wrote:

> Prawnik, co zrobi rozs dna umow te kosztuje;)
> Projekt powa niejszy ni studenckie pospolite ruszenia
> a wszystko jako sznurkiem do snopowi za ki wi zane..
> W nauce to bym rozumia , ale przemys ;-)
Czy przemysl czy nie to zlamanie warukow umowy trzeba
udowodnic, a z tym sa problemy.

A wracajac jeszcze do automatycznej budowy takich
heurystyk to zastanawiam sie jakie efekty bylyby dla
przeszukiwania drzewa gry w szachach. Dobre programy
szachowe sa dlatego dobre ze bez przeszukiwania
drzewa gry z duzym prawd. przewiduja ktory ruch jest
na tyle kiepski ze mozna po nim nie przeszukiwac. Takie
techniki przyspieszaja programy miliony razy, tyle ze
sa one wpisywane przez programistow-szachistow.

Zastanawiam sie czy mozna wygenerowac taka heurystyke w
pelni atomatycznie. Tez mozna zrzucic stan algorytmu do pliku i
widac jak na dloni po ktorych ruchach przeszukiwanie nie
mialo sensu. Ale co potem zrobic z takim plikiem?

Pozdrawiam

do góry

kenobi <p...@p...onet.pl> wrote:
> kiedys (jakis kwartal temu) wymyslilem
> sentencje 'prawdziwy asemblerowiec
> pisze 365 razy dluzej 365 razy szybsza
> aplikacje' (notabene w dokach ktore dzis
> czytalem asembler jest okreslany mianem
> 'dark art')
> mimochodem
... nie da sie. Wspolczesne kompilatory odwalaja calkiem
niezly kawal roboty, dawno dawno temu na amidze probowalem
robic takie zabawy i kod przepisany na asembler z lednoscia
udawalo sie napisac 2 razy szybciej (2 miesiace optymalizacji
w miare krotkiego programu). Podejrzewam, ze przy wspolczesnych
kompilatorach bym sie tego nie podjal. Z powazaniem
Adam Przybyla

do góry

W dniu 2011-04-04 07:02, Adam Przybyla pisze:

> ... nie da sie. Wspolczesne kompilatory odwalaja calkiem
> niezly kawal roboty, dawno dawno temu na amidze probowalem
> robic takie zabawy i kod przepisany na asembler z lednoscia
> udawalo sie napisac 2 razy szybciej (2 miesiace optymalizacji
> w miare krotkiego programu). Podejrzewam, ze przy wspolczesnych
> kompilatorach bym sie tego nie podjal. Z powazaniem


Da się, trzeba tylko odpowiednio kretyńsko pisać w odpowiednim
wysokopoziomowym 'języku'.

tic,
t=[];
for j=0:10^5,
t=[t;sin(j*2*pi/10^5)];
end,
toc

-> Elapsed time is 13.286814 seconds.


Dziubdziając to w asm pół wieczora zbije
czas 1000 razy.. albo napisze 'po ludzku'

tic,
x=linspace(0,2*pi,10^5+1);
t2=sin(x);
toc
-> Elapsed time is 0.004445 seconds.


pozdrawiam
bartekltg

do góry