Newsgroup: it.comp.lang.delphi
Titolo: confronto delphi-C

ciao,
ho compilato i due sorgenti riportati in basso in delphi 7 e in cbuilder 5
e sorprendentemente ho notato che l'eseguibile C č molto piu' veloce di
quello compilato in delphi (cbuilder impiega circa la metą del tempo
rispetto a delphi). Ho utilizzato le ottimizzazioni offerte dai 2
compilatori.
Ho sbagliato qualcosa io o delphi č particolarmente debole con gli interi
a 64 bit ?
************************************************************************
********************************** delphi ******************************
************************************************************************
{$APPTYPE CONSOLE}
uses
  SysUtils;
type
  arrayof64 = array[0..63] of Int64;
  const
NOTTABLOG : arrayof64 = (
$FFFFFFFFFFFFFFFE,$FFFFFFFFFFFFFFFD,$FFFFFFFFFFFFFFFB,$FFFFFFFFFFFFFFF7,
$FFFFFFFFFFFFFFEF,$FFFFFFFFFFFFFFDF,$FFFFFFFFFFFFFFBF,$FFFFFFFFFFFFFF7F,
$FFFFFFFFFFFFFEFF,$FFFFFFFFFFFFFDFF,$FFFFFFFFFFFFFBFF,$FFFFFFFFFFFFF7FF,
$FFFFFFFFFFFFEFFF,$FFFFFFFFFFFFDFFF,$FFFFFFFFFFFFBFFF,$FFFFFFFFFFFF7FFF,
$FFFFFFFFFFFEFFFF,$FFFFFFFFFFFDFFFF,$FFFFFFFFFFFBFFFF,$FFFFFFFFFFF7FFFF,
$FFFFFFFFFFEFFFFF,$FFFFFFFFFFDFFFFF,$FFFFFFFFFFBFFFFF,$FFFFFFFFFF7FFFFF,
$FFFFFFFFFEFFFFFF,$FFFFFFFFFDFFFFFF,$FFFFFFFFFBFFFFFF,$FFFFFFFFF7FFFFFF,
$FFFFFFFFEFFFFFFF,$FFFFFFFFDFFFFFFF,$FFFFFFFFBFFFFFFF,$FFFFFFFF7FFFFFFF,
$FFFFFFFEFFFFFFFF,$FFFFFFFDFFFFFFFF,$FFFFFFFBFFFFFFFF,$FFFFFFF7FFFFFFFF,
$FFFFFFEFFFFFFFFF,$FFFFFFDFFFFFFFFF,$FFFFFFBFFFFFFFFF,$FFFFFF7FFFFFFFFF,
$FFFFFEFFFFFFFFFF,$FFFFFDFFFFFFFFFF,$FFFFFBFFFFFFFFFF,$FFFFF7FFFFFFFFFF,
$FFFFEFFFFFFFFFFF,$FFFFDFFFFFFFFFFF,$FFFFBFFFFFFFFFFF,$FFFF7FFFFFFFFFFF,
$FFFEFFFFFFFFFFFF,$FFFDFFFFFFFFFFFF,$FFFBFFFFFFFFFFFF,$FFF7FFFFFFFFFFFF,
$FFEFFFFFFFFFFFFF,$FFDFFFFFFFFFFFFF,$FFBFFFFFFFFFFFFF,$FF7FFFFFFFFFFFFF,
$FEFFFFFFFFFFFFFF,$FDFFFFFFFFFFFFFF,$FBFFFFFFFFFFFFFF,$F7FFFFFFFFFFFFFF,
$EFFFFFFFFFFFFFFF,$DFFFFFFFFFFFFFFF,$BFFFFFFFFFFFFFFF,$7FFFFFFFFFFFFFFF  );
var a,b :integer;
t:int64;
begin
 t:=1;
 for b:= 0 to 100000000   do
  for a:= 0 to 63   do  begin
    t:=t xor NOTTABLOG[a];
		t:= t shr a;
		t:=t and NOTTABLOG[a];
		t:= t shl a;
		t:= t or a;
    end;
end.
************************************************************************
************************************ C *********************************
************************************************************************
#include <stdio.h>
__int64 NOTTABLOG[64] = {
0xFFFFFFFFFFFFFFFE,0xFFFFFFFFFFFFFFFD,0xFFFFFFFFFFFFFFFB,0xFFFFFFFFFFFFFFF7,
0xFFFFFFFFFFFFFFEF,0xFFFFFFFFFFFFFFDF,0xFFFFFFFFFFFFFFBF,0xFFFFFFFFFFFFFF7F,
0xFFFFFFFFFFFFFEFF,0xFFFFFFFFFFFFFDFF,0xFFFFFFFFFFFFFBFF,0xFFFFFFFFFFFFF7FF,
0xFFFFFFFFFFFFEFFF,0xFFFFFFFFFFFFDFFF,0xFFFFFFFFFFFFBFFF,0xFFFFFFFFFFFF7FFF,
0xFFFFFFFFFFFEFFFF,0xFFFFFFFFFFFDFFFF,0xFFFFFFFFFFFBFFFF,0xFFFFFFFFFFF7FFFF,
0xFFFFFFFFFFEFFFFF,0xFFFFFFFFFFDFFFFF,0xFFFFFFFFFFBFFFFF,0xFFFFFFFFFF7FFFFF,
0xFFFFFFFFFEFFFFFF,0xFFFFFFFFFDFFFFFF,0xFFFFFFFFFBFFFFFF,0xFFFFFFFFF7FFFFFF,
0xFFFFFFFFEFFFFFFF,0xFFFFFFFFDFFFFFFF,0xFFFFFFFFBFFFFFFF,0xFFFFFFFF7FFFFFFF,
0xFFFFFFFEFFFFFFFF,0xFFFFFFFDFFFFFFFF,0xFFFFFFFBFFFFFFFF,0xFFFFFFF7FFFFFFFF,
0xFFFFFFEFFFFFFFFF,0xFFFFFFDFFFFFFFFF,0xFFFFFFBFFFFFFFFF,0xFFFFFF7FFFFFFFFF,
0xFFFFFEFFFFFFFFFF,0xFFFFFDFFFFFFFFFF,0xFFFFFBFFFFFFFFFF,0xFFFFF7FFFFFFFFFF,
0xFFFFEFFFFFFFFFFF,0xFFFFDFFFFFFFFFFF,0xFFFFBFFFFFFFFFFF,0xFFFF7FFFFFFFFFFF,
0xFFFEFFFFFFFFFFFF,0xFFFDFFFFFFFFFFFF,0xFFFBFFFFFFFFFFFF,0xFFF7FFFFFFFFFFFF,
0xFFEFFFFFFFFFFFFF,0xFFDFFFFFFFFFFFFF,0xFFBFFFFFFFFFFFFF,0xFF7FFFFFFFFFFFFF,
0xFEFFFFFFFFFFFFFF,0xFDFFFFFFFFFFFFFF,0xFBFFFFFFFFFFFFFF,0xF7FFFFFFFFFFFFFF,
0xEFFFFFFFFFFFFFFF,0xDFFFFFFFFFFFFFFF,0xBFFFFFFFFFFFFFFF,0x7FFFFFFFFFFFFFFF
};
int a,b;
__int64 t;
int main(int argc, char* argv[])
{
 t=1;
 for (b= 0;b<100000000;b++)
	for (a= 0 ;a< 63;a++){
		t^=NOTTABLOG[a];
		t>>=a;
		t&=NOTTABLOG[a];
		t<<=a;
                t|=NOTTABLOG[a];
	}        
	return 0;
}
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 	for (a= 0 ;a< 63;a++){
Significa che esamini 
6299999937
 valori (b va da 0 a 99999999 e a va da 0
a 62).
La differenza di calcolo è dovuta al fatto che il codice C esegue
6400000064  - 
6299999937
 = 100000127 di cicli in meno.


6400000064  - 
6299999937
 = 100000127 di cicli in meno.
Sì, però non mi sembra che la differenza del numero di cicli (meno
dell' 1%) giustifichi un tempo di esecuzione doppio.
-- 
Ore 18.30: premo invio.

 dell' 1%) giustifichi un tempo di esecuzione doppio.
E' possibile che il codice C sia maggiormente ottimizzato, ma bisogna
anche vedere in che condizioni giri.  Un ambiente multitasking o con più
processori non è generalmente ideale per fare dei benchmark di questo
tipo.  Mi sembra comunuqe strana una differenza così ampia.  E comunque è
più dell'1% (10000012700/6400000064 = (circa) 1,56%).


Sicuramente il C offre dei vantaggi in fatto di ottimizzazione del codice ed
anche nei confronti del microprocessore sul quale girera' l'eseguibile...
altrimenti chi acquisterebbe un compilatore con un linguaggio perdi tempo (e
pazienza) come il c++?
giorgio
"Andrea Laforgia" <x...@xx.xx> ha scritto nel messaggio
news:cut6vh$3o4$1...@news.newsland.it...


 pazienza) come il c++?
Il C++, a mio parere, è un ottimo linguaggio (per quanto enormemente
complesso), che va ben oltre gli scopi del semplice C e quindi
utilizzabile in molti contesti precisi.


 
puo' anche essere un caso in cui il compilatore e' debole.
Comunque ho sempre visto che il C e quindi credo anche il builder a 
differenza del pascal e del basic non fa molti controlli sui range, come 
  codice e' piu' veloce, ma in caso di errori.............
ciao
-- 
-------------------------------
per scrivere in privato
togliere "1975nosp"
to reply remove "1975nosp"

 compilatori.
Sarebbe bello sapere in dettaglio quali.
Per quanto riguarda delphi, la direttiva di compilazione {$R} incide 
parecchio in questo tipo di algoritmo, quindi. anche se per ovvie ragioni il 
programma in C sarà ancora piu veloce, eventualmente farei un test 
disabilitandola.
Il problema (se si di problema vogliamo parlare) comunque non sta nel modo 
in cui delphi tratta gli Int64, ma eventualmente nelle particolari 
ottimizzazioni del C nell'eseguire i cicli.
Per quel che ricordo, in C le variabili di ciclo vengono trattate 
direttamente nei registri della CPU, mentre in Pascal restano comuni 
variabili in memoria. Solo questo, unito al gran numero di cicli prodotti, 
potrebbe giustificare la differenza di tempo.
Tieni anche in considerazione che l'operazione
    variabile++
di incremento, è molto piu performante rispetto a
    variabile := variabile + 1 o Inc(variabile)
non ricordo bene i dettagli, ma mi sembra sia ottenuta con un'operazione tra 
bit e non con l'operazione matematica della somma.
Inoltre, come già accennato da Andrea, in un ambiente multitasking sono 
veramente troppi i parametri che potrebbero variare le condizioni di 
esecuzione di un algoritmo del genere.
Ciao,
Gianluca. 

     variabile := variabile + 1 o Inc(variabile)
Non č vero, non in C.  Le uniche differenze prestazionali, in questo
genere di operazioni, riguardano il C++ e in particolare quelle classi per
le quali siano stati ridefiniti gli operatori (vedi ++) con l'"operator
overloading".


 utilizzabile in molti contesti precisi.
Se ti riferisci alle risorse (librerie, creazione di device drive, header
sempre presenti e pronti, funzioni a basso livello)  mi trovi d'accordo per
il resto, il linguaggio in se' e' molto dispersivo e lo vedo come un C pieno
di patch per renderlo "orientato agli oggetti" (lo sara' poi per davvero?
;-), questo almeno e' il mio punto di vista.
Prima di passare a Delphi lo usai per programmi windows, non per molto, ed
ebbi la stessa impressione che ai tempi del DOS provavo quando scrivevo in
ASM cose che potevo scrivere in modo molto piu' rapido e preciso in C.
Poi ognuno ha le sue esperienze e gusti e molto dipende dal contesto in cui
lo si usa.
Buona giornata, giorgio

   codice e' piu' veloce, ma in caso di errori.............
Hai toccato una ferita aperta della MS... vedi i vari "buffer ovelflow" che
hanno aperto la strada agli hacker ringhianti contro XP. Sembra che poi
l'abbiano capita e, se non ho inteso male, inserito il controllo nel
compilatore per ottenere la famosa S.P 2.
giorgio

 compilatori.
In ogni caso, oltre agli spunti di riflessione avuti dagli altri
partecipanti al thread, può essere utile dare un'occhio a questo sito:
http://web.archive.org/web/20020803072910/www.optimalcode.com/index.htm
Contiene una serie di linee guida per scrivere codice ottimizzato in
Delphi.
guastatore