🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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
#17362
Author: Szpieg z Krainy Deszczowców
Date: Tue, 29 Apr 2008 04:44
21 lines
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
#17363
Author: A.L.
Date: Tue, 29 Apr 2008 12:25
60 lines
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
#17364
Author: Szpieg z Krainy Deszczowców
Date: Wed, 30 Apr 2008 03:50
73 lines
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
#17365
Author: A.L.
Date: Wed, 30 Apr 2008 12:35
82 lines
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