Komentowana treść: Amiga X Party - pierwsze zdjęcia
29.02.2012 00:14
[#93]
Re: Amiga X Party - pierwsze zdjęcia
@Radov, post #87
Dlatego bardzo bym chciał, żebyś zajął się precyzowaniem założeń, które podałeś w wiadomościach #64 i #67, a nie znacznie je zmieniał tak jak to zrobiłeś w #70.
To nieprawda. W #70 je właśnie sprecyzowałem, w #75 dołożyłem Ci wartości numeryczne kryteriów.
Bądź teraz konsekwentny. Wiadomości #70 i #75 są pewnie bardzo ciekawe, szkoda tylko, że mało związane z treściami, które sprokurowały Cię do zaproponowania eksperymentu.
Jestem konsekwentny. Wiadomości #70 i #75 są uściśleniem #64 i #67.
Po prostu ciekawi mnie, że tk piszesz o PA6T, jakbyś te materiały jednak już miał (nie, samo odniesienie do G5 nie wystarczy, jeśli nie uwzględnisz różnic w wydajności RAM...)
Wcale Cię nie ciekawi, z tego prostego powodu, że nigdzie tak nie piszę. Informacje o potokach jednostek AltiVec w PA6T zaczerpnąłem z tego obrazka. Jeżeli uważasz, że są na nim błędy, podaj lepszą literaturę.
Oj nie... Chciałbym żebyś to zrobił po raz pierwszy.
Patrz posty #70 i #75.
Jak na razie zaproponowałeś jakiś dziwny podział nie wiadomo skąd. Skończmy więc już z dziwnymi i daj jakiś dobry - spójny ze stwierdzeniami jakie zaproponowałeś w wiadomościach #64 i #67
Co można poradzić na Twój ośli upór. Post #64 jest tylko o AltiVecu, czy to dociera do Ciebie po jego przeczytaniu? Co za tym idzie, post #67 jest też tylko o AltiVecu, co zresztą wynika z samej jego treści nawet nie popartej lekturą #64.
Intrygujące, bo ile razy czytam kluczową tu wypowiedź z wiadomości #64: "Tak czy inaczej najmniej PA6T dostanie w plecy przy aplikacjach altivecowych ostro męczących jednostkę permutacji (kryptografia), a najbardziej przy zmiennoprzecinkowych (hello LAME...). " - to tyle razy widzę, że odnosisz się do PA6T i gdzie ten CPU dostanie w plecy mniej, a gdzie więcej. Nie ma tu ograniczenia wyłącznie do altiveca
Widzisz słowo „altivecowych” w pierwszym zdaniu, czy też może umknęło ono Twojej uwadze? Jest tu ograniczenie wyłącznie do AltiVeca.
Gdzie można zaobserwować "zmianę tematu dyskusji" na przestrzeni 2 wiadomości?
Otóż właśnie nigdzie nie można, cieszę się, że w końcu to zauważyłeś, chociaż w #77 o zmianie podmiotu dyskusji pisałeś. Brak konsekwencji z Twojej strony. Od postu #64 w dół tematem jest AltiVec.
To co było później to tylko moje pytanie, dlaczego teza z #64 (na którą zaproponowałeś eksperyment) i #70 (po tym jak poprosiłem o sprecyzowanie) się różnią. Nadal czekam na odpowiedź.
Odpowiedź jest prosta. One się nie różnią. W #70 następuje sprecyzowanie tezy i sformułowanie jej w nieco bardziej formalnym języku.
Sorry. To ta wypowiedź o dostawaniu w plecy przez PA6T w aplikacjach altivecowych mnie zmyliła. Muszę zapamiętać, że jak coś piszesz, to tak naprawdę nie masz tego na myśli...
Zmyliła? Specjalnie pominąłeś słowo „altivecowych”.
No to całe szczęście, że pojęcie "dostawania w plecy" jest za to zdefiniowane... a nie, nie jest. do tej pory nie wyjaśniłeś co miałeś na myśli w wiadomości #64.
Owszem, wyjaśniłem. #70 i #75 zawierają kompletne i spójne logicznie wyjaśnienie. Zauważyłbyś to z pewnością, gdyby Ci zależało na ustaleniu naukowej prawdy a nie prozaicznym przegadaniu mnie.
No i jak na razie zaproponowałeś eksperyment polegający w wybraniu jednego podzagadnienia korzystnego dla G4. Możesz mi wyjaśnić jak możesz jednocześnie radzić by coś robić i by tego nie robić? Jestem naprawdę zafascynowany
To proste. Tylko AltiVec był przedmiotem całej tej dyskusji. Od postu #64 poczynając.
Ja napisałem o energooszczędności w wiadomości #57 (odnosząc się przy okazji do znajomości specyfikacji), a ty w odpowiedzi zrobiłeś w #64 analizę altiveca podsumowując jak w tych aplikacjach sprawdzi się PA6T. Serio twierdzisz, że wiadomości #57 i #64 to dwa różne miejsca portalu, a to że w #64 piszesz o altivecu, wcale nie oznacza, że piszesz o altivecu? Doprawdy ciężko jest mi pojąć takie rozumowanie....
Tylko że post #57 nie jest dyskusją ze mną, cytujesz tam tylko moją wypowiedź z innego miejsca portalu. Ja w #64 się do tego cytatu nie odnoszę. Cieszę się, że w końcu po kręceniu przez kilka postów zauważyłeś, że w #64 piszę o AltiVecu. Nie można było tak od razu? Nie możesz się jakoś powstrzymać od zaprzeczania samemu sobie? To by znacznie uporządkowało ten wątek i może znacznie więcej byłbyś w stanie z niego pojąć.
Czekaj, czekaj.... czyli teza podsumowująca #64, że PA6T uzyska rezultaty złe albo gorsze jest jednak nieprawdziwa....?
Sprytne uogólnienie, ale pamiętaj, że uogólnianie tezy nie podtrzymuje jej prawdziwości. Między „istnieje takie X, że zachodzi Y” a „dla każdego X zachodzi Y” jest zasadnicza różnica, którą właśnie raczyłeś zignorować. Przypomnę po raz kolejny (niestety muszę, Twoje problemy z logiką zmuszają mnie do tego), że post #64 dotyczy AltiVeca. Jeżeli napiszemy kod, który będzie unikał AltiVeca, a intensywnie obciąży kontroler pamięci, to PA6T wykona go szybciej. Jak chociażby testy kopiowania plików przeprowadzone przez Mufę.
I nie ma problemu zrobić aplikację, która na PA6T będzie działać lepiej?
To zależy od tego w jaki sposób aplikacja wykorzystuje procesor. Daruj sobie to udawane zdziwienie, przecież w testach robionych przez Mufę i Piru wystąpiły aplikacje, które na PA6T działały szybciej.
To nad czym w ogóle chciałeś eksperymentować w #67? a no tak....
Ech... Nad AltiVecem chciałem eksperymentować. „Zaproponuj zagadnienie do zaimplementowania w AltiVecu.”. Jak mam to jeszcze napisać? Rosztrzelonym tekstem, na czerwono, a może cyrylicą?
Co z tego że Altivec w G4 może ciut szybciej przetwarzać dane, jeśli równocześnie ciut częściej ich nie ma. Obawiam się, że po "szybszym nic nie robieniu na pamięci" zaraz udowodnisz "szybsze nieprzetwarzanie danych". Normalnie super rzetelne testy...
Przypominam, test kompresji pliku AKsack.wav, programem LAME, PA6T @ 1,8 GHz - 18 sekund, 7447A @ 1,67 GHz - 15 sekund. Sugerujesz, że to nicnierobienie na pamięci i szybsze nieprzetwarzanie danych? To może z faktami sobie teraz podyskutujesz?
Ja tylko chcę się dowiedzieć, dlaczego zaproponowałeś pewien eksperyment, a potem zacząłeś zmieniać jego zakres.
Nie da się dowiedzieć czegokolwiek o fakcie niebyłym.
Inna sprawa, że wątpię, by te kolejne miały dać jakikolwiek obraz Altiveca w obu prockach
Wyniki testów dają dobry obraz. Można co najwyżej próbować ten obraz wyjaśnić, ale do tego potrzebna jest szczegółowa dokumentacja PA6T, której nie ma.
Ostatnia aktualizacja: 29.02.2012 00:17:00 przez krashan_
To nieprawda. W #70 je właśnie sprecyzowałem, w #75 dołożyłem Ci wartości numeryczne kryteriów.
Bądź teraz konsekwentny. Wiadomości #70 i #75 są pewnie bardzo ciekawe, szkoda tylko, że mało związane z treściami, które sprokurowały Cię do zaproponowania eksperymentu.
Jestem konsekwentny. Wiadomości #70 i #75 są uściśleniem #64 i #67.
Po prostu ciekawi mnie, że tk piszesz o PA6T, jakbyś te materiały jednak już miał (nie, samo odniesienie do G5 nie wystarczy, jeśli nie uwzględnisz różnic w wydajności RAM...)
Wcale Cię nie ciekawi, z tego prostego powodu, że nigdzie tak nie piszę. Informacje o potokach jednostek AltiVec w PA6T zaczerpnąłem z tego obrazka. Jeżeli uważasz, że są na nim błędy, podaj lepszą literaturę.
Oj nie... Chciałbym żebyś to zrobił po raz pierwszy.
Patrz posty #70 i #75.
Jak na razie zaproponowałeś jakiś dziwny podział nie wiadomo skąd. Skończmy więc już z dziwnymi i daj jakiś dobry - spójny ze stwierdzeniami jakie zaproponowałeś w wiadomościach #64 i #67
Co można poradzić na Twój ośli upór. Post #64 jest tylko o AltiVecu, czy to dociera do Ciebie po jego przeczytaniu? Co za tym idzie, post #67 jest też tylko o AltiVecu, co zresztą wynika z samej jego treści nawet nie popartej lekturą #64.
Intrygujące, bo ile razy czytam kluczową tu wypowiedź z wiadomości #64: "Tak czy inaczej najmniej PA6T dostanie w plecy przy aplikacjach altivecowych ostro męczących jednostkę permutacji (kryptografia), a najbardziej przy zmiennoprzecinkowych (hello LAME...). " - to tyle razy widzę, że odnosisz się do PA6T i gdzie ten CPU dostanie w plecy mniej, a gdzie więcej. Nie ma tu ograniczenia wyłącznie do altiveca
Widzisz słowo „altivecowych” w pierwszym zdaniu, czy też może umknęło ono Twojej uwadze? Jest tu ograniczenie wyłącznie do AltiVeca.
Gdzie można zaobserwować "zmianę tematu dyskusji" na przestrzeni 2 wiadomości?
Otóż właśnie nigdzie nie można, cieszę się, że w końcu to zauważyłeś, chociaż w #77 o zmianie podmiotu dyskusji pisałeś. Brak konsekwencji z Twojej strony. Od postu #64 w dół tematem jest AltiVec.
To co było później to tylko moje pytanie, dlaczego teza z #64 (na którą zaproponowałeś eksperyment) i #70 (po tym jak poprosiłem o sprecyzowanie) się różnią. Nadal czekam na odpowiedź.
Odpowiedź jest prosta. One się nie różnią. W #70 następuje sprecyzowanie tezy i sformułowanie jej w nieco bardziej formalnym języku.
Sorry. To ta wypowiedź o dostawaniu w plecy przez PA6T w aplikacjach altivecowych mnie zmyliła. Muszę zapamiętać, że jak coś piszesz, to tak naprawdę nie masz tego na myśli...
Zmyliła? Specjalnie pominąłeś słowo „altivecowych”.
No to całe szczęście, że pojęcie "dostawania w plecy" jest za to zdefiniowane... a nie, nie jest. do tej pory nie wyjaśniłeś co miałeś na myśli w wiadomości #64.
Owszem, wyjaśniłem. #70 i #75 zawierają kompletne i spójne logicznie wyjaśnienie. Zauważyłbyś to z pewnością, gdyby Ci zależało na ustaleniu naukowej prawdy a nie prozaicznym przegadaniu mnie.
No i jak na razie zaproponowałeś eksperyment polegający w wybraniu jednego podzagadnienia korzystnego dla G4. Możesz mi wyjaśnić jak możesz jednocześnie radzić by coś robić i by tego nie robić? Jestem naprawdę zafascynowany
To proste. Tylko AltiVec był przedmiotem całej tej dyskusji. Od postu #64 poczynając.
Ja napisałem o energooszczędności w wiadomości #57 (odnosząc się przy okazji do znajomości specyfikacji), a ty w odpowiedzi zrobiłeś w #64 analizę altiveca podsumowując jak w tych aplikacjach sprawdzi się PA6T. Serio twierdzisz, że wiadomości #57 i #64 to dwa różne miejsca portalu, a to że w #64 piszesz o altivecu, wcale nie oznacza, że piszesz o altivecu? Doprawdy ciężko jest mi pojąć takie rozumowanie....
Tylko że post #57 nie jest dyskusją ze mną, cytujesz tam tylko moją wypowiedź z innego miejsca portalu. Ja w #64 się do tego cytatu nie odnoszę. Cieszę się, że w końcu po kręceniu przez kilka postów zauważyłeś, że w #64 piszę o AltiVecu. Nie można było tak od razu? Nie możesz się jakoś powstrzymać od zaprzeczania samemu sobie? To by znacznie uporządkowało ten wątek i może znacznie więcej byłbyś w stanie z niego pojąć.
Czekaj, czekaj.... czyli teza podsumowująca #64, że PA6T uzyska rezultaty złe albo gorsze jest jednak nieprawdziwa....?
Sprytne uogólnienie, ale pamiętaj, że uogólnianie tezy nie podtrzymuje jej prawdziwości. Między „istnieje takie X, że zachodzi Y” a „dla każdego X zachodzi Y” jest zasadnicza różnica, którą właśnie raczyłeś zignorować. Przypomnę po raz kolejny (niestety muszę, Twoje problemy z logiką zmuszają mnie do tego), że post #64 dotyczy AltiVeca. Jeżeli napiszemy kod, który będzie unikał AltiVeca, a intensywnie obciąży kontroler pamięci, to PA6T wykona go szybciej. Jak chociażby testy kopiowania plików przeprowadzone przez Mufę.
I nie ma problemu zrobić aplikację, która na PA6T będzie działać lepiej?
To zależy od tego w jaki sposób aplikacja wykorzystuje procesor. Daruj sobie to udawane zdziwienie, przecież w testach robionych przez Mufę i Piru wystąpiły aplikacje, które na PA6T działały szybciej.
To nad czym w ogóle chciałeś eksperymentować w #67? a no tak....
Ech... Nad AltiVecem chciałem eksperymentować. „Zaproponuj zagadnienie do zaimplementowania w AltiVecu.”. Jak mam to jeszcze napisać? Rosztrzelonym tekstem, na czerwono, a może cyrylicą?
Co z tego że Altivec w G4 może ciut szybciej przetwarzać dane, jeśli równocześnie ciut częściej ich nie ma. Obawiam się, że po "szybszym nic nie robieniu na pamięci" zaraz udowodnisz "szybsze nieprzetwarzanie danych". Normalnie super rzetelne testy...
Przypominam, test kompresji pliku AKsack.wav, programem LAME, PA6T @ 1,8 GHz - 18 sekund, 7447A @ 1,67 GHz - 15 sekund. Sugerujesz, że to nicnierobienie na pamięci i szybsze nieprzetwarzanie danych? To może z faktami sobie teraz podyskutujesz?
Ja tylko chcę się dowiedzieć, dlaczego zaproponowałeś pewien eksperyment, a potem zacząłeś zmieniać jego zakres.
Nie da się dowiedzieć czegokolwiek o fakcie niebyłym.
Inna sprawa, że wątpię, by te kolejne miały dać jakikolwiek obraz Altiveca w obu prockach
Wyniki testów dają dobry obraz. Można co najwyżej próbować ten obraz wyjaśnić, ale do tego potrzebna jest szczegółowa dokumentacja PA6T, której nie ma.
Ostatnia aktualizacja: 29.02.2012 00:17:00 przez krashan_
29.02.2012 00:52
[#94]
Re: Amiga X Party - pierwsze zdjęcia
@krashan_, post #93
Tak Was obu czytam i wlasciwie nic nie wiem, bo nic z tego nie wynika, choc obaj naprawde duzo napisaliscie :). Nadal nie wiem ktory SIMD jest wydajniejszy. Brak testow typu np: mnozen macierzy przez macierz dla liczb rzeczywistych roznej precyzji itp...itd..., w przeliczeniu na Mhz, Wat...
Ostatnia aktualizacja: 29.02.2012 01:05:32 przez gx
Ostatnia aktualizacja: 29.02.2012 01:05:32 przez gx
29.02.2012 06:45
[#96]
Re: Amiga X Party - pierwsze zdjęcia
@gx, post #94
Nadal nie wiem ktory SIMD jest wydajniejszy. Brak testow typu np: mnozen macierzy przez macierz dla liczb rzeczywistych roznej precyzji itp...itd..., w przeliczeniu na Mhz, Wat...
Można to streścić następująco:
1. Fakt: w testach programem LAME akcelerowanym AV dla przykładowego pliku WAVE około 42 MB PA6T @ 1,8 GHz uzyskał czas 18 sekund, G4 @ 1,67 MHz uzyskał czas 15 sekund.
2. Z tego robię założenie, że AV w G4 jest wydajniejszy. Radov sugeruje, że to dlatego, że LAME nie jest zoptymalizowany pod PA6T. Ja na to, że AV w PA6T jest po prostu konstrukcyjnie wolniejszy i optymalizacja (cokolwiek by miała oznaczać) zwyczajnie nie pomoże. Dokładam, że jeżeli uważa, że winny jest brak optymalizacji, to może zrobimy jakiś teścik AltiVeca, który on zoptymalizuje dla PA6T i porównamy wyniki.
3. Radovowi to nie w smak, zaczyna uprawiać filozofię, zaprzeczać sam sobie, wciskać mi, że powiedziałem coś, czego nie powiedziałem, względnie sam nie wiem co powiedziałem, albo że wziąłem coś z sufitu i tak dalej. Przeciwko moim konkretom nie postawił nic konkretnego, tylko bujną retorykę.
Po analizie wyników testów i tego co mogłem sobie poczytać o procesorze PA6T, uważam, że z MHz trochę wydajniejszy jest AltiVec w G4, nie jest to wielka przewaga i często będzie równoważona szybkością kontrolera pamięci (np. w teście z artykułu Lockheeda Martina, albo w teście dekodowania video). Z wata wydajniejszy AltiVec jest w PA6T, bo ten procesor ma znacznie mniejszy pobór mocy.
Ostatnia aktualizacja: 29.02.2012 06:59:00 przez krashan_
Można to streścić następująco:
1. Fakt: w testach programem LAME akcelerowanym AV dla przykładowego pliku WAVE około 42 MB PA6T @ 1,8 GHz uzyskał czas 18 sekund, G4 @ 1,67 MHz uzyskał czas 15 sekund.
2. Z tego robię założenie, że AV w G4 jest wydajniejszy. Radov sugeruje, że to dlatego, że LAME nie jest zoptymalizowany pod PA6T. Ja na to, że AV w PA6T jest po prostu konstrukcyjnie wolniejszy i optymalizacja (cokolwiek by miała oznaczać) zwyczajnie nie pomoże. Dokładam, że jeżeli uważa, że winny jest brak optymalizacji, to może zrobimy jakiś teścik AltiVeca, który on zoptymalizuje dla PA6T i porównamy wyniki.
3. Radovowi to nie w smak, zaczyna uprawiać filozofię, zaprzeczać sam sobie, wciskać mi, że powiedziałem coś, czego nie powiedziałem, względnie sam nie wiem co powiedziałem, albo że wziąłem coś z sufitu i tak dalej. Przeciwko moim konkretom nie postawił nic konkretnego, tylko bujną retorykę.
Po analizie wyników testów i tego co mogłem sobie poczytać o procesorze PA6T, uważam, że z MHz trochę wydajniejszy jest AltiVec w G4, nie jest to wielka przewaga i często będzie równoważona szybkością kontrolera pamięci (np. w teście z artykułu Lockheeda Martina, albo w teście dekodowania video). Z wata wydajniejszy AltiVec jest w PA6T, bo ten procesor ma znacznie mniejszy pobór mocy.
Ostatnia aktualizacja: 29.02.2012 06:59:00 przez krashan_
29.02.2012 09:29
[#97]
Re: Amiga X Party - pierwsze zdjęcia
@Aniol, post #95
Mnie wczoraj korciło aby zapytać Radova co miał z logiki bo zaczął bredzić trochę, gubić się. Przeszło mi też przez myśl aby napisać prostymi słowami to co Krashan próbuje mu przekazać, ale... ugryzłem się w język i powstrzymałem bo pomyślałem, że potem może mnie czekać dyskusja i wjaśnianie co znaczą moje słowa, co miałem na myśli itp. Odpuściłem sobie. Szkoda czasu. :)
Za to z przyjemnością czyta się jasne i rzeczowe wywody Krashana. To duży plus dla portalu, że się tutaj udziela, bo zawsze czegoś ciekawego i konkretnego człowiek się dowie.
Bez wazeliny, ot takie spostrzeżnie mam.
A żeby coś było w temacie to napisze tak:
- przeciętnego końcowego użytkownika może nie interesować czy LAME jest zoptymalizowane czy nie dla danego procesora a nawet systemu,
- siadając do postawionych obok siebie kompów - jeden X1000 drugi ten MAC Krashana - taki użytkownik odpali najnowszą wersję LAME dostępną dla danego systemu i przekoduje ten sam plik,
- ten komputer który zrobi to w krótszym czasie będzie dla niego szybszym - proste. :)
X1000 ma potencjał, pytanie tylko jak i kiedy zostanie on wykorzystany. To pytanie pojawia się już gdzieś tak od 2 lat?
Ostatnia aktualizacja: 29.02.2012 09:48:34 przez Deftronic/...
Za to z przyjemnością czyta się jasne i rzeczowe wywody Krashana. To duży plus dla portalu, że się tutaj udziela, bo zawsze czegoś ciekawego i konkretnego człowiek się dowie.
Bez wazeliny, ot takie spostrzeżnie mam.
A żeby coś było w temacie to napisze tak:
- przeciętnego końcowego użytkownika może nie interesować czy LAME jest zoptymalizowane czy nie dla danego procesora a nawet systemu,
- siadając do postawionych obok siebie kompów - jeden X1000 drugi ten MAC Krashana - taki użytkownik odpali najnowszą wersję LAME dostępną dla danego systemu i przekoduje ten sam plik,
- ten komputer który zrobi to w krótszym czasie będzie dla niego szybszym - proste. :)
X1000 ma potencjał, pytanie tylko jak i kiedy zostanie on wykorzystany. To pytanie pojawia się już gdzieś tak od 2 lat?
Ostatnia aktualizacja: 29.02.2012 09:48:34 przez Deftronic/...
29.02.2012 12:30
[#102]
Re: Amiga X Party - pierwsze zdjęcia
@krashan_, post #93
@anioł
No trochę mi przykro, że mdli - ale się nie obrażam :) Ja doskonale rozumiem, że to temat trudny - a forma w jakiej będzie prowadzona dla osób postronnych będzie dziwna. Dlatego wolałem prowadzić ją osobiście na Amiwawie, a że jednak wyszło tutaj....
@krashan_
Żeby wiadomości nie rozrastały się w nieskończoność postaram się je pogrupować na najważniejsze wątki. Jakbym jakiś istotny pominął - nie wahaj się go przywrócić
Tłumaczę:
1. w wiadomości #64 dokonałeś wstępnego podziału obszarów wydajności PA6T w aplikacjach na dwie klasy:
- "dostać w plecy" (DWP) oraz
- "bardzo dostać w plecy" (BDWP)
To co napisałeś w wiadomościach kolejnych spowosodowało, że mam wrażenie, że wcześniej podany obszar wydajności "DWP" zawiera się jednak w (BDWP). Dlatego chciałem, żebyś to PRECYZYJNIE wyjaśnił, by uniknąć sytuacji w której aktywne będą jednocześnie dwie klasyfikacje.
2. Podział graniczny zaproponowany w kolejnych wiadomościach jest bardzo wąski, można go sprowadzić do klasyfikacji binarnej. Wg mnie nie ma on większego sensu i nie jestem pewien, czy jest użyteczny w "eksperymencie".
3. Dlatego vhciałbym, żebyś (w takim razie - jeszcze raz) wypełnił tę klasyfikację, ale w formie, którą podałem kilka wiadomości później, z jednoznacznie zaznaczonymi przedziałami wartości.
4. Chciałbym, ale już niekoniecznie, żeby obszary DWP i BDWP z wiadomości #64 wypadały także w tych obszarach w nowej klasyfikacji. Jeśli jednak to pierwsze to był luźny podział, może dokonany na fali emocji - to ok. Po prostu to napisz i nie będę tego oczekiwał.
W wiadomości #64 jednoznacznie oceniłeś oba układy za pomocą analizy specyfikacji ALtiveca - więc jednak to zrobiłeś. Uważam, że z tego obrazka możesz również wywnioskować jaki jest najbardziej niekorzystny przypadek potrzebnego latency - i na jego podstawie możesz ocenić, czy da się zoptymalizować kod by działał porównywalnie wydajnie na PA6T. Załóżmy, że parametry czasowe ze względu na potok są (strzelam) 2x gorsze dla PA6T. Pytam sie więc:
- czy takie parametry uniemożliwią optymalne wykorzystanie potoku, czy wciąż będzie to możliwe?
- czy też potrzeba na to eksperymentu?
- jeśli eksperymentu, to dlaczego dokonałeś oceny przed eksperymentem, na podstawie 1 testu (LAME) nawet niezgodnego z jego założeniami?
1. Grzegorzu - w podsumowaniu wiadomości #64 do której JA z kolei się odnosiłem jest nie tylko słowo "Altivec". Tam jest wyrażenie "Aplikacje Altivecowe". I ocena, że na PA6T będą działać gorzej niż na G4.
Moje pytanie było: skąd takie założenie? Długi potok Altivecu to nie jedyny element wpływający na wydajność tych aplikacji - więc skąd taki wniosek?
Zgadzam się, że i ja mogłem przesadzić swoim stwierdzeniu podsumowującym odpowiedź na #64 - ale dla tego też z zainteresowaniem przyjąłem propozycję eksperymentu. Jeśli jednak, jak raczej wynika z kolejnych, wiadomości mamy się ograniczyć TYLKO do Altivecu i pominąć usprawnienia PA6T pozwalające efektywniej wykorzystać PA6T - to raczej nie mamy o czym mówić..
2. To co pojawiło się w kolejnych wiadomościach to zmiana słowa "aplikacje" na "algorytmy". To są dwa różne obszary funkcjonalne - z czego ten pierwszy warto przetestować, a ten drugi: nie ma większego sensu, bo nie przekłada się na rzeczywistą wydajność całego układu.
Moje pytanie było: dlaczego gdy odniosłem się do "aplikacji altivecowych" - ty zaproponowałeś eksperyment na "algorytmy altivecowe"? "Aplikacje altivecowe" to szersze pojęcie niż "algorytmy altivecowe" i nie możesz tak po prostu sobie ich zmieniać.
3. Dlaczego chcesz eksperymentować przy ściśle określonych założeniach wykluczających korzystne dla PA6T rozwiązania? Można napisać także i aplikację i "algorytm altivecowy", które z tych rozwiązań będą korzystać. Można tez próbować tego nie robić - ale i tak będą miały wpływ na wynik.
Pisząc tu "nad czym w ogóle" zastosowałem emfazę, która miała brzmieć jak "Czy widzisz sens w...". Piszę więc jasno: jaki jest sens eksperymentowania nad "Altiveciem", przy założeniach jakie podajesz - jeśli wydajność w rzeczywistych zastosowaniach i tak będzie wypadkową wydajności interfejsu pamięci?
1. Sugeruję, że przy próbie sprecyzowania warunków eksperymentu odrzucasz te, które są korzystne dla PA6T, a przy których G4 mimo, że chciałoby liczyć - nie miałoby czego. W efekcie czego, w istotnej części rzeczywistych przypadków, AV w G4 NIE przetwarza danych.
2. Fakty też są takie, że odwołujesz się do testu niezoptymalizowanego algorytmu, a traktujesz go jako potwierdzenie różnic konstrukcyjnych.
3. Jeśli chcesz zbadać różnice konstrukcyjne Altiveców (już nawet nie na polu wydajności aplikacji altivecowych, tylko jakichś specyficznych układów) to właśnie o istotnym elementem jest to, że PA6T potrafi wydajniej karmić AV danymi. Nie możemy tego odrzucić tylko dlatego, bo w G4 tego nie ma.
Grzegorzu - proszę, w takim razie wyjaśnij. W wiadomości #64, po analizie altiveca, napisałeś że na PA6T **Aplikacje Altivecowe** będą działać gorzej, albo jeszcze gorzej. Moim zdaniem to ty zastosowałeś to uogólnienie. Owszem: istnieją takie aplikacje, które na PA6T będą działać gorzej niż na G4 - ale też są takie aplikacje altivecowe, które na PA6T będą działać lepiej - ale to nie to napisałeś. Właśnie *TAM* dokonałeś uogólnienia.
Ja czytalem tylko Krashana A kolege Radova odpuscilem niestety bo lekko mnie mdli od jego wywodów,ale proszę ,żeby sie nie obrażałOK
No trochę mi przykro, że mdli - ale się nie obrażam :) Ja doskonale rozumiem, że to temat trudny - a forma w jakiej będzie prowadzona dla osób postronnych będzie dziwna. Dlatego wolałem prowadzić ją osobiście na Amiwawie, a że jednak wyszło tutaj....
@krashan_
Żeby wiadomości nie rozrastały się w nieskończoność postaram się je pogrupować na najważniejsze wątki. Jakbym jakiś istotny pominął - nie wahaj się go przywrócić
To nieprawda. W #70 je właśnie sprecyzowałem, w #75 dołożyłem Ci wartości numeryczne kryteriów. (...) Jestem konsekwentny. Wiadomości #70 i #75 są uściśleniem #64 i #67. (...) Patrz posty #70 i #75.
Tłumaczę:
1. w wiadomości #64 dokonałeś wstępnego podziału obszarów wydajności PA6T w aplikacjach na dwie klasy:
- "dostać w plecy" (DWP) oraz
- "bardzo dostać w plecy" (BDWP)
To co napisałeś w wiadomościach kolejnych spowosodowało, że mam wrażenie, że wcześniej podany obszar wydajności "DWP" zawiera się jednak w (BDWP). Dlatego chciałem, żebyś to PRECYZYJNIE wyjaśnił, by uniknąć sytuacji w której aktywne będą jednocześnie dwie klasyfikacje.
2. Podział graniczny zaproponowany w kolejnych wiadomościach jest bardzo wąski, można go sprowadzić do klasyfikacji binarnej. Wg mnie nie ma on większego sensu i nie jestem pewien, czy jest użyteczny w "eksperymencie".
3. Dlatego vhciałbym, żebyś (w takim razie - jeszcze raz) wypełnił tę klasyfikację, ale w formie, którą podałem kilka wiadomości później, z jednoznacznie zaznaczonymi przedziałami wartości.
4. Chciałbym, ale już niekoniecznie, żeby obszary DWP i BDWP z wiadomości #64 wypadały także w tych obszarach w nowej klasyfikacji. Jeśli jednak to pierwsze to był luźny podział, może dokonany na fali emocji - to ok. Po prostu to napisz i nie będę tego oczekiwał.
Wcale Cię nie ciekawi, z tego prostego powodu, że nigdzie tak nie piszę.
W wiadomości #64 jednoznacznie oceniłeś oba układy za pomocą analizy specyfikacji ALtiveca - więc jednak to zrobiłeś. Uważam, że z tego obrazka możesz również wywnioskować jaki jest najbardziej niekorzystny przypadek potrzebnego latency - i na jego podstawie możesz ocenić, czy da się zoptymalizować kod by działał porównywalnie wydajnie na PA6T. Załóżmy, że parametry czasowe ze względu na potok są (strzelam) 2x gorsze dla PA6T. Pytam sie więc:
- czy takie parametry uniemożliwią optymalne wykorzystanie potoku, czy wciąż będzie to możliwe?
- czy też potrzeba na to eksperymentu?
- jeśli eksperymentu, to dlaczego dokonałeś oceny przed eksperymentem, na podstawie 1 testu (LAME) nawet niezgodnego z jego założeniami?
Co można poradzić na Twój ośli upór. Post #64 jest tylko o AltiVecu, czy to dociera do Ciebie (...) Widzisz słowo "altivecowych" w pierwszym zdaniu, czy też może umknęło ono Twojej uwadze? Jest tu ograniczenie wyłącznie do AltiVeca. (...) Od postu #64 w dół tematem jest AltiVec. (...) To proste. Tylko AltiVec był przedmiotem całej tej dyskusji. Od postu #64 poczynając. (...) Odpowiedź jest prosta. One się nie różnią. W #70 następuje sprecyzowanie tezy i sformułowanie jej w nieco bardziej formalnym języku.
1. Grzegorzu - w podsumowaniu wiadomości #64 do której JA z kolei się odnosiłem jest nie tylko słowo "Altivec". Tam jest wyrażenie "Aplikacje Altivecowe". I ocena, że na PA6T będą działać gorzej niż na G4.
Moje pytanie było: skąd takie założenie? Długi potok Altivecu to nie jedyny element wpływający na wydajność tych aplikacji - więc skąd taki wniosek?
Zgadzam się, że i ja mogłem przesadzić swoim stwierdzeniu podsumowującym odpowiedź na #64 - ale dla tego też z zainteresowaniem przyjąłem propozycję eksperymentu. Jeśli jednak, jak raczej wynika z kolejnych, wiadomości mamy się ograniczyć TYLKO do Altivecu i pominąć usprawnienia PA6T pozwalające efektywniej wykorzystać PA6T - to raczej nie mamy o czym mówić..
2. To co pojawiło się w kolejnych wiadomościach to zmiana słowa "aplikacje" na "algorytmy". To są dwa różne obszary funkcjonalne - z czego ten pierwszy warto przetestować, a ten drugi: nie ma większego sensu, bo nie przekłada się na rzeczywistą wydajność całego układu.
Moje pytanie było: dlaczego gdy odniosłem się do "aplikacji altivecowych" - ty zaproponowałeś eksperyment na "algorytmy altivecowe"? "Aplikacje altivecowe" to szersze pojęcie niż "algorytmy altivecowe" i nie możesz tak po prostu sobie ich zmieniać.
3. Dlaczego chcesz eksperymentować przy ściśle określonych założeniach wykluczających korzystne dla PA6T rozwiązania? Można napisać także i aplikację i "algorytm altivecowy", które z tych rozwiązań będą korzystać. Można tez próbować tego nie robić - ale i tak będą miały wpływ na wynik.
Ech... Nad AltiVecem chciałem eksperymentować. "Zaproponuj zagadnienie do zaimplementowania w AltiVecu.". Jak mam to jeszcze napisać? Rozstrzelonym tekstem, na czerwono, a może cyrylicą?
Pisząc tu "nad czym w ogóle" zastosowałem emfazę, która miała brzmieć jak "Czy widzisz sens w...". Piszę więc jasno: jaki jest sens eksperymentowania nad "Altiveciem", przy założeniach jakie podajesz - jeśli wydajność w rzeczywistych zastosowaniach i tak będzie wypadkową wydajności interfejsu pamięci?
Sugerujesz, że to nicnierobienie na pamięci i szybsze nieprzetwarzanie danych? To może z faktami sobie teraz podyskutujesz?
1. Sugeruję, że przy próbie sprecyzowania warunków eksperymentu odrzucasz te, które są korzystne dla PA6T, a przy których G4 mimo, że chciałoby liczyć - nie miałoby czego. W efekcie czego, w istotnej części rzeczywistych przypadków, AV w G4 NIE przetwarza danych.
2. Fakty też są takie, że odwołujesz się do testu niezoptymalizowanego algorytmu, a traktujesz go jako potwierdzenie różnic konstrukcyjnych.
3. Jeśli chcesz zbadać różnice konstrukcyjne Altiveców (już nawet nie na polu wydajności aplikacji altivecowych, tylko jakichś specyficznych układów) to właśnie o istotnym elementem jest to, że PA6T potrafi wydajniej karmić AV danymi. Nie możemy tego odrzucić tylko dlatego, bo w G4 tego nie ma.
Sprytne uogólnienie, ale pamiętaj, że uogólnianie tezy nie podtrzymuje jej prawdziwości. Między "istnieje takie X, że zachodzi"; a "dla każdego X zachodzi" jest zasadnicza różnica, którą właśnie raczyłeś zignorować.
Grzegorzu - proszę, w takim razie wyjaśnij. W wiadomości #64, po analizie altiveca, napisałeś że na PA6T **Aplikacje Altivecowe** będą działać gorzej, albo jeszcze gorzej. Moim zdaniem to ty zastosowałeś to uogólnienie. Owszem: istnieją takie aplikacje, które na PA6T będą działać gorzej niż na G4 - ale też są takie aplikacje altivecowe, które na PA6T będą działać lepiej - ale to nie to napisałeś. Właśnie *TAM* dokonałeś uogólnienia.
29.02.2012 12:50
[#103]
Re: Amiga X Party - pierwsze zdjęcia
@gx, post #94
A to moja wersja :)
Oba rozwiązania są zbliżone w założeniach, ale jest kilka szczegółów, przez które powstają spore różnice. PA6T ma lepszy przelicznik wydajności na wat (jak i cały układ), w przypadku "mhz" ciężko to stwierdzić bez eksperymentów.
W przypadku AV G4 możemy zauważyć:
- krótszy potok wykonawczy (prostsza optymalizacja)
- lepsze możliwości obsadzaniach jednostek wykonawczych (ale też nie każdym zastosowaniu
Ale występują następujące ograniczenia:
- cały układ może jednocześnie przetwarzać max 16 instrukcji (na różnych etapach). Oznacza to, że wydajność najbardziej złożonych algorytmów spadnie efektywnie do poziomu 1.45 / instrukcji takt (przy podawanej przez producenta średniej bodajże 2.3)
- jest ograniczony stosunkowo wolnymi interfejsami (względem PA6T). Więc mimo dość efektywnej konstrukcji - częściej po prostu nie ma co liczyć i musi czekać na dane.
W przypadku PA6T na korzyść przemawia:
- szybki interfejs pamięci
- brak ograniczeń na ilość jednocześnie wykonywanych instrukcji - tutaj 3.0 (PA6T nie powinien się "dławić", przy wykonywaniu instrukcji "wspierających" przetwarzanie kodu AV)
Ograniczenia:
- dłuższy potok wykonawczy - optymalny kod dla G4 nie musi być optymalny dla PA6T (co interesujące, w drugą stronę rezultaty byłyby bardziej korzystne)
- mniej korzystny podział jednostek AV - co jednak wymaga potwierdzenia z dokumentacją.
Podsumowując: teoretycznie G4 pozwala uzyskać lepsze wykorzystanie jego AV - z drugiej strony PA6T będzie liczył także wtedy gdy G4 będzie musiał stać w miejscu.
Pytanie brzmi - jak często i w jakich aplikacjach altivecowych obie sytuacje będą się zdarzać?
Moim zdaniem: sytuacja będzie przemawiać za PA6T.
Grzesiek jest przeciwnego zdania i uważa, że nie zoptymalizowany test nie uwzględniający różnić konstrukcyjnych układów - jest wystarczający by twierdzic inaczej.
Nadal nie wiem ktory SIMD jest wydajniejszy. Brak testow typu np: mnozen macierzy przez macierz dla liczb rzeczywistych roznej precyzji itp...itd..., w przeliczeniu na Mhz, Wat...
Oba rozwiązania są zbliżone w założeniach, ale jest kilka szczegółów, przez które powstają spore różnice. PA6T ma lepszy przelicznik wydajności na wat (jak i cały układ), w przypadku "mhz" ciężko to stwierdzić bez eksperymentów.
W przypadku AV G4 możemy zauważyć:
- krótszy potok wykonawczy (prostsza optymalizacja)
- lepsze możliwości obsadzaniach jednostek wykonawczych (ale też nie każdym zastosowaniu
Ale występują następujące ograniczenia:
- cały układ może jednocześnie przetwarzać max 16 instrukcji (na różnych etapach). Oznacza to, że wydajność najbardziej złożonych algorytmów spadnie efektywnie do poziomu 1.45 / instrukcji takt (przy podawanej przez producenta średniej bodajże 2.3)
- jest ograniczony stosunkowo wolnymi interfejsami (względem PA6T). Więc mimo dość efektywnej konstrukcji - częściej po prostu nie ma co liczyć i musi czekać na dane.
W przypadku PA6T na korzyść przemawia:
- szybki interfejs pamięci
- brak ograniczeń na ilość jednocześnie wykonywanych instrukcji - tutaj 3.0 (PA6T nie powinien się "dławić", przy wykonywaniu instrukcji "wspierających" przetwarzanie kodu AV)
Ograniczenia:
- dłuższy potok wykonawczy - optymalny kod dla G4 nie musi być optymalny dla PA6T (co interesujące, w drugą stronę rezultaty byłyby bardziej korzystne)
- mniej korzystny podział jednostek AV - co jednak wymaga potwierdzenia z dokumentacją.
Podsumowując: teoretycznie G4 pozwala uzyskać lepsze wykorzystanie jego AV - z drugiej strony PA6T będzie liczył także wtedy gdy G4 będzie musiał stać w miejscu.
Pytanie brzmi - jak często i w jakich aplikacjach altivecowych obie sytuacje będą się zdarzać?
Moim zdaniem: sytuacja będzie przemawiać za PA6T.
Grzesiek jest przeciwnego zdania i uważa, że nie zoptymalizowany test nie uwzględniający różnić konstrukcyjnych układów - jest wystarczający by twierdzic inaczej.
29.02.2012 13:13
[#104]
Re: Amiga X Party - pierwsze zdjęcia
@Deftronic/..., post #97
Mnie wczoraj korciło aby zapytać Radova co miał z logiki bo zaczął bredzić trochę, gubić się. Przeszło mi też przez myśl aby napisać prostymi słowami to co Krashan próbuje mu przekazać, ale...
Ale dlaczego mieszasz w to logikę, bredzenie i gubienie się?
Od samego początku piszę o tym samym - ocenie PA6T jakiej Krashan dokonał przez pryzmat jednego z elementów dokumentacji w wiadomości #64 i wynikającej z tego propozycji "eksperymentu".
Teza jest jedna i ją chcę obalić:
"Tak czy inaczej najmniej PA6T dostanie w plecy przy aplikacjach altivecowych ostro męczących jednostkę permutacji (kryptografia), a najbardziej przy zmiennoprzecinkowych (hello LAME...). "
Jak możesz zobaczyć po wiadomości #94, Grzesiek pisze już coś w zasadzie innego:
"Po analizie wyników testów i tego co mogłem sobie poczytać o procesorze PA6T, uważam, że z MHz trochę wydajniejszy jest AltiVec w G4, nie jest to wielka przewaga i często będzie równoważona szybkością kontrolera pamięci (np. w teście z artykułu Lockheeda Martina, albo w teście dekodowania video). Z wata wydajniejszy AltiVec jest w PA6T, bo ten procesor ma znacznie mniejszy pobór mocy."
Ja wiem, że on wtedy prawdopodobnie chciał ocenić jedynie altivec w oderwaniu od wszystkich *pozostałych* elementów CPU (co pokazały kolejne) posty - ale nie to napisał, nie w takim kontekście oszacował wydajność PA6T i inaczej zaczął precyzować warunki "eksperymentu"
Jeśli więc nazywasz "bredzeniem" ciągłe przywoływanie "pierwszej" wypowiedzi Grześka, mimo że on by chciał rozmawiać już o czymś innym i w innym kontekście - to tak. Przyznaję. Bredzę.
A żeby coś było w temacie to napisze tak:
- przeciętnego końcowego użytkownika może nie interesować czy LAME jest zoptymalizowane czy nie dla danego procesora a nawet systemu,
- siadając do postawionych obok siebie kompów - jeden X1000 drugi ten MAC Krashana - taki użytkownik odpali najnowszą wersję LAME dostępną dla danego systemu i przekoduje ten sam plik,
- ten komputer który zrobi to w krótszym czasie będzie dla niego szybszym - proste.
Oczywiście że tak. Tak samo przeciętnego użytkownika nie zainteresuje jak bardzo wydajny jest Altivec w danym CPU, jeśli setka innych czynników nie pozwala mu rozwinąć skrzydeł.
Dlatego też, mniej lub bardziej (zazwyczaj bardziej) retorycznie, protestuję przeciw wypowiedzi podsumowującej #64 i podpieraniem się testem niezoptymalizowanego algorytmu.
Owszem, taki algorytm mamy i jest to poważny argument w kontekście X1000 i AmigaOS 4 - nie będę go tam obalał.
Ale nie w przypadku szacowania wydajności CPU - co robi Grzesiek...
Czy teraz już jestem zrozumiały
29.02.2012 13:13
[#105]
Re: Amiga X Party - pierwsze zdjęcia
@Radov, post #102
Podsumuję to krótko:
1. Tracimy czas, bo „pop swoje, a czort swoje”.
2. LAME jest programem o otwartych źródłach. Zrób tak, żeby na X1000 działał szybciej niż na PowerBooku 1,67 GHz. Swoje teoryjki możesz sobie wydrukować i powiesić nad łóżkiem.
EOT, idę się wykonaniem bounty zająć, będzie okazja AltiVeca użyć.
1. Tracimy czas, bo „pop swoje, a czort swoje”.
2. LAME jest programem o otwartych źródłach. Zrób tak, żeby na X1000 działał szybciej niż na PowerBooku 1,67 GHz. Swoje teoryjki możesz sobie wydrukować i powiesić nad łóżkiem.
EOT, idę się wykonaniem bounty zająć, będzie okazja AltiVeca użyć.
29.02.2012 18:55
[#107]
Re: Amiga X Party - pierwsze zdjęcia
@Radov, post #104
Dlatego też, mniej lub bardziej (zazwyczaj bardziej) retorycznie, protestuję przeciw wypowiedzi podsumowującej #64 i podpieraniem się testem niezoptymalizowanego algorytmu.
No ale innego nie ma, to czym ma się podpierać? O ile pamiętam od zawsze w pismach typu Enter czy Chip (kiedyś, dawno temu bo nie wiem jak jest teraz) jak porównywano programy na Apple i PC to instalowano najnowsze dostepne wersje i powtarzano w nich te same operacje. Ten na którym mozna je było wykonać szybciej, był szybszym systemem. Nikt specjalnie nie rozwodził się co jest bardziej zoptymalizowane itp.
Podobnie było pod koniec działalności Amiga Format czy innych pism amigowskich w UK, kieedy ludzi zasypywali redakcje pytaniami co robić, czy przechodzić na PC? Czy na Amidze też da się zrobić to samo co u kolegi na PC|? I czy tak samo szybko? Porównywano wtedy nawet nie te same programy (bo ich praktycznie nie było) na obu platformach, ale mniej więcej zegrary - typu Amiga 040/25 Mhz vs PC 486DX/33Mhz.
Wracając do tego co napisał Krashan. Praktyczny test wykazał że Lame przekoduje ten sam plik na Macu z mniejszym zegarem i starszym prockiem niż na X1000, która ma nowszą architekturę i procesor. W akademickim wywodzie - hehe - Krashan wykazał dlaczego.
Ja tylko mogę powtórzyć, że zwykły użytkownik który by przyszedł na jakieś targi i zobaczył oba te kompy i systemy obok siebie, a zachciał by zrobić test praktyczny z przekodowaniem pliku przez LAME, zdziwił by się, że na sprzęcie nowszym, z szybszym zegarem a do tego dwurdzeniowym (i do tego za TAKĄ KASĘ) trwa to dłużej. Oczywiście można by mu zaraz tłumaczyć: - Panie, drugi rdzeń na razie nie działa ale już pracują nad tym, będzie za jakiś czas. Poza tym Lame jest niezoptymalizowane. Będzie za jakiś czas. Itp. itd.
Nie pisze tego złośliwie, X1000 ogólnie sporo u mnie zyskała po ostatnich materiałach które widzałem na sieci w formie zdjęc, czy filmów, ale to wszystko jeszcze mało. Szczególnie w obecnej cenie. Trzymam kciuki aby pojawił się soft zoptymalizowany pod nią, aby drugi rdzeń zaczął być wykorzystywany, sterowniki 3d i aby nastąpiło to jak najszybciej. Może do końca roku? Pewnie nierealne...
29.02.2012 20:38
[#109]
Re: Amiga X Party - pierwsze zdjęcia
@RadoslawF, post #108
Na tę chwilę Timberwolf na OS4Depot ma 708 ściągnięć. A działających komputerów z AmigaOS 4 jest więcej. Jak tak ma wyglądać użytkowanie AmigaOS 4, to co mówić o wsparciu kolejnych ambitnych projektów. W tym "bawieniu się" w optymalizacje na konkretny komputer (nawet drogi).
Odpowiadając na twoje pytanie - myślę że ponad tysiąc, ale z tego co pamiętam - tylu X1000 nie będzie wyprodukowanych, więc...
Obsługa drugiego rdzenia? Kiedyś. Optymalizacja - nigdy.
Odpowiadając na twoje pytanie - myślę że ponad tysiąc, ale z tego co pamiętam - tylu X1000 nie będzie wyprodukowanych, więc...
Obsługa drugiego rdzenia? Kiedyś. Optymalizacja - nigdy. 29.02.2012 21:06
[#110]
Re: Amiga X Party - pierwsze zdjęcia
@adam_mierzwa, post #109
Zdaję sobie z tego sprawę, ale to jest teraz często argument w dyskusjach - że coś jest niezoptymalizowane (algorytm w LAME na OS4), że będzie poprawione (czas botowania czy firmware) itp.
Na konkretne optymalizacje, podobne do tych z czasów świetności Amigi, domyślam się, że chyba nie ma co liczyć. Tylko do jakich wniosków nas to wtedy prowadzi? Że X1000 będzie działać na "pół gwizdka"? Czas pokaże.
Na konkretne optymalizacje, podobne do tych z czasów świetności Amigi, domyślam się, że chyba nie ma co liczyć. Tylko do jakich wniosków nas to wtedy prowadzi? Że X1000 będzie działać na "pół gwizdka"? Czas pokaże.
29.02.2012 21:17
[#111]
Re: Amiga X Party - pierwsze zdjęcia
@Deftronic/..., post #110
Na razie działa na jedną trzecią, na pół gwizdka to będzie jak zoptymalizują kod pod ten procesor i dodadzą obsługę Xeny a na cały gwizdek jak system będzie w stanie wykorzystać drugie jądro. Na dzień dzisiejszy mamy sprzęt za dwanaście tysięcy który jest wstanie wykorzystać jedną trzecią potencjału sprzętu.
29.02.2012 21:24
[#113]
Re: Amiga X Party - pierwsze zdjęcia
@Deftronic/..., post #107
No ale innego nie ma, to czym ma się podpierać? O ile pamiętam od zawsze w pismach typu Enter czy Chip (kiedyś, dawno temu bo nie wiem jak jest teraz) jak porównywano programy na Apple i PC to instalowano najnowsze dostepne wersje i powtarzano w nich te same operacje. Ten na którym mozna je było wykonać szybciej, był szybszym systemem. Nikt specjalnie nie rozwodził się co jest bardziej zoptymalizowane itp.
Zobacz jaka jest sytuacja na obecnym rynku kart graficznych - i AMD i NVIDIA wspierają wybranych twórców gier i współpracują z nimi nad optymalizacją. Z tego powodu zdarzają się sytuację, że w jednych grach nadspodziewanie dobrze radzą sobie Radeony (np. Crysis 2), a w innych GeForce (np. w Batman: Arkham Asylum - link)
Z tego też powodu w testach gier można zauważyć, że tytuły są pogrupowane: na wspierające jedną stronę, uchodzące za neutralne oraz wspierające drugą stronę.
Taka właśnie sytuacja występuje w tym przypadku: mamy pewne rozwiązanie zoptymalizowane pod jedną ze stron, a pod drugą nie. Wiem i zgadzam się, że:
- źle to świadczy o X1000
- nie jest to marketingowe dla AmigaOS4
- nie wiadomo kiedy to się zmieni
Tylko, że to wszystko dotyczy sfery funkcjonalnej użytkownika, a nie czysto technicznej analizy architektury procesora.
Do czysto technicznej analizy procesora potrzebujesz większej ilości testów - najlepiej by były zoptymalizowane dla obu stron. Bez tego nawet nie ma co wchodzić na tę płaszczyznę analizy. A weszliśmy - bo jest 1 test. (ale ogólnie, tak: będę działał by było ich więcej. Nie wiem kto będzie lepszy, ale zależy mi na uzyskaniu OBIEKTYWNEGO rezultatu)
Ja tylko mogę powtórzyć, że zwykły użytkownik który by przyszedł na jakieś targi i zobaczył oba te kompy i systemy obok siebie, a zachciał by zrobić test praktyczny z przekodowaniem pliku przez LAME, zdziwił by się, że (...)
Zgadzam się. Nie twierdzę inaczej. Ale przynajmniej i ja i Grzesiek zwykłymi użytkownikami nie jesteśmy. Chciałbym wiedzieć:
- jaka jest rzeczywista różnica między układami (niech i G4 wciąż wygrywa - ale to nie to test LAME pokazuje)
- i z jakich różnic architektury to wynika (gdzie akademicki wywód Grześka mi nie wystarcza bo nawiązuje tylko do części specyfikacji układu)
Grzesiek traktuje temat za zakończony - więc ja też. Chociaż nie pozostawię go zupełnie. Mam zamiar wydobyć trochę testów oprogramowania na różnych etapach optymalizacji dla PA6T i pokazać wpływ kolejnych kroków. Zobaczymy co z tego wyjdzie, może się uda i artykuł kogoś zainteresuje....