[Gfoss] Compilazione qgis su windows

Local Chapters GFOSS.it
1 
>a) si, è vero: installare MinGW/MSYS non è esattamente
>   il top della semplicità. specie la prima volta può
>   anche essere abbastanza sconvolgente.
>   il punto è che si tratta di strumenti che seguono

>   passo passo la logica operativa di Unix/Linux.
>   certo, per chi è abituato a WinOZ può anche essere 
>   un bel trauma :-)

Infatti.

Sono incagliato sulla compilazione di SIP e non ne sono ancora uscito...

Sul sito QT in effetti all'inizio ho provato con QT4.6 e Python 2.7,
poi pero' sono sceso a QT4.4 e Python 2.5 ma di compilare SIP non se ne parla ...

Non mi resta che tornare indietro a GCC 3.4.

>b) anche questo è vero: la versione stabile/ufficiale
>   (quella con l'installer automatico, per capirsi)
>   supporta un GCC "vecchiotto".
>   però va anche detto che è assolutamente stabile,

>   e che funziona perfettamente bene.

Puo’ darsi, ma e’ una situazione che rischia di invecchiare in fretta.
Non sono esperto, ma non so’ quanto la versione GCC 3.4 sia usabile per una eventuale (e futuribile) compilazione a 64bit.

>) MSVC genera codice che gira più veloce ...
>   si, è sicuramente vero, confermo
>   però va anche detto che un conto è fare qualche test 

Bah, non so' neanche se alla fine sia vero.

Probabilmente la maggiore velocita' e' legata al fatto che MSVC sa' che verra' usato solo su Windows e quindi conosce gia' a menadito il gestore di memoria di Win,
e il suo gestore del FileSystem.

Invece, GCC dovendo essere multipiattaforma non puo' legarsi a strategie prestabilite.


>f) sempre a proposito di velocità: in linea di massima
>   va anche detto che Linux è sensibilmente più pimpante

>   di WinOz praticamente in tutte le condizioni d'uso.
>   - l'intero subsystem di I/O ha un'efficienza neppure
>     lontanamente comparabile: specie per quanto riguarda
>     la gestione del disk caching WinOz fa veramente pena

>   - malloc / free su WinOz sono notoriamente di una
>
>     lentezza/inefficienza esasperante

Davvero ? 
Interessante...

Hai gia' svolto delle prove con MinGW a allocare e liberare risorse sia su Win che su Linux ?

–

Andrea Peri
. . . . . . . . .
qwerty àèìòù

2

On Wed, 11 Aug 2010 14:29:07 +0200, Andrea Peri wrote

Sono incagliato sulla compilazione di SIP e non ne sono ancora uscito…
Sul sito QT in effetti all’inizio ho provato con QT4.6 e Python 2.7,
poi pero’ sono sceso a QT4.4 e Python 2.5 ma di compilare SIP non se ne parla …
Non mi resta che tornare indietro a GCC 3.4.


come volevasi dimostrare: infatti SIP è esattamente uno di quei packages 

"sfigati" di cui parlavo nell'altro mio post.

fare una build con MinGW/MSYS rasenta la follia ... o la santità,

come preferite.

magari con MSVC invece si scopre che gira liscio ... ma vedi un po' ...

> >   - malloc / free su WinOz sono notoriamente di una

> >     lentezza/inefficienza esasperante

> Davvero ? 

> Interessante...

>

Andrea, sono riuscito a ritrovare il riferimento:

http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html

vedi al punto:

12 Hacking the source / 

12.1 Replace the memory allocation library

"The memory allocation is notoriously bad on some systems (e.g. Windows). 

Replacing the functions malloc(), realloc(), and free() on these systems 

can have a dramatic effect on performance."

ciao Sandro
3

12 Hacking the source /

12.1 Replace the memory allocation library

"The memory allocation is notoriously bad on some systems (e.g. Windows).

Replacing the functions malloc(), realloc(), and free() on these systems

can have a dramatic effect on performance."

Es. tcmalloc
http://goog-perftools.sourceforge.net/doc/tcmalloc.html
http://stackoverflow.com/questions/858592/windows-malloc-replacement-e-g-tcmalloc-and-dynamic-crt-linking

giovanni

4

On Wed, 11 Aug 2010 14:29:07 +0200, Andrea Peri wrote

Hai gia’ svolto delle prove con MinGW a allocare e liberare risorse sia su Win che su Linux ?

Ok, come suggerito da Andrea ho perso un po’
di tempo per fare benchmarking comparativo:
tanto mi è servito comunque per testare il rilascio
ormai imminente della prossima SpatiaLite :slight_smile:

ho ottenuto risposte di una nettezza cristallina
(e purtroppo, decisamente imbarazzante per
“qualcuno” che ne esce decisamente malconcio)

