Bench linguaggi di programmazione

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).

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License