Newsgroup: it.comp.lang.c
Titolo: Ma perchè?

Ho fatto due stupidissimi programmini che stampano su schermo "hello world"
in versione console in Delphi e in c. Il fatto è che il delphi proceduce un
exe di 16 kb, il vc 6 28 kb!!! La procedura è questa:
program Ciao; {APPTYPE CONSOLE}
begin
writeln('hello world');
end.
#include <stdio.h>
void main()
{
printf("hello world\n");
}
Come mai il Pascal si comporta meglio?!? Per le app console conviene usare
il delphi allra? Sono un principiante :-)
-=Azathoth=-

il delphi allra? Sono un principiante :-)
Hai tolto le informazioni di debug ? 
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------

 exe di 16 kb, il vc 6 28 kb!!!
E' probabilmente solo il codice di start-up che fa la differenza. Al
crescere delle dimensioni del programma i due compilatori dovrebbero
divenire equivalenti.
EMG


#include <stdio.h>
int main()
{
    printf( "Hello, world!\n" );
}
Questo programma compilato con VC4 (dando semplicemente "cl c1.c") viene circa 
18.5K, mentre:
#include <conio.h>
int main()
{
    cputs( "Hello, world!\n" );
}
occupa appena 11K.
Anche la printf() ha il suo peso...

Certo, altrimenti erano 150 Kb, alla faccia di Wirth Niklaus
8-P
-=Azathoth=-

11 kb? A me vengono 24 :-\ Non che sia uno sproposito, ma a questo punto
preferisco usare il Delphi piuttosto che impazzire! Con l'aumentare delle
versioni aumenta sempre pure la dimensione degli exe. Guardate per esempio
le run times per Visual Basic 6!!! Eheh, col Tp7 un messaggio su schermo
occupa 2 kb, con l'assembly sono arrivato (copiando il codice perchè non lo
conosco) a 500 bytes. E' fuori luogo, chiaramente anche col turbo c la dim.
sarebbe minore... Sono un pò rattristato per la "console", ma pi la musica
cambia. Un form vuoto in Delphi è grosso 300 kb (a - che non si usano tutte
le Api) e la ver. console, appena si aggiunge una unit si arrivano 100 kb e
+.
-=Azathoth=-

 il delphi allra? Sono un principiante :-)
Perchè gli eseguibili creati dal compilatore c contengono un'utilità di
debug....
Mi sembra che anche i programmi pascal la contengano...però.....non si sa
mai...
NoBoDy

Utilità di debug, ovvero? Grazie e ciao.
-=Azathoth=-

Hai tolto le informazioni di debug ?
Cosa sono le informazioni di debug? È forse per questo che un programma
sulle matrici che ho fatto (e che non posto perché è piuttosto lunghetto),
viene 14 kb compilato con lcc e 110 kb compliato con il djgpp (preso perché
andava in dos, così lo posso usare anche sul 486!).
E poi perché il djgpp tutto compresso (haha... battuta) occupa una vagonata
di mega e l'lcc, che ha anche interfaccia grafica, ne occupa solo uno e
mezzo?
Sono questi i misteri della vita...
Ciao,
Zeppe

preferisco usare il Delphi piuttosto che impazzire! Con l'aumentare delle
Ma credi davvero che si possa operare una scelta su quale linguaggio
utilizzare, basandosi sulla dimensione del codice generato ?
Dipende sicuramente dal contesto, ma oggigiorno quella delle
dimensioni del codice oggetto non e' piu' una questione rilevante.


Certo, altrimenti erano 150 Kb, alla faccia di Wirth Niklaus
Che c'entra Wirth ? ;)


Sono questi i misteri della vita...
Misteri molto poco interessanti, pero', ;))


 mezzo?
Però, se non sbaglio, lcc è solo C mentre DJGPP anche C++.
EMG

Però, se non sbaglio, lcc è solo C mentre DJGPP anche C++.
solo se installi, oltre ai moduli c, anche i moduli gpp e le
librerie...


Certo che no, a - che io non sia solo un hobbysta e sarei disposto a
lavorare 10 minuti in + per guadagnare 1 kb ;-)
-=Azathoth=-

ehehe, c'entra, c'entra! Prova a leggere Algoritmi + strutture dati =
programmi. Ci sono 200 pagine che parlano solo degli algoritmi per ordinare
di array. Sarà meglio il quicksort o il bubblesort? Magari il primo impiega
2 decimi, il secondo mezzo secondo. Cambia qualcosa? No, ma questo è il
bello!
-=Azathoth=-

Io intanto ho continuato i miei esperimenti. Con il Turbo C (levando sempre
le info di debug) ottengo un exe da 5,3 kb. Il TP7, con i suoi 2,5 kb rimane
imbattuto tra i linguaggi "ad alto livello". Con l'assembly poi sono 500
bytes, ma è un'altra cosa :-)
-=Azathoth=-

 librerie...
Chiaro. Ma dalle dimensioni dei files di cui parlava l'amico mi sembrava
che le avesse installate tutte.
EMG

...