metodologia:

  • sono partito dagli SHP free del Comune di
    Merano (è un dataset abbastanza “polposo”,
    sono circa 80MB su una ventina di tavole,
    circa 100,000 entità)

  • quindi ho buttato giù uno script SQL per
    splite che effettua le seguenti operazioni:
    a) carica gli SHP nel DB
    b) crea uno spatial index per ogni tavola
    c) infine (sempre per ciascuna tavola)
    effettua il calcolo del numero delle
    entità e determina l’extent della tavola.
    per le tavole POLYGON viene anche calcolata
    la superficie media, mentre per le tavole
    LINESTRING viene calcolata la lunghezza media.
    d) il tempo di inizio e fine viene misurato
    direttamente dato che lo SQL script
    inizia e termina con un bel:
    SELECT DateTime(‘now’);

  • insomma, direi che si tratta di un mix di I/O
    e di calcoli ‘pesantucci’, che dovrebbe essere
    abbastanza rappresentativo di casi reali d’uso

  • per evitare effetti strani ho ripetuto ciascun
    test almeno 3 volte (sia con “cache calda” che
    con “cache fredda”)

piattaforma:

tutti i test sono stati effettuati sul medesimo PC

  • Windows7 pro (64 bit) ‘nativo’
  • WindowsXP pro su Virtual Machine
  • Ubuntu 8.04 (32 bit) su VM
  • Debian Lenny (64 bit) su VM

si noti che il confronto non è ad armi pari:

  • le macchine virtuali sono sicuramente svantaggiate,
    seppur magari di poco
  • inoltre le VM “vedono” una configurazione dimezzata:
    due soli cores e 2GB di ram, contro i 4 cores / 4GB
    di ram a disposizione di Win7

ed eccovi i risultati (lo so, lo so che a questo punto
siete veramente curiosi …)

Windows7 / spatialite MinGW/MSYS

65 secondi (journal-file)
50 secondi (WAL)

WindowsXP / spatialite MinGW/MSYS

65 secondi (journal-file)
60 secondi (WAL)

WindowsXP / spatialite MSVC

50 secondi (journal-file)
45 secondi (WAL)

Ubuntu 8.04 (32 bit)

22 secondi (journal-file)
20 secondi (WAL)

Debian Lenny (64 bit) / splite 64 bit

19 secondi (journal-file)
21 secondi (WAL)

giusto per curiosità personale, ho anche
testato le precedente versione di splite
sotto Windows 7

80 secondi

conclusioni:

a) utilizzare sistemi / applicativi 32 bit o 64 bit
non offre nessun vantaggio in termini di velocità

b) l’ultima versione di SQLite è veramente veloce
da far paura, specie in scrittura …
il WAL ha effetti abbastanza peculiari a seconda
della piattaforma … a volte si nota … altre
volte sembra assolutamente irrilevante

c) confermato: il codice generato da MinGW/MSYS
gira più lentamente di quello generato da MSVC.
la differenza è abbastanza sensibile.

d) confermato anche questo: l’unico modo possibile
per velocizzare Windows (se uno proprio non riesce
a rinunciarci in nessun modo, per un motivo o per
l’altro) è quello di …
installarci sopra Linux tramite VM :slight_smile:

ciao Sandro

5

Grazie Sandro. Conferma quanto pensavamo, ma non credevo ci fosse così
tanto margine tra Windows e Linux. La cosa buona per me, è che almeno
a livello server l'azienda fa girare (quasi) tutto su Debian o Ubuntu!

giovanni

Il 11 agosto 2010 20:59, <a.furieri@lqt.it> ha scritto:

On Wed, 11 Aug 2010 14:29:07 +0200, Andrea Peri wrote

Hai gia' svolto delle prove con MinGW a allocare e liberare risorse sia su
Win che su Linux ?

Ok, come suggerito da Andrea ho perso un po'
di tempo per fare benchmarking comparativo:
tanto mi è servito comunque per testare il rilascio
ormai imminente della prossima SpatiaLite :slight_smile:

ho ottenuto risposte di una nettezza cristallina
(e purtroppo, decisamente imbarazzante per
"qualcuno" che ne esce decisamente malconcio)

metodologia:

- sono partito dagli SHP free del Comune di
Merano (è un dataset abbastanza "polposo",
sono circa 80MB su una ventina di tavole,
circa 100,000 entità)

- quindi ho buttato giù uno script SQL per
splite che effettua le seguenti operazioni:
a) carica gli SHP nel DB
b) crea uno spatial index per ogni tavola
c) infine (sempre per ciascuna tavola)
effettua il calcolo del numero delle
entità e determina l'extent della tavola.
per le tavole POLYGON viene anche calcolata
la superficie media, mentre per le tavole
LINESTRING viene calcolata la lunghezza media.
d) il tempo di inizio e fine viene misurato
direttamente dato che lo SQL script
inizia e termina con un bel:
SELECT DateTime('now');

- insomma, direi che si tratta di un mix di I/O
e di calcoli 'pesantucci', che dovrebbe essere
abbastanza rappresentativo di casi reali d'uso

- per evitare effetti strani ho ripetuto ciascun
test almeno 3 volte (sia con "cache calda" che
con "cache fredda")

piattaforma:

tutti i test sono stati effettuati sul medesimo PC
- Windows7 pro (64 bit) 'nativo'
- WindowsXP pro su Virtual Machine
- Ubuntu 8.04 (32 bit) su VM
- Debian Lenny (64 bit) su VM

si noti che il confronto non è ad armi pari:
- le macchine virtuali sono sicuramente svantaggiate,
seppur magari di poco
- inoltre le VM "vedono" una configurazione dimezzata:
due soli cores e 2GB di ram, contro i 4 cores / 4GB
di ram a disposizione di Win7

ed eccovi i risultati (lo so, lo so che a questo punto
siete veramente curiosi ...)

Windows7 / spatialite MinGW/MSYS
---------------------------------------
65 secondi (journal-file)
50 secondi (WAL)

WindowsXP / spatialite MinGW/MSYS
---------------------------------------
65 secondi (journal-file)
60 secondi (WAL)

WindowsXP / spatialite MSVC
---------------------------------------
50 secondi (journal-file)
45 secondi (WAL)

Ubuntu 8.04 (32 bit)
---------------------------------------
22 secondi (journal-file)
20 secondi (WAL)

Debian Lenny (64 bit) / splite 64 bit
---------------------------------------
19 secondi (journal-file)
21 secondi (WAL)

giusto per curiosità personale, ho anche
testato le precedente versione di splite
sotto Windows 7
-----------------------------------------
80 secondi

conclusioni:

a) utilizzare sistemi / applicativi 32 bit o 64 bit
non offre nessun vantaggio in termini di velocità

b) l'ultima versione di SQLite è veramente veloce
da far paura, specie in scrittura ...
il WAL ha effetti abbastanza peculiari a seconda
della piattaforma ... a volte si nota ... altre
volte sembra assolutamente irrilevante

c) confermato: il codice generato da MinGW/MSYS
gira più lentamente di quello generato da MSVC.
la differenza è abbastanza sensibile.

d) confermato anche questo: l'unico modo possibile
per velocizzare Windows (se uno proprio non riesce
a rinunciarci in nessun modo, per un motivo o per
l'altro) è quello di ...
installarci sopra Linux tramite VM :slight_smile:

ciao Sandro

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010

6

Ciao Sandro,

2010/8/11 <a.furieri@lqt.it>

On Wed, 11 Aug 2010 14:29:07 +0200, Andrea Peri wrote

Hai gia’ svolto delle prove con MinGW a allocare e liberare risorse sia su Win che su Linux ?

Ok, come suggerito da Andrea ho perso un po’
di tempo per fare benchmarking comparativo:
tanto mi è servito comunque per testare il rilascio
ormai imminente della prossima SpatiaLite :slight_smile:

se non ci fossi dovrebbero inventarti :slight_smile:

ho ottenuto risposte di una nettezza cristallina
(e purtroppo, decisamente imbarazzante per
“qualcuno” che ne esce decisamente malconcio)

tutti i test sono stati effettuati sul medesimo PC

  • Windows7 pro (64 bit) ‘nativo’
  • WindowsXP pro su Virtual Machine
  • Ubuntu 8.04 (32 bit) su VM
  • Debian Lenny (64 bit) su VM

si noti che il confronto non è ad armi pari:

  • le macchine virtuali sono sicuramente svantaggiate,
    seppur magari di poco
  • inoltre le VM “vedono” una configurazione dimezzata:
    due soli cores e 2GB di ram, contro i 4 cores / 4GB
    di ram a disposizione di Win7

ed eccovi i risultati (lo so, lo so che a questo punto
siete veramente curiosi …)

Windows7 / spatialite MinGW/MSYS

65 secondi (journal-file)
50 secondi (WAL)

WindowsXP / spatialite MinGW/MSYS

65 secondi (journal-file)
60 secondi (WAL)

WindowsXP / spatialite MSVC

50 secondi (journal-file)
45 secondi (WAL)

Ubuntu 8.04 (32 bit)

22 secondi (journal-file)
20 secondi (WAL)

Debian Lenny (64 bit) / splite 64 bit

19 secondi (journal-file)
21 secondi (WAL)

I test confermano quasi tutti i presupposti.
Peccato soltanto che non hai potuto fare i test su Debian e Ubuntu
in nativo. Ne avremmo viste più che delle belle, delle bellissime :slight_smile:

Saluti

–
Giuseppe Sucameli