Il 18/02/2011 22:08, Giorgio Pastore ha scritto:
> On 2/18/11 9:34 PM, Pleg wrote:
> ....
>> Io invece in genere sconsiglio vivamente lo scrivere routine numeriche
>> a mano. Per qualsiasi routine ti serve, e' *quasi certo* che esistano
>> librerie numeriche scritte da professionisti, testate, stabili e
>> veloci che fanno quello che ti serve.
>
> Concordo.
> Anche perch�, nel caso della soluzione dei sistemi lineari, oltre agli
> algoritmi (tipo Gauss) intervengono in modo essenziale considerazioni
> legate alla minimizzazione degli effetti del roundoff.
>
>> Tra l'altro non sono mai stato un appassionato delle NR:
> ...
>> per fare una routine veloce non basta un algoritmo
>> veloce, serve anche una intima conoscenza dell'architettura della
>> macchina su cui vuoi far girare il programma (CPU o GPU? multitheaded?
>> cache coherent? quanti livelli di cache, con che dimensione, con che
>> associativita', con che dimensione della cache line? superscalare?
>> quate unita' floating point? ha unita' SIMD? quanto e' aggressivo il
>> prefetcher hardware? eccetera...).
>
> Qui mi sembra per� che dai per scontato che occorrano performance di
> picco. Per un' enorme quantit� di probemi reali ed interessanti non �
> cos� e anche la libreria meno ottimizzata e il programmatore meno
> conscio dell' HW su cui girano i programmi potr� avere ottimi risultati
> in tempi ragionevoli.
>
> ... BLAS e LAPACK sono gratis e inclusa nelle maggiori
>> distribuzioni linux, ma immagino non siano ottimizzata bene come le
>> prime due.
> Vedi sopra. Finch� non si sbatte il naso con problemi reali di
> performace anche l' implementazione generica va benissimo.
>
> Se invece vuoi lanciarti nella programmazione GPGPU,
>> CUBLAS e' BLAS per CUDA, non so se ci siano gia' delle librerie tipo
>> LAPACK open-source. Per OpenCL non so niente, ma immagino ci sia
>> qualcosa anche li'.
>
> Ma se uno ti chiede qualcosa contro le zanzare gli suggerisci una bomba
> all' idrogeno ? :-)
>
> Io sarei molto cauto a suggerire la programmazione delle GPGPU anche a
> colleghi "affamati" di calcolo intensivo, figurarsi a Soviet che non
> credo abbia necessit� cos� estreme (mi cosparger� la testa di cenere se
> sbaglio).
no infatti, devo solo bilanciare reazioni in modo
automatico, e pensavo di trascriverle in sistemi lineari,
pi� di un 10-15 incognite (ma proprio volendo avere largo
margine) non dovr� manipolare.
Ed � un calcolo una tantum, manco iterativo o altro
>
> Per Soviet:
> Per fare i conti Lapack va benissimo.
Spero di trovare i sorgenti
> Mi lascia invece un po'
> perplessol'affermazione che il linguaggio non conti. Dipende da cosa
> vuoi fare.
Si, certo, non mi sono spiegato bene.
Sono indeciso se fare il porting dal C al VB, ma anche fosse
fortran almeno leggerlo me lo ricordo quel tanto che basta.
Ora non credo che le NR siano in linguaggi strani,
funzionali o cosa.
D'altra parte se fosse molto lungo, non escludo di fare una
DLL a parte e mantenere il linguaggio nativo e compilare e
stop. Intendevo questo col fatto che non conta : che non mi
interessava particolarmente.
> Per calcoli non ci sono problemi. Ma se invece vuoi guardare
> come sono fatte, non so se suggerirtele.
Devo si guardare come � scritto il codice, a meno che non
diano una versione compilata e una ottima documentazione
della API, in questo caso in effetti potrei usarle a scatola
chiusa.
>
> Comunque il sito delle num. rec. �
> http://www.nr.com/oldverswitcher.html
> "tonnellate" di sw numerico (in sorgente) le trovi su
> http://www.netlib.org/
ci andr� a guardare ! GRazie
Soviet
> Giorgio
Received on Sat Feb 19 2011 - 00:06:06 CET