No, anzi, ho preso proprio il necessario per il C. Più l'interfaccia
grafica, of couse.
Oltretutto anche l'lcc è c++, mi sembra (non so nulla di c++ quindi non
fidatevi)...
Ciao,
Zeppe

 mezzo?
L'interfaccia grafica per i programmi di win9x sta tutta in librerie
che non sono comprese nell'eseguibile, ed e' per questo motivo che hai
bisogno di tutti i vari .dll e simili per farli funzionare.
--
 Ciao, Luca.
 Reply to 
luca....@tiscalinet.it



se lavori con moltissimi dati il mezzo secondo x 100000 fa la
differenza
Aranar
e-mail: 
ro...@geocities.com
http://www.nettaxi.com/citizens/Aranar/
   (above all VgaPlanets)
http://www.tempolibero.com/user/aranar
    (sopratutto VgaPlanets)

bello!
Certo che cambia qualcosa ! 
Hai mai studiato le complessita' degli algoritmi ? 
Leggere uno dei libri sacri della programmazione per poi concludere
che cio' che dice e' irrilevante non e' molto saggio e non c'entra
nulla con quanto stiamo dicendo. Una cosa e' parlare delle dimensioni
del codice oggetto, una cosa e' invece la velocita' di ordinamento dei
dati.


bytes, ma č un'altra cosa :-)
Ok, allora scrivi pure i tuoi programmi in assembly ;)


In effetti hai ragione, ma io apprezzo moltissimo anche gli eseguibili di
dim. ridotta :-)
-=Azathoth=-

 che cio' che dice e' irrilevante non e' molto saggio e non c'entra
Proprio perchè uno conosce quello di cui sta parlando può giudicare se è
rilevante o meno.
Del resto la velocità un ordinamento ha importanza a seconda del compito. In
un PC che, una volta al giorno, deve ordinare l'elenco degli appuntamenti
della giornata per un dipendente di un'azienda, è assulutamente irrilevante
che ci metta 0,2 o 0,5 secondi.
Se invece devo ordinare l'elenco telefonico d'Italia, e devo farlo ogni
volta che si aggiunge/toglie un utente, magari è meglio che cerco un
algoritmo efficente, ma nota che qui probabilmente si parla della differenza
tra ore e minuti di elaborazione.
Oppure se l'ordinamento è solo un passo di un processo più sofisticato,
tornano ad essere importanti non solo i decimi di secondo, maforse anche i
cicli di clock.
Penso, ad esempio, ad un programma di scacchi che, presumibilmente, deve
ordinare le mosse possibili ad ogni passo della computazione mentre valuta i
vari livelli di profondità del suo albero di decisione.
Inoltre, come ben saprai, vi sono situazioni in cui la valutazione delle
prestazioni asintotiche non dà sufficenti garanzie di velocità.
Immagina 2 algoritmi: uno di comlessità (caso peggiore) esattamente uguale
a:
T = K N^2
il tempo (in secondi) è uguale a K volte il numero di elementi da ordinare
(N) elevatoal quadrato. (complessità quadratica).
e un altro:
T1= K1 log(N)
dove il tempo è uguale a K1 moltiplicato il logaritmo (se vuoi: base 2) di
N.
Ora: è sempre vero che il secondo è più veloce?
Si possono scegliere K e K1 tali che il primo algoritmo può essere molto
vantaggioso anche per N piuttosto grande.
Perciò nella scelta di un algoritmo a mio parere non bisogna procedere ad
occhi chiusi fidandosi della propria intuizione o magari su "regole
universali", ma riflettere anche su come il problema influenza la bontà di
un algoritmo rispetto ad un altro.
--
Alessandro Monti

un algoritmo rispetto ad un altro.
Cioe', in conclusione di questo messaggio, convieni che parlare della
differenza tra i diversi algoritmi di ordinamento HA indiscutibilmente
una grande importanza, contrariamente a quanto ho letto in questo
thread.


 thread.
Certamente.
Non capisco però dove, in questo thread, si sarebbe detto che non vale la
pena parlare degli algoritmi di ordinamento e le loro differenze in termini
di prestazioni, a parte la considerazione che nel 99,9% dei casi la
differenza è invisibile all'utente.
Se fosse come dici, useremmo sempre gli stessi algoritmi per ogni compito,
no?
--
Alessandro Monti

no?
Se fosse come c'e' scritto sopra sarebbe cosi', non se fosse come dico
io.


Guarda, la scelta di un algoritmo secondo me varia da caso a caso. Per
l'elenco telefonico sceglierei il Qucksort, per ordinare 5 numeri va bene
qualsiasi cosa. Se ci mette 2 decimi o 1 secondo a me, in questo caso, non
cambia nulla :-)
-=Azathoth=-

Se sapessi già farlo non starei qui ;-) Ci sono un milione di cose da
imparare, non si finisce proprio mai! :-)))
-=Azathoth=-

you wrote:

per ordinare 5 numeri io non sceglierei neanche un algoritmo di
ordinamento, se e' per questo ! ;)


 Se fosse come c'e' scritto sopra sarebbe cosi', non se fosse come dico
Allora avevo capito male. Pensavo che volessi usare sempre il qsort perchè è
risaputo che è asintoticamente il migliore. Chiedo venia.
--
Alessandro Monti