Thread View: pl.comp.objects
4 messages
4 total messages
Started by Szpieg z Krainy Deszczowców
Tue, 29 Apr 2008 04:44
Do kolegi A.L. na temat: historyczny papier
Author: Szpieg z Krainy Deszczowców
Date: Tue, 29 Apr 2008 04:44
Date: Tue, 29 Apr 2008 04:44
21 lines
1785 bytes
1785 bytes
Drogi kolego A.L.!
Właśnie z około rocznym opóźnieniem przeczytałem Pański artykuł p.t.
Parallel Computer Technology in Natural Gas Pipeline Simulation.
Mam takie pytania:
1) W jakim języku programowania robił Pan te eksperymenty na transputerach? OCCAM
czy Fortran? Bo mnie się wydaje że skoro porównywał Pan 387 i 487 z T400 to
chyba tylko NDP Fortran z Microway był na obie te rodziny procesorów.
2) Czy zachował Pan jeszcze kod żródłowy z tych experymentów?
Chętnie bym się pobawił czymś, o czym można by było publicznie podyskutować.
U wnie w biurze wszytko tajne łamane przez poufne (spalić przed przeczytaniem).
Proszę się odezwać, jeśli znajdzie kolega chwilę czasu.
Z góry dziękuję,
Sylwek
Re: Do kolegi A.L. na temat: historyczny papier
Author: A.L.
Date: Tue, 29 Apr 2008 12:25
Date: Tue, 29 Apr 2008 12:25
60 lines
2912 bytes
2912 bytes
On Mon, 28 Apr 2008 21:44:35 -0700, "Szpieg z Krainy Deszczowców" <__THINK__sylvek@cox.net> wrote: >Drogi kolego A.L.! > >Właśnie z około rocznym opóźnieniem przeczytałem Pański artykuł p.t. >Parallel Computer Technology in Natural Gas Pipeline Simulation. > >Mam takie pytania: > >1) W jakim języku programowania robił Pan te eksperymenty na transputerach? OCCAM > czy Fortran? Bo mnie się wydaje że skoro porównywał Pan 387 i 487 z T400 to > chyba tylko NDP Fortran z Microway był na obie te rodziny procesorów. > W jezyku C dostarczanym przez producenta systemy transputerowego, ktorym byla nieistniejaca od dawna firma CSA. ParallelC to byl normalny C rozszerzony o "occamowe" konstrukcje. Wczesny prototyp tego symulatora byl w jezyku OCCAM, ale generalnie, ze wzgledu na spora ilosc numeryko, zdecydowalem ze C jest poreczniejszy. Ta wersja C opisana jest tutaj http://maven.smith.edu/~thiebaut/transputer/descript.html >2) Czy zachował Pan jeszcze kod żródłowy z tych experymentów? > Neistety, nic mi nie zostalo oprocz paru manuali, ksiazek i plytek z trasputerami... >Chętnie bym się pobawił czymś, o czym można by było publicznie podyskutować. >U wnie w biurze wszytko tajne łamane przez poufne (spalić przed przeczytaniem). > Proponuje: Transterpreter http://maven.smith.edu/~thiebaut/transputer/descript.html Proponuje tez zajrzec na WoTUG (TUG znaczy transputer user's group, bardzo oaktywna mimo ze transputerow juz nei ma wsrod nas) http://www.wotug.org/about.shtml oraz KrOC (KentRetargetable OCCAM Compiler) http://wotug.org/kroc/ czy ogolnie o jezyku OCCAM http://wotug.org/occam/ Mozna sie tez pobawic Javova implementacja CSP http://www.cs.kent.ac.uk/projects/ofa/jcsp/ To ostatnie, miimo ze akademickie, to bynajmniej nei zabawka A.L.
Re: Do kolegi A.L. na temat: historyczny papier
Author: Szpieg z Krainy Deszczowców
Date: Wed, 30 Apr 2008 03:50
Date: Wed, 30 Apr 2008 03:50
73 lines
4547 bytes
4547 bytes
Drogi Panie A.! Przede wszystkim dziękuję za odpowiedź. Szkoda, że nie spędziłem więcej czasu precyzyjniej formułując moje pytania. > W jezyku C dostarczanym przez producenta systemy transputerowego, > ktorym byla nieistniejaca od dawna firma CSA. ParallelC to byl > normalny C rozszerzony o "occamowe" konstrukcje. Wczesny prototyp tego > symulatora byl w jezyku OCCAM, ale generalnie, ze wzgledu na spora > ilosc numeryko, zdecydowalem ze C jest poreczniejszy. Ta wersja C > opisana jest tutaj Mniej więcej tak właśnie myślałem. Occam jest na mój gust trochę za fikuśny gdy w grę wchodzą obliczenia numeryczne. W mojej przed-poprzedniej firmie próbowaliśmy używać T800 w wersji single oraz quad i oprogramowania Microway NDP Fortran & C. Te próby bardzo szybko zostały zarzucone na rzecz systemów SGI, które wówczas opierały się na procesorach MIPS. Pomimo dużo większej początkowej ceny zakupu ostateczna wydajność i łatwość programowania przechyliła szalę na rzecz bardzo drogich maszyn SGI. > Neistety, nic mi nie zostalo oprocz paru manuali, ksiazek i plytek z > trasputerami... Szkoda. Miałem nadzieję, że może została Panu jakaś 5-calowa dyskietka z szeregową wersją oprogramowania, które testował Pan na klasycznym PC-cie. > Proponuje: > Transterpreter > http://maven.smith.edu/~thiebaut/transputer/descript.html No i tu właśnie winny jestem Panu przeprosiny. Mnie nie interesuje nekromancja i odgrzewanie tego starego pomysłu. Ja to już raz w życiu przeszedłem i nie chcę tam wracać. Wszystko to, co originalnie zrobiliśmy na transputerach przeniosło się wspaniale na produkowane przez SGI maszyny SMP połączone przy pomocy CrayLink-ów w topologię ccNUMA. Problem z tym jest tylko taki, że są one bardzo drogie, nawet gry zakupić je używane. Dobrą technologicznie ich namiastką są dziś maszyny oparte o procesory AMD Opteron z linkami HyperTransport. Intel też je niedługo zacznie kopiować, tzn. niektóre nowe Xeon-y będą miały zintegrowany kontroler pamięci zamiast FSB i klon HyperTransport, który tymczasowo ma nazwę QuickPath. Na SGI Onyx2 miałem rutynowo wyniki w zakresie 7(z małym hakiem) na 8 procesorowej maszynie. Na dual-socket quad-core Opteronach mam obecnie wyniki sporo gorsze, ale też mało spędziłem nad tym czasu. Moje podejście do zadadnienia jest 100% komplementarne do Pańskiego. Pan zaczyna od góry i rozdziela algorytmy na kawałki, które daje się zrównoleglić. Ja pracuję od dołu: algorytmy dostaję od razu pokawałkowane, problem jest taki jak je efektywnie zaimplementować, unikając "false sharing", "cache and TLB trashing" i "remote memory accesses". To, nad czym pracuję w biurze, jest niestety 100% "company confidential" i ok. 50% "not for export from USA". A chciałbym z kimś nowym porównać wyniki. > Natomiast multi-core procesory chyba jak najbardziej sie nadadza, i > wlasnei zameirzam eksperyment powtorzyc na dual-core procesorze. Moze > ktos chce wziac udzial w eksperymencie? Narobiłem sobie nadzieji.... :-( Gdyby jednak Pan gdziś znalazł w starych archiwach jakąś dyskietkę z programami, które Pan testował do tego artykułu to proszę się odezwać jeszcze raz na tą grupę. Może nie odpowiem od razu, ale na pewno nie przepuszczę takiej okazji. Jeszcze raz dziękuję, Sylwek
Re: Do kolegi A.L. na temat: historyczny papier
Author: A.L.
Date: Wed, 30 Apr 2008 12:35
Date: Wed, 30 Apr 2008 12:35
82 lines
4661 bytes
4661 bytes
On Tue, 29 Apr 2008 20:50:08 -0700, "Szpieg z Krainy Deszczowców" <__THINK__sylvek@cox.net> wrote: >> Neistety, nic mi nie zostalo oprocz paru manuali, ksiazek i plytek z >> trasputerami... > >Szkoda. Miałem nadzieję, że może została Panu jakaś 5-calowa dyskietka >z szeregową wersją oprogramowania, które testował Pan na klasycznym PC-cie. > Niestety, nic sie nei ostalo... >No i tu właśnie winny jestem Panu przeprosiny. Mnie nie interesuje nekromancja >i odgrzewanie tego starego pomysłu. Ja to już raz w życiu przeszedłem i >nie chcę tam wracać. Wszystko to, co originalnie zrobiliśmy na transputerach >przeniosło się wspaniale na produkowane przez SGI maszyny SMP połączone >przy pomocy CrayLink-ów w topologię ccNUMA. Problem z tym jest tylko taki, >że są one bardzo drogie, nawet gry zakupić je używane. > Owszem. Za drogie. >Dobrą technologicznie ich namiastką są dziś maszyny oparte o procesory AMD >Opteron z linkami HyperTransport. Intel też je niedługo zacznie kopiować, tzn. >niektóre nowe Xeon-y będą miały zintegrowany kontroler pamięci zamiast FSB >i klon HyperTransport, który tymczasowo ma nazwę QuickPath. > >Na SGI Onyx2 miałem rutynowo wyniki w zakresie 7(z małym hakiem) >na 8 procesorowej maszynie. > To jescze zalezy jaki jest communication overhead. Dawno temu (rok 2001) zrobilem wersje systemu do optymalizacji pewnych procesow na normalnych pecetach polacznocyh normalna siecia (to byly czasy gdy najszybszy komputer mial 200MHz). Skalowalo sie to-to dobrze do okolo 10 procesorow, a potem speedup spadal. Prawdopodobnie powtorzymy to wamo w oparciu o aktyalna technologie, problem tylko ze spzretem - klient nei chce placic 6 cyfrowych sum za komputery. >Na dual-socket quad-core Opteronach mam obecnie wyniki sporo gorsze, ale też mało >spędziłem nad tym czasu. > Poki co, nie udalo mi sie wycisnac duzo z Quad Core, ale podobnie jak Pan spedzilem nad tym malo czasu >Moje podejście do zadadnienia jest 100% komplementarne do Pańskiego. Pan >zaczyna od góry i rozdziela algorytmy na kawałki, które daje się zrównoleglić. >Ja pracuję od dołu: algorytmy dostaję od razu pokawałkowane, problem jest >taki jak je efektywnie zaimplementować, unikając "false sharing", "cache >and TLB trashing" i "remote memory accesses". > He... Moja sytuacja jest wygodniejsza :) >To, nad czym pracuję w biurze, jest niestety 100% "company confidential" >i ok. 50% "not for export from USA". A chciałbym z kimś nowym porównać >wyniki. > Z wyjatkiem tego ze to co robie jest na eksport, moja sytuacja jest taka sama: company confidential :) >> Natomiast multi-core procesory chyba jak najbardziej sie nadadza, i >> wlasnei zameirzam eksperyment powtorzyc na dual-core procesorze. Moze >> ktos chce wziac udzial w eksperymencie? > Jak pisalem wyzej, mam malo czasu na te eksperymenty. Prawdopodobnie "sytuacje modelowa" zapuszcze jako prace na lokalnej uczelni... >Narobiłem sobie nadzieji.... :-( > >Gdyby jednak Pan gdziś znalazł w starych archiwach jakąś dyskietkę >z programami, które Pan testował do tego artykułu to proszę się odezwać >jeszcze raz na tą grupę. Może nie odpowiem od razu, ale na pewno >nie przepuszczę takiej okazji. Niestety, w 100 procentach wiem ze to wywalilem... Przed ktoras z przeprowadzek postanowilem "odchudzic" swoj dobytek... A.L.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads