Compilazione qgis su windows

[Andrea Peri]

>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 àèìòù
-----------------


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[a.furieri]

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[giohappy]

> 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
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[a.furieri]

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

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 :-)
  
ciao Sandro

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[giohappy]

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,  <[hidden email]> 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 :-)
>
> 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 :-)
>
> ciao Sandro
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> 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
>

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Giuseppe Sucameli]

Ciao Sandro,

2010/8/11 <[hidden email]>

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

se non ci fossi dovrebbero inventarti :)
 

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

Saluti

--
Giuseppe Sucameli

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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