Autor: Krzysztof Goworek (krzys_at_enpol.gliwice.pl)
Data: Fri 11 Sep 1998 - 11:25:09 MET DST
Vindex napisał(a) w wiadomości: <35f81301.841296_at_news.fuw.edu.pl>...
>On Fri, 11 Sep 1998 15:59:23 +0200, "Krzysztof Goworek"
><krzys_at_enpol.gliwice.pl> wrote:
(...)
>>>Probowales pisac kiedys AI? Ja nie - wiec wstrzymam sie ze skomentowaniem
>>To dlaczego podajesz jako przyklad ?
>
>Jako przyklad tego ze poza wizualizacja jest jeszcze pare innych
>rzeczy w grach. Poniewaz nie wiem na ile da sie zastosowac SIMD przy
>programowaniu AI to nie pisze o konkretach - niewykluczone jest jednak
>ze sie da
>
>>>tego. Poza tym pozostaje rowniez kwestia przygotowania danych do
>>>wizualizacji - tu SIMD moze sie jak najbardziej przydac
>>Co masz dokladnie na mysli piszac przygotowanie danych ?
>
>Wszelkiego typu transformacje wierzcholkow, przeliczenia bryl itp. Do
>tego akurat SIMD nadaje sie bardzo dobrze.
To jest geometria i tym powinno zajmowac sie API (i sie zajmuje).
(...)
>Nie bylbym pewien czy w calosci - zwlaszcza biorac pod uwage to ze np.
>w DX'ie ma sie do wyboru albo wygode albo szybkosc. Majac pod reka
>ograniczona ilosc operacji i tak musisz cos optymalizowac
Napisalem: zda to egzamin, jezeli bedzie dobre i optymalne API.
(...)
>>>A wiec jednak zgadzasz sie ze mna ze programy optymalizuje sie pod procesor?
>>Siur. Chodzi o to, by nie trzeba bylo tego robic. Program nie powinien opierac sie
>>o architekture procesora. I to powinny zapewniac biblioteki i kompilator.
>
>Kompilator nigdy nie zapewni odpowiedniego poziomu optymalizacji -
>chyba ze bedzie napisany pod konkretny typ aplikacji. Skoro
>optymalizuje sie oprogramowanie pod konkretny procesor to widac warta
>skorka wyprawki - efekty nie sa widac tak mizerne jak twierdzisz
Zapewni - na najnizszym poziomie. Dla programisty pozostaje napisac
optymalnie na wyzszym poziomie. I Nie pisze tu o instrukcjach specjalnych - 3d.
To nalezy do biblioteki.
(...)
>Owszem - tylko ze wtedy to API stanie sie nieoptymalne z zalozenia.
>Sam wiesz ze im program wiekszy tym trudniej go dostosowac do
>nietypowych zastosowan
Ale jest jedno zastosowanie: grafika 3d.
>
>>No, moze. Dla chcacego nie ma nic trudnego. Chodzi o to, ze jezeli program bedzie tak napisany
>>i jednoczesnie API bedzie obslugiwalo (w optymalny sposob) obydwa procesory, to roznica w
>>predkosci dzialania programu bedzie zalezala tylko od roznicy w predkosci procesorow.
>
>
>Zakladajac ze cos takiego da sie osiagnac - w wypadku innej filozofii
>dzialania zastosowanej w procesorach moze to byc bardzo trudne. A
>takie API nie bedzie w tym momencie optymalne dla zadnego procesora -
>bedzie _dosc_ optymalne na obu
Nie mowie o jednym kodzie dla kazdego procesora. Kazdy procesor powinien miec
swoj kod, wybierany na etapie instalacji.
>>Chodzi o to (sedno calej sprawy), by API bylo _dobrze_ napisane. Direct3D posiada obsluge
>>geometrii, ale nikt z tego nie korzysta, bo nie dosc ze zagmatwane, to jeszcze nieoptymalne.
>
>Ano wlasnie - nieoptymalne. Trudno jest dostosowac API do wymagan
>wszystkich programistow
Mowimy o podstawowych operacjach. Na wektorach duzo sie wymyslic nie da. Podstawowe
przeksztalcenia (zoptymalizowane) + operacje na macierzach.
>>Wiec kazdy pisze swoje kawalki kodu, ktore sa zazwyczaj zoptymalizowane na intela.
>>BTW: ciekawe ile % zysku daloby przerobienie quaka na AMD (nie K6-2). Fakt, ze ma ciankiego
>>koproca, ale z drugiej strony mozna by nieco to poprawic ukladajac odpowiednio instrukcje...
>
>Troche pewnie by dalo - ale na zadne cuda bym nie liczyl. Sam widzisz
>ze optymalizacja kodu a nie API daje wieksze mozliwosci. Nie jest to
>moze najwygodniejsze dla programistow ale cos za cos ...
Eehh.. Ty ciagle swoje... Wszystko zalezy od tego, czy program korzysta ze wszystkich
mozliwosci API, czy tylko na ostatnim, akcelerowanym etapie. Do tej pory nie bylo sensu,
jednak moze sie to zmieni.
>>>J.w. Wizualizacja na czyms sie opiera
>>Na czym ?
>
>Na danych przygotowanych przez procesor - od tego przygotowania zalezy
>czy program bedzie dzialal szybciej czy wolniej. Nie ma mozliwosci
>zoptymalizowania tego procesu tak aby na wszystkich procesorach byl
>optymalny. Cos za cos
He, znowu zero konkretow. Przygotowanie danych... Ladowanie z dysku ?
To co pisales wczesniej (przeksztalcenia bryl, itp.) powinno byc oparte o API
(znowu ten akronim, czy jak to sie tam zwie...).
>>>Jest - tyle ze i tak dziala z przerobiona wersja Quake'a. Jak myslisz -
>>>czemu?
>>Nie wiem. Pewnie tak go napisali...
>
>To nie jest kwestia napisania - skoro tak jest to znaczy ze lepsze
>efekty uzyskali poprzez optymalizacje kodu niz przez optymalizacje
>API/sterownikow.
To wszystko, to tylko domysly. Poczekajmy az opublikuja zrodla Quaka1/2, to sie
przekonamy, jak jest naprawde... ;-)
Dodam tylko jedno: nie mowie, ze tak jest. Ale tak powinno byc, ze programista
aplikacji nie powinien optymalizowac kodu do procesora. To powinien zapewniac
kompilator, biblioteki, system i Bog (wybacz) wie jeszcze co...
-- _____________________________________________________________________ | full name: Krzysztof Goworek, sex: male, occupation: developer | | mailto:kabel_at_zeus.polsl.gliwice.pl || mailto:krzys_at_enpol.gliwice.pl | |_____________________________________________________________________|
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 17:36:09 MET DST