Newsgroup: it.scienza.fisica
Titolo: C# e Java usati dai fisici?

Salve,
ho notato che esistono diverse librerie e codici scientifici per
Fortran (anche FORTRAN 77) e C/C++. 
Mi chiedevo che successo (o insuccesso) avessero linguaggi piu'
"moderni" come Java o C# nell'ambito fisico.
Che ne dite?
Programmare in C# o Java, grazie alla presenza di garbage collector e
gestione "automatica" della memoria, renderebbe le cose piu' semplici.
Pero' credo anche che in fisica sia richiesta notevole capacita' e
potenza di calcolo, cosi' mi chiedevo se C# e Java fossero adatti al
calcolo scientifico, e in che misura fossero usati dalla comunita' dei
fisici.
Grazie in anticipo

 fisici.
Quando è richiesta molta potenza di calcolo, preferisco il C standard
con strumenti GNU. Trovo interessante Java per le realizzare delle
interfacce grafiche, ma non l'ho mai usato nell'ambito del mio lavoro
(ma solo per alcune applet giocattolo).

 fisici.
in fisica certo ma si usano spesso cluster di pc non è tanto il 
compilatore in sè o il computer singolo super potente che fa la differenza.

 fisici.
Devo dire che di utilizzo di C#  non ho notizie significative al di 
fuori di alcuni tentativi in ambito didattico.  Una buona ragione può 
essere il fatto che si tratta di un linguaggio legato ad una determinata 
piattaforma.
Per Java la storia è  diversa. In certi ambiti viene usato 
correntemente. Per esempio,  mi risulta che a Elettra,  il sincrotrone 
che sta vicino Trieste, il software di controllo del fascio di elettroni 
sia realizzato  in Java.
Naturalmente non si usa Java dove è  necessario avere un controllo fine 
della parte numerica e/o  dove e'  richiesta una grande efficienza 
(forse le cose potrebbero cambiare con l'  evoluzione di compilatori 
specifici per una data architettura ma al momento non mi risulta che si 
possa ancora parlare di codici Java competititivi con C,C++ e Fortran.
Se però  la performance non è  l'  obiettivo primario si utilizza Java 
come anche altri linguaggi.
Aggiungerei due osservazioni sulla base della mia esperienza:
1. le comunità di programmatori scientifici (fisici ma non solo)  sono 
abbastanza conservatrici (codici sviluppati ancora  in Fortran 77, 
programmi C  che ignorano caratteristiche utilissime dello standard 99, 
  programmi C++ che cercano di travestire  da programmazione ad oggetti 
  un  approccio procedurale...).  Questo non credo che sia 
giustificabile solo sulla base dell'  esistenza pregressa di librerie di 
programmi. Temo  piuttosto che ci sia un ritardo culturale dovuto ad una 
scarsa attenzione nei  curricoli a problematiche relative al software e 
all'  ingegneria software.
2. non menzionerei come esempio della modernità  di Java o C#  il solo 
meccanismo della garbage collection automatica.  Ce l'hanno  anche 
linguaggi piu'  vecchi di Java o C#. E  di nuovo, il peso di questo 
aspetto dipende dall' ambito applicativo.
Giorgio

 wrote:

Tu rimani sul vago : "l'ambito fisico"...... cosa e'?
A voler essere piu' precisi bisognerebbe citare almeno il tipo di dati
da elaborare e le metodologie di processamento (dico: algoritmi
distribuiti, algoritmi paralleli, single/multi threaded?... non e' una
cosa banale).
Per cercare di risponderti al meglio, io penso questo:
Java e C# sono cattivi dal punto di vista non-funzionale (cioe'
performances e spreco di risorse) rispetto ai buoni Fortran77/90 e
ancor meglio C/C++ ed ottimo Assembler!
Ovviamente il problema non e' questo!
Volendo assumere (ad ipotesi) che tra una semplice routine ottimizzata
direttamente in Assembler ed una in Java vi corra una differenza
abissale in termini di potenza di calcolo (direi 1/100.... cosi' su 2
piedi) bisogna anche chiedersi un'altra cosa importante:
Ma quanto ti costa programmare in Assembler (tra errori e quant'altro,
e debug etc etc) rispetto a Java?
Ne vale la pena?
Orbene, ancor oggi per real-time processing dei dati satellitari (per
intenderci i dati grezzi che invia il satellite alla gound-station ad
ogni passaggio sull'antenna, che debbono essere tradotti nel minor
tempo possibile ai sistemi back di storage, pena la loro perdita
parziale, oppure sistemi militari balistici per la missilistica...
[PURTROPPO...li farei col pallottoliere, ma e' un'altra questione]) si
usano processi iper ottimizzati: nemmeno C compilato -O4, ma
direttamente assembler {oppure mixed technology: pezzi assembler
accanto a compilati C).
Accanto a questa considerazione ve ne e' un'altra: e' utile oggi usare
ancora algoritmi stand-alone? Cioe' elaborazioni su singole macchine?
Si va verso una struttura distribuita (le GRIDs) che permettono di
aumentare lo sfruttamento di risorse esistenti ed altrimenti perdute
nell'inutile attesa di qualche estemporaneo task: sentito gia' il
SETI@home?
Un lavoro che viene fatto non da una sola macchina mentre le altre
100000 della rete sono a non far nulla; bensi' un lavoro che e'
distribuito nella speranza che le 100000 macchine della rete possano
lavorarlo in sinergia!
A questo punto torna utile l'utilizzo di linguaggi moderni (come java)
che rende molto piu' maneggevole la costruzione di sistemi cosi'
concepiti.

 fisici.
La mia esperienza è molto limitata perchè sono un giovane dottorando,
oltretutto ingegnere, ma ho la fortuna di lavorare in un gruppo 
interdisciplinare con molti fisici. 
Al di là delle librerie "number crunching", che conviene comunque
sviluppare in C o Fortran proprio per tenere alte le performance, la parte
logica può essere sviluppata in C++ per permettere una maggiore
elasticità e snellezza del codice. 
Questo è un indirizzo che credo prenderà sempre più piede grazie alla
logica di simulazione multiscala, che necessità intrinsecamente di una
buona modularità interna e di una gestione efficiente e elastica di tale
modularità.
Quindi direi che l'attenzione alla programmazione orientata agli oggetti
c'è anche in ambito fisico ormai.
Java sinceramente non so, anche perchè la portabilità del codice è una
necessità entro certi limiti...mi sembra più adatto a sviluppare applet
contenute e per scopi non di calcolo, ad esempio dei visualizzatori.

 gestione "automatica" della memoria, renderebbe le cose piu' semplici.
Ciao, non sono un fisico bensì un programmatore di computer e un 
progettista (nel campo dell'oleodinamica), sono un perito industriale, 
quindi non so cosa fanno i fisici (purtroppo), al massimo so dirti come 
fanno gli ingegneri con i quali lavoro, dato che risolviamo problemi (in 
questa fase sono più che altro loro, anche se io da curioso mi impiccio 
sempre, male che mi vada imparo sempre qualcosa) e poi scriviamo del 
codice per fare i calcoli (e quì intervengo io).
Posso comunque parlarti per l'esperienza che mi sono fatto in oltre 
dieci anni di lavoro.
Spesso mi trovo a scrivere codice per applicazioni "scientifiche" ad uso 
interno nella ditta per la quale lavoro.
Non conosco il C# ma ho avuto qualche esperienza con Java (che ho poi 
abbandonato).
Java è drammaticamente lento per il calcolo numerico perchè gira 
all'interno di una macchina virtuale. Cioè la CPU non lavora 
direttamente sul tuo programma ma elabora un meta-codice.
E' meglio di un linguaggio interpretato come ad esempio il BASIC ma 
comunque non è soddisfacente per questo tipo di applicazioni (è molto 
buono invece per le applicazioni client/server nelle intranet).
Un programma in C/C++ piuttosto che in Fortran viene invece compilato in 
linguaggio macchina e può quindi "macinare numeri" alla piena potenza 
del processore (o dei processori) installati.
Secondo me un'ottima alternativa è appunto il C++ con la libreria STL, 
in questo caso non c'è bisogno di diventar matti con la memoria in 
quanto viene gestita automaticamente dai vari container standard della 
Standard Template Library.
Ci sono poi algoritmi molto potenti (sempre nella Standard Template 
Library) pronti all'uso che facilitano notevolmente la scrittura di 
codice robusto e veloce.
La velocità praticamente non cambia, un buon codice C++ non è più lento 
di un buon codice in C. I compilatori odierni poi non hanno nulla da 
invidiare ad un programma in Assembly, il risultato della compilazione è 
praticamente linguaggio macchina sta-ottimizzato e non pseudo-codice 
come nei compilatori di 10 e più anni fa.
Per la mia esperienza (che non è quella di un fisico, ma per certi 
aspetti è quella degli ingegneri con i quali lavoro), con l'uso di 
Octave (o Matlab) in molti casi (che è un linguaggio di altissimo 
livello) o quando ce n'è bisogno la scrittura di codice in C++ (livello 
decisamente più basso) è un aiuto validissimo per il calcoli.
Con Java (e forse anche con C#) pur essendo linguaggi molto potenti, 
semplicemente aspetti di più.
ciao.

 (ma solo per alcune applet giocattolo).
non capisco cosa c'entri la potenza di calcolo con il C standard. Se 
vuoi sfruttare la potenza di calcolo peraltro dovresti affidarti a 
compilatori ottimizzati per piattaforma. Prova 
http://www.absoft.com/
 e 
dimmi la differenza.

 piattaforma.
in realtà c'è un progetto 
http://www.mono-project.com/
 che permette di 
lavorare in multipiattaforma.

 semplicemente aspetti di più.
faccio presente che Matlab nasce da una costola di Fortran. Infatti 
all'inizio era semplicemente una libreria numerica del Fortran. Notare 
la sintassi matriciale molto simile. Senza contare che Matlab permette 
di interagire con compilatori esterni aumentando le prestazioni.

 concepiti.
ecco questo è sensato. Se uno vuole "potenza pura" si affida ad un 
cluster e di solito si può costruire con poca spesa. Di solito ogni 
dipartimento ha qualche clusterino. Ormai nessuno lavora su singola 
macchina...non ha senso per simulazioni numeriche ad esempio.

 contenute e per scopi non di calcolo, ad esempio dei visualizzatori.
la portabilità è importante se si lavora con interfacce grafiche ad 
esempio. Io scrivevo codice in fortran 90 su una macchina Unix, poi lo 
rimettevo a posto a casa su una macchina windows e a volte se il 
laboratorio era pieno lo ricompilavo in linux senza problemi.

 macchina...non ha senso per simulazioni numeriche ad esempio.
E' vero: anche il mio portatilino nel suo piccolo senza essere un
cluster è comunque un dual core. E' probabile che in futuro bisognerà
puntare sempre di più sulle architetture distribuite, ormai anche in
ambito praticamente domestico.

 lavorare in multipiattaforma.
Interessante, e la presenza di Novell da'  una certa garanzia di 
supporto. Pero' non credo che ci potrebbero essere  grandi spostamenti 
di equilibri solo su  questo. Nessun gruppo importante investirebbe in 
C# solo su questa base. Se il progetto fallisse,  non sarebbe la prima 
volta nella storia dei linguaggi di programmazione.  Ma per chi resta 
col cerino in mano son dolori...
Giorgio

 come ogni altro compilatore.
GASP! Ti pare davvero la stessa cosa? E` come paragonare un programma
che converte testi da un formato a un altro con uno che li traduce da
una lingua a un'altra. L'assembly non e` che una rappresentazione
confortevole del linguaggio macchina per editarlo piu' facilmente.
Salvo casi eccezionali, nessuno sano di mente scriverebbe direttamente
in linguaggio macchina.
Ciao
Paolo Russo

 macchina...non ha senso per simulazioni numeriche ad esempio.
Ci sono simulazioni e simulazioni e cluster e cluster. Dipende in modo 
cruciale dagli algoritmi, dalle implementazioni e dalle architetture se 
la soluzione cluster e'  la piu'  vantaggiosa.
Se  c'e' una cosa che ho imparato in piu' di 30 anni di lavoro con i 
computer in fisica e'  che l'  informatica e'  il mondo in cui tutto 
"dipende".
Giorgio

 ogni altro compilatore.
Ma è il linguaggio che è diverso e ti permette di fare cose che un 
linguaggio di più alto livello non ti lascerebbe fare. Il codice 
macchina risultante è più veloce anche perchè _il programma_ è 
ottimizzato (ovviamente se il programmatore sa quello che fa), non solo 
la sua 'traduzione'.
saluti,
Peltio
-- 
File "firmaadattaallamoderazione.txt" not found.

in linguaggio macchina.
Non sono d'accordo, i compliatori ottimizzano ma per raggiungere la massima
efficenza devi usare l'assembler.
Io uso spesso routines in linguaggio macchina i microcontrollers per ottenere il
massimo delle prestazioni ad esempio in interrupts veloci dove magari usando il
C dovrei usare risorse esterne.
E la cosa č usata anche in campo scientifico ad esempio in calcoli ricorsivi. 
Ricordo di aver letto che il famoso bug della FDIV sul primo Pentium fu scoperto
da un ricercatore mentre l'usava in assembler per calcoli astronomici
Programmare in assembler č piů difficile, questo sě.
--
ciao
  Stefano

 in linguaggio macchina.
non so se hai letto bene la risposta di jan ma a me pareva ironica come 
per dire che se proprio uno vuol spingersi all'estremo perché non usare 
il linguaggio macchina?

 Programmare in assembler č piů difficile, questo sě.
no difficile non penso secondo me č piů "macchinoso" per fare certe cose.

 
Non saprei darti tutti i torti: in effetti la programmazione OO è solo uno
dei tanti paradigmi esistenti, e non è necessariamente "il migliore" solo
perchè è uno dei più recenti, anzi.
I veri vantaggi della programmazione OO, secondo me ma anche secondo altri,
diventano evidenti quando più persone devono mettere mano al codice (team
work), quando il codice va incontro ad un riutilizzo frequente (ad es., per
un processo di sviluppo continuo delle applicazioni), e più in generale,
ogniqualvolta si progetta qualcosa "in the large" (molto codice, molto
complesso, molti attori coinvolti).
Naturalmente questo è vero per la "buona" programmazione ad oggetti, se
scritto male il codice ad oggetti è equivalente a quello funzionale puro,
solo con costrutti più complicati e astrusi, e tende perciò ad essere
addirittura peggiore.
Probabilmente la comunità dei fisici non apprezza questo tipo di linguaggi
perchè, come tutte le cose progettate "dagli informatici per gli
informatici", risultano di primo impatto astruse e pieni di complicazioni
apparentemente inutili: inoltre, rendono il codice quasi "stucchevole" dal
punto di vista stilistico. In realtà, si tratterebbe solo di studiare
espressamente questo paradigma di programmazione, solo che i fisici non
hanno il tempo di diventare programmatori, come dici tu, e d'altra parte io
non mi sognerei mai di disquisire, dal "basso" del mio livello, con chi
faccia ricerca fisica "sul serio".
-- 
Mixmar.
Solo nel silenzio la parola
solo nella tenebra la luce,
solo nella morte è vita;
fulgido è il volo del falco
nel cielo deserto.
La creazione di 'Ea.

no difficile non penso secondo me è più "macchinoso" per fare certe cose.
Diciamo che quando programmi in assembler devi tenere conto di cose che quando
programmi con un linguaggio evoluto puoi trascurare, come l'allocazione delle
variabili, l'uso dei registri e della ram, ecc.
Di contro c'è da dire che se le variabili sono molte, in assembler diventa molto
più difficile gestirle, ad esempio non userei mai l'assembler per accedere ad
una FAT16, ma per generare sincronismi o acquisire dati velocemente va
benissimo.
--
ciao
  Stefano

   Stefano


 all'estremo perché non usare il linguaggio macchina?
Forse hai ragione, ma il fatto e` che non sarei d'accordo
neanche se avesse voluto essere ironico... ci sono
situazioni in cui e` del tutto sensato usare l'assembler.
Ciao
Paolo Russo

 benissimo.
sì su questo sono d'accordo. Penso che anche lavorare su database 
moderni diventi alquanto complesso o quasi impossibile.

 faccia ricerca fisica "sul serio".
penso che la programmazione ad oggetti se applicata secondo i canoni 
tradizionali senza esagerare con forme di puro estetismo informatico sia 
  potentissima. Io l'ho sempre trovata elegante. Non penso che i fisici 
non l'apprezzino è solo che per quanto ho visto io di solito in fisica 
si rimaneggiano codici scritti anche decine di anni fa. Inoltre spesso 
il fisico punta alla soluzione immediata e magari si mette a buttare giù 
codice come gli viene perché ha avuto un improvviso "lampo" di genio. 
Questo di certo non aiuta nella stesura del codice e ci si ritrova 
magari con un codice funzionante ma molto difficile da leggere per gli 
altri perché scritto pezzo per pezzo come capita. Il fisico ha bisogno 
di routines per risolvere problemi pratici...qualcosa di immediato non 
bada all'analisi in senso stretto. L'informatico invece lavora su 
progetti estesi, database, gestionali,...Deve creare anche degli 
applicativi user-friendly e riutilizzabili al massimo. Ad un fisico 
invece di un interfaccia grafica non gliene frega nulla e gli basta che 
il programma gli "scriva" i dati in un file qualsiasi. Ho incontrato 
anche molti ricercatori che scrivevano volutamente del codice 
incomprensibile (fuorché per loro) anche per una sorta di paura...per 
evitare che qualcuno si impossessasse del loro "tesoro".

 raggiungere la massima efficenza devi usare l'assembler.
Lo so, lo uso anch'io piuttosto spesso, c'e` un equivoco. Mi
riferivo alla differenza tra sorgente assembler ("linguaggio
assembly") e opcode numerici ("linguaggio macchina"). Il
rapporto tra le due cose e` cosi' stretto che in pratica i
termini sono intercambiabili (infatti dici che programmi in
linguaggio macchina, quasi certamente intendendo assembler),
tuttavia la persona a cui ho risposto sembrava sostenere ben
altro.
Ciao
Paolo Russo

laboratorio era pieno lo ricompilavo in linux senza problemi.
....Con Fortran si possono realizzare interfacce grafiche?
MrAsm

   Stefano

> ....Con Fortran si possono realizzare interfacce grafiche?
sì.