Questa pagina è dedicata alla sfida realBasic vs Java in termini di efficienza, ovvero a parità di algoritmo chi completa prima il compito. A volte non è proprio a parità di algoritmo ma saranno comprese anche le librerie disponibili
Aggiornamento1: ho deciso che questa sarà la pagina di bench tra tutti i linguaggi (quindi potenzialmente diventerà lunghissima).
Numeri primi e memoria dinamica
Java vs Realbasic
Il primo bench riguarda la ricerca (stupida) dei primi 5000 numeri primi (posto che 2 e 3 si conoscono) memorizzandoli (e riutilizzandoli) in un array dinamico (che varia di dimensione).
Il codice è il seguente
I risultati sono (presi con process explorer "tempo cpu"):
linguaggio | secondi |
realBasic 2009r2 | 2.281 |
java 6u7 | 1.250 |
Macchina: uguale per entrambi - Win xp sp2 pro optimized, 1giga di ram ddr2, atom n270. (i netbook sono i veri portatili per lavorare)
Anche se java, visto che deve avviare la JVM utilizza molta più memoria.
Sinceramete mi aspettavo che java fosse più lento, sia per il fatto che essendo interpretato con le operazioni matematiche intense non andasse proprio d'accordo, sia perchè l'utilizzo dell'arrayList pensavo fosse più pesante rispetto agli array di realbasic (che sono sin da subito sia array che arrayList) ed infine perchè in java dovevo pure castizzare l'oggetto preso dall'arrayList ad intero.
Invece realbasic le ha prese di brutto. Bravo java, seppur realbasic è un ottimo linguaggio.
Scilab
Ho fatto lo stesso test con Scilab, software per l'analisi numerica. Ovviamente essendo un software ad hoc, che comunque interpreta gli script, pensavo che non fosse velocissimo come i linguaggi di programmazione di alto livello "diretti" (java, realbasic & co), ma comunque abbastanza veloce. Invece sono rimasto molto deluso, tuttavia , anche se non performante, il programma ha moltissime funzioni che nei linguaggi di programmazione bisogna programmarsi da soli, quindi è comunque valido.
I risultati sono (presi con process explorer "tempo cpu"):
linguaggio | secondi |
realBasic 2009r2 | 2.281 |
java 6u7 | 1.250 |
Scilab 5.1.1 | >10 min |
VBA 2007
Ho ripetuto il test (cercando di non usare le peculiarità del linguaggio, quindi mantendendo stabile l'algoritmo) con Visual Basic per excel 2007. Da notare che comunque l'array è statico e non dinamico.
Il codice (VBA 2007) è il seguente:
Sub benchCalcolaNumeriPrimi()
Const quantiNumeri As Long = 5000
MsgBox ("parto")
Dim primi(1 To quantiNumeri) As Long 'che pillole o faccio redim o devo usare le costanti
primi(1) = 2
primi(2) = 3
Dim currentNumber As Long
currentNumber = 4
'devo farlo piu' simile possibile al lingugagio delle calcolatrici/scilab/altro altrimenti
'ci son sempre le funzioni ottimizzate
Dim i As Long
i = 1
Dim t As Long
t = 1
Do While (primi(quantiNumeri) = 0)
i = 1
t = 1
Do While (primi(i) > 0 And t = 1)
If (currentNumber Mod primi(i) = 0) Then
t = 0
End If
i = i + 1
Loop
If (t = 1) Then
primi(i) = currentNumber
End If
currentNumber = currentNumber + 1
Loop
MsgBox ("finito")
Dim nuovoFoglio As Worksheet
Set nuovoFoglio = Worksheets.Add()
'stampa i risultati
Dim ind As Long
For ind = 1 To quantiNumeri
nuovoFoglio.Cells(ind, 1).Value = primi(ind)
Next
End Sub
Io pensavo che, comunque, scilab fosse veloce rispetto ad altri linguaggi interpretati (come può esserlo visual basic for applications).
Stiquarzi!!!
In tempi di CPU netti sempre sull'atom n270 (con un core logico usato, quindi anche più lento) impiega 6,5 secondi. Considerando il tempo lordo… 8 secondi!
8 secondi contro 10 minuti!!!!!
Se scilab non migliora, almeno per i calcoli base, lo userò sempre meno :(
I risultati sono (presi con process explorer "tempo cpu"):
linguaggio | secondi |
realBasic 2009r2 | 2.281 |
java 6u7 | 1.250 |
Scilab 5.1.1 | >10 min |
Visual basic 6.3 excel 2007 | 6.500 |
C
Ho provato c (con codeblocks ed exe generato con gcc). Non ho provato la versione ottimizzata per il seguente motivo: una versione ottimizzata di codice C non solo funziona solo su una certa famiglia di sistemi operativi e solo su una certa architettura di cpu, ma anche solo su particolari processori di questa architettura. Come se, facendo codice per core 2 duo, non potessi più eseguirlo su pentium 3.
Ora, almeno la portabilità inter sistema operativo (ovvero: posso installare windows xp su pentium 3 e su core 2 duo? Allora l'exe deve girare ovunque), tralasciando la possibilità di produrre diversi eseguibili o aggiungere codice appositamente, deve esserci. Altrimenti anche l'interprete java (o python o altro), che è scritto in C++ (lol) ottimizzato per quella macchina ridurrebbe i tempi in maniera sensibile. Cosa che invece è fattibile solo con i linguaggi compilati, perchè il compilatore non sarà ottimizzato, ma l'eseguibile prodotto si. In questi termini C è il linguaggio con compilatori più ottimizzanti esistente (ma ovviamente compilato, il che vuol dire risparmiarsi il tempo della prima interpretazione del programma1 , che comunque costa). Comunque la portabilità almeno inter sistema operativo ed architettura della cpu (es dove gira win xp a 32 bit gira anche il programma) è necessaria, tranne alcuni casi (calcolo scientifico su macchine fisse o app in real time con requisiti minimi ben specificati).
Anzi, ho controllato, probabilmente è la versione già ottimizzata, perchè ho settato le flags di ottimizzazione ma non è cambiata la velocità di esecuzione.
I risultati sono (presi con process explorer "tempo cpu"):
linguaggio | secondi |
realBasic 2009r2 | 2.281 |
java 6u7 | 1.250 |
Scilab 5.1.1 | >10 min |
Visual basic 6.3 excel 2007 | 6,500 |
gnu gcc 4.4.1 | 0.730 |
Devo dire che stavolta sono stato molto preciso a prendere i tempi con process explorer, come pure con realbasic, devo riprovare con java e vedere se ottengo comunque 1.250
Ah, ovviamente quando si tratta di un progetto complesso C (non conosco C++) è un campo minato, bisogna essere molto bravi e concentrati ad usare tutto per bene con gli adeguati controlli (perchè di controlli automatici non ne esistono), inoltre fare cose semplici spesso diventa complicato (però una cosa sicuramente semplificata rispetto a linguaggi di più alto livello è il controllo dei devices). Quindi bisogna scendere a compromessi: faccio qualcosa in un linguaggio molto efficiente e ci metto molto o perdo di efficienza e ci metto di meno?
Bisogna dire due cose: 1) spesso il guadagno di prestazione sfruttando meglio le potenzialità hw di un sistema è minore al guadagno di prestazione che si avrebbe migliorando l'algoritmo. Ciò vuol dire che il tempo risparmiato a programmare con attenzione in C (e forse C++?) potrebbe essere investito per migliorare l'algoritmo in sè e guadagnare ancor di più in performance. 2) Molti linguaggi ad alto livello sanno che esistono linguaggi ad medio-alto livello più ottimizzati, il re dei quali è C, quindi permettono di interfacciarsi con questi (tanto alla fine i compilatori/interpreti son tutti C). Quindi si possono scrivere le parti molto utilizzate del codice in C, e fare il resto nel linguaggio ad un livello più alto meno vicino al linguaggio macchina.
Jscript (Javascript su windows script host)
Il tempo non l'ho preso da process explorer (e c'è il problema che se il processo non usa tutta la cpu si perdono secondi) quindi è un pò gonfiato, dunque:
linguaggio | secondi |
realBasic 2009r2 | 2.281 |
java 6u7 | 1.250 |
Scilab 5.1.1 | >10 min |
Visual basic 6.3 excel 2007 | 6,500 |
gnu gcc 4.4.1 | 0.730 |
Jscript su WSH 5.6 | 41.484 |
(devo riprendere i tempi di tutti con process explorer in modo ponderato, ovvero valutando solo l'esecuzione e non l'avvio).
Javascript su node.js (0.8.20)
Senza proc exp ma da programma (che usa solo una cpu): 594 millisecondi.
linguaggio | secondi da process explorer |
realBasic 2009r2 | 2.281 |
java 6u7 | 1.250 |
Scilab 5.1.1 | >10 min |
Visual basic 6.3 excel 2007 | 6.500 |
gnu gcc 4.4.1 | 0.730 |
Jscript su WSH 5.6 | 41.484 |
Javascript su node.js | 0.6 [da programma e non da proc exp] |
Anche se può essere falsato (perchè è un tempo preso da programma), conferma la bontà di node.js .
(devo riprendere i tempi di tutti con process explorer in modo ponderato, ovvero valutando solo l'esecuzione e non l'avvio).