OT Programmazione 2014

[MItaly]

Poi leggi le ultime domande su SO e fai un infarto. Ho capito le prestazioni ma anche un po' di coerenza e.e
http://stackoverflow.com/questions/2...ode=73389|dcdf

Dio santo cosa stavano pensando? Piuttosto fai una roba tipo QVector, con implicit sharing ma che sei sicuro che copia a qualunque operazione di modifica (ovvero, la semantica visibile è di deep copy).

(parentesi: oggi in produzione è arrivata la prima fattura elettronica PA da smistare)
(è andata avanti a calci in culo, ma è passata )

Fortunatamente la PA non è nostra cliente giusto l'altra settimana abbiamo scritto uno script che smonta un PDF con tutte le fatture generate dal gestionale (di cui è meglio non parlare ), lo separa, individua i destinatari e spedisce via mail, e alla fine salta fuori che bisogna fare cose strane addizionali con la PEC.

La questione è stata risolta aggiungendo in fondo alla mail una scritta tipo "stampatela e facciamo tutti finta di averla inviata via posta normale".

---

Unrelated: rirovato oggi nei sorgenti di un'applicazione interna:

            // il marcio della logica dei delta asimmetrici e del punto
            // centrale si attesta su 0.83 MPI
            // (1 MPI := Marciume della Politica Italiana al 2014)

[Scara95]

Dio santo cosa stavano pensando? Piuttosto fai una roba tipo QVector, con implicit sharing ma che sei sicuro che copia a qualunque operazione di modifica (ovvero, la semantica visibile è di deep copy).

Ma dai non essere banale: quella era una soluzione troppo semplice. Loro sono la Apple: scrivono il futuro dell'informatica non possono perdersi in luoghi comuni.

di cui è meglio non parlare

??

La questione è stata risolta aggiungendo in fondo alla mail una scritta tipo "stampatela e facciamo tutti finta di averla inviata via posta normale".

Io al tuo posto non lo direi tanto in giro

Unrelated: rirovato oggi nei sorgenti:

            // il marcio della logica dei delta asimmetrici e del punto
            // centrale si attesta su 0.83 MPI
            // (1 MPI := Marciume della Politica Italiana al 2014)

Di quanto tempo fa se posso chiedere?

[MItaly]

Ma dai non essere banale: quella era una soluzione troppo semplice. Loro sono la Apple: scrivono il futuro dell'informatica non possono perdersi in luoghi comuni.

??

Lascia stare guarda, è una cosa allucinante; ho visto ogni tanto spuntare dei messaggi di errore che danno l'idea di un marcio apocalittico dentro, e tra l'altro non è neanche dei peggiori (il documentale è ben peggio ).

La teoria di cui si discuteva con un mio collega è che gestionali & co. (soprattutto in ambito contabilità/tasse/...) tendono ad allontanare la competenza, perché la maggior parte dei programmatori bravi a scrivere quella roba si rompe le balle nel giro di dieci minuti, e appena ha occasione scappa a fare qualche altro lavoro. Segue che la competenza media di chi lavora a questi programmi tende ad auto-assestarsi su un livello medio-basso.

Io al tuo posto non lo direi tanto in giro

Di quanto tempo fa se posso chiedere?

In realtà qualche settimana, ma mi ero dimenticato di averlo scritto nel frattempo (sono state settimane ingarbugliate). Non a caso le vicissitudini di questo programmino stanno già entrando nella leggende aziendali (il core è abbastanza ben fatto, ma tutto il resto è un pasticcio clamoroso dato che le specifiche hanno molto poco senso e cambiano davvero ogni 10 minuti ).

[Alex'87]

Fortunatamente la PA non è nostra cliente giusto l'altra settimana abbiamo scritto uno script che smonta un PDF con tutte le fatture generate dal gestionale (di cui è meglio non parlare ), lo separa, individua i destinatari e spedisce via mail, e alla fine salta fuori che bisogna fare cose strane addizionali con la PEC.

La questione è stata risolta aggiungendo in fondo alla mail una scritta tipo "stampatela e facciamo tutti finta di averla inviata via posta normale".

Le "strane cose addizionali" sono all'ordine del giorno sul prodotto su cui sto lavorando. Tant'è che alla fine sono diventate parte del programma stesso C'è un intero modulo che tratta le "forzature", in pratica è un'enorme sistema che gestisce tutti i casi particolari di tutte le catene batch che girano

Unrelated: rirovato oggi nei sorgenti di un'applicazione interna:

            // il marcio della logica dei delta asimmetrici e del punto
            // centrale si attesta su 0.83 MPI
            // (1 MPI := Marciume della Politica Italiana al 2014)

XD

[MItaly]

Le "strane cose addizionali" sono all'ordine del giorno sul prodotto su cui sto lavorando. Tant'è che alla fine sono diventate parte del programma stesso C'è un intero modulo che tratta le "forzature", in pratica è un'enorme sistema che gestisce tutti i casi particolari di tutte le catene batch che girano

Eh infatti anch'io sto cercando di concentrare tutto il Male in un unico punto

Ti dico solo che questa roba nasceva come un simulatore fisico di un certo sistema con una GUI semplice semplice, è stato riattato a metà strada a interprete JavaScript (per poter gestire script di simulazione in Montecarlo) e lo sviluppo attuale tende a realizzare quella che noi chiamiamo "la maschera più brutta del mondo", che ricorda un Excel brutto con dentro parametri di simulazione & co. Attualmente il programma salva i parametri in tre modi diversi (a seconda del punto della GUI da cui decidi di salvare), incluso un salvataggio automatico che alla fine fa l'override di tutti gli altri settaggi.

Un bel programma, insomma.

Tra l'altro, mi serviva fare il deploy Windows a 64 bit (perché questo coso deve andare veloce e fa un fottio di conti - specialmente in virgola mobile - per cui può solo beneficiare delle varie SSE e dei registri aggiuntivi), e l'unico compilatore supportato dai binari Qt forniti direttamente da Digia è VS2013.

Ora, io non so chi stia dirigendo lo sviluppo di Visual Studio in Microsoft, ma secondo me si stanno bruciando il cervello con 'sta storia del Metro-izzare e stupidizzare tutto.
Hanno iniziato con la stupenda idea dei menu CAPS LOCK, adesso scarico l'installer di VS2013 Express e scopro che il normale wizard con la scelta delle features da installare è stato sostituito da un gigantesco pulsante "INSTALLA" che ti riversa su disco 5 GB di stronzate di cui non me ne faccio niente (e che tra l'altro sulla VM di build Windows 7, che ha 20 GB di disco di cui 15 occupati da Windows stesso - altra questione che mi lascia allibito - non ci sta).
Ora, io capisco che vogliano spingere su tutte le loro tecnologie nuove e non confondere i principianti con troppe opzioni, però cacchio, è pur sempre uno strumento per sviluppatori, ovvero utenti esperti per definizione. Perché devo installare F#, VB.NET, un'istanza di MS SQL locale, i suoi strumenti di gestione, la roba per la validazione delle app per l'app store Microsoft e altre millemila componenti inutili? Io voglio solo un compilatore C++ da riga di comando e il Windows SDK, il resto lo fa Qt Creator.

(comunque alla fine sono riuscito ad installare solo quel che mi serviva installando a pedate - perché a lanciarli normalmente ti dicevano di lanciare setup.exe - un po' di .msi dal nome promettente )


Ma tra l'altro, sbaglio o scara95 oggi inizia la maturità?

(in bocca al lupo nel caso )

[Scara95]

Eh infatti anch'io sto cercando di concentrare tutto il Male in un unico punto

Ti dico solo che questa roba nasceva come un simulatore fisico di un certo sistema con una GUI semplice semplice, è stato riattato a metà strada a interprete JavaScript (per poter gestire script di simulazione in Montecarlo) e lo sviluppo attuale tende a realizzare quella che noi chiamiamo "la maschera più brutta del mondo", che ricorda un Excel brutto con dentro parametri di simulazione & co. Attualmente il programma salva i parametri in tre modi diversi (a seconda del punto della GUI da cui decidi di salvare), incluso un salvataggio automatico che alla fine fa l'override di tutti gli altri settaggi.

Un bel programma, insomma.

Si prospetta proprio un bel programma: ottima strutturazione con separazione dei task; divisione fra elaborazione dei dati e presentazione; geniale inclusione di un unico sistema di scripting di facile comprensione. Un progetto da manuale insomma

Tra l'altro, mi serviva fare il deploy Windows a 64 bit (perché questo coso deve andare veloce e fa un fottio di conti - specialmente in virgola mobile - per cui può solo beneficiare delle varie SSE e dei registri aggiuntivi), e l'unico compilatore supportato dai binari Qt forniti direttamente da Digia è VS2013.

Ora, io non so chi stia dirigendo lo sviluppo di Visual Studio in Microsoft, ma secondo me si stanno bruciando il cervello con 'sta storia del Metro-izzare e stupidizzare tutto.
Hanno iniziato con la stupenda idea dei menu CAPS LOCK, adesso scarico l'installer di VS2013 Express e scopro che il normale wizard con la scelta delle features da installare è stato sostituito da un gigantesco pulsante "INSTALLA" che ti riversa su disco 5 GB di stronzate di cui non me ne faccio niente (e che tra l'altro sulla VM di build Windows 7, che ha 20 GB di disco di cui 15 occupati da Windows stesso - altra questione che mi lascia allibito - non ci sta).
Ora, io capisco che vogliano spingere su tutte le loro tecnologie nuove e non confondere i principianti con troppe opzioni, però cacchio, è pur sempre uno strumento per sviluppatori, ovvero utenti esperti per definizione. Perché devo installare F#, VB.NET, un'istanza di MS SQL locale, i suoi strumenti di gestione, la roba per la validazione delle app per l'app store Microsoft e altre millemila componenti inutili? Io voglio solo un compilatore C++ da riga di comando e il Windows SDK, il resto lo fa Qt Creator.

(comunque alla fine sono riuscito ad installare solo quel che mi serviva installando a pedate - perché a lanciarli normalmente ti dicevano di lanciare setup.exe - un po' di .msi dal nome promettente )

è l'altro terzo del futuro dell'informatica poi c'è google

Ma tra l'altro, sbaglio o scara95 oggi inizia la maturità?

(in bocca al lupo nel caso )

Purtroppo, e già in italiano mi preoccupo del fuori tema. Titoli di 2 parole, mai visti prima

[MItaly]

Si prospetta proprio un bel programma: ottima strutturazione con separazione dei task; divisione fra elaborazione dei dati e presentazione; geniale inclusione di un unico sistema di scripting di facile comprensione. Un progetto da manuale insomma

Non a caso per metà l'ho scritto io

Purtroppo, e già in italiano mi preoccupo del fuori tema. Titoli di 2 parole, mai visti prima

Se non sono indiscreto, che traccia hai scelto?

Comunque oggi si è visto come le stringhe C++ usate malamente possano costare veramente tanto... al di là di un'altra serie di bachi mostruosi (per cui attualmente questa routine di caricamento di un modello viene chiamata tipo 3 volte per ogni ordine che si carica), c'era una routine di pre-parsing del file (per estrarre solo alcune informazioni sul contenuto) che portava via circa 13 secondi per un modello da 5 MB (~12 decompressa).

Salta fuori che il collo di bottiglia era roba del tipo if(line.substr(0, 4)=="ABC ") ripetuta per qualche volta; rimossi i temporary (e quindi tre allocazioni dinamiche per ogni riga di un file da decine di migliaia di righe) più qualche altra ottimizzazione il runtime è passato da 13 a 1 secondo.

Altra roba notevole: quanto costano i branch misprediction sulle architetture attuali! Nel più inner loop di tutti gli inner loop di un algoritmo piuttosto complesso a cui sto lavorando c'è sostanzialmente la scansione dei pixel in diagonale di una piccola bitmap, fatta partendo da ogni y dell'immagine.
Per fare questo, sostanzialmente c'era una cosa del tipo

for(int y=a; y<limit; ++y)
{
    offset.y=y;
    for(double r; ; ++r)
    {
        Point p = r*direction + offset;
        if(p.x > img.width || p.y >img.height || p.x<0 || p.y<0)
            break;
        Pixel px=img.pixel(p.x, p.y);
        if(px)
        {
            // eccetera
        }
    }
}

Ora, facendo profiling è saltato fuori che i colli di bottiglia erano le coppie cmp/jump: l'if(px) è costosa (perché l'immagine ha un andamento non ben prevedibile dal branch predictor) ma inevitabile; invece, precalcolando fuori il limite corretto di r (invece di fare il controllo sulla posizione risultante) e rimuovendo così la necessità del primo if è venuto fuori un incremento di prestazioni di tutto l'algoritmo di un buon 30%

[Scara95]

Non a caso per metà l'ho scritto io

Se non sono indiscreto, che traccia hai scelto?

Tecnologia pervasiva, ma ho parlato in sostanza della società disinformata, non preparata alla tecnologia che si forma idee scorrette su alcuni argomenti e si espone a rischi inconsapevoli.

Comunque oggi si è visto come le stringhe C++ usate malamente possano costare veramente tanto... al di là di un'altra serie di bachi mostruosi (per cui attualmente questa routine di caricamento di un modello viene chiamata tipo 3 volte per ogni ordine che si carica), c'era una routine di pre-parsing del file (per estrarre solo alcune informazioni sul contenuto) che portava via circa 13 secondi per un modello da 5 MB (~12 decompressa).

Salta fuori che il collo di bottiglia era roba del tipo if(line.substr(0, 4)=="ABC ") ripetuta per qualche volta; rimossi i temporary (e quindi tre allocazioni dinamiche per ogni riga di un file da decine di migliaia di righe) più qualche altra ottimizzazione il runtime è passato da 13 a 1 secondo.

Non preoccuparti, succede in molti linguaggi: spesso le operazioni con le stringhe vengono sottovalutate, e pensa che sei fortunato che in C++ sono mutabili, in molti linguaggi sono immutabili e non ti dico che può venirne fuori in mani inconsapevoli. Il fatto è che pochi se ne rendono conto purtroppo.

Altra roba notevole: quanto costano i branch misprediction sulle architetture attuali! Nel più inner loop di tutti gli inner loop di un algoritmo piuttosto complesso a cui sto lavorando c'è sostanzialmente la scansione dei pixel in diagonale di una piccola bitmap, fatta partendo da ogni y dell'immagine.
Per fare questo, sostanzialmente c'era una cosa del tipo

for(int y=a; y<limit; ++y)
{
    offset.y=y;
    for(double r; ; ++r)
    {
        Point p = r*direction + offset;
        if(p.x > img.width || p.y >img.height || p.x<0 || p.y<0)
            break;
        Pixel px=img.pixel(p.x, p.y);
        if(px)
        {
            // eccetera
        }
    }
}

Ora, facendo profiling è saltato fuori che i colli di bottiglia erano le coppie cmp/jump: l'if(px) è costosa (perché l'immagine ha un andamento non ben prevedibile dal branch predictor) ma inevitabile; invece, precalcolando fuori il limite corretto di r (invece di fare il controllo sulla posizione risultante) e rimuovendo così la necessità del primo if è venuto fuori un incremento di prestazioni di tutto l'algoritmo di un buon 30%

Ma lui è gentile: ti pre-carica un sacco di roba che non userai ma dovrai consumare lo stesso solo per migliorare le prestazioni
Sei TU che vanifichi I SUOI SFORZI scrivendo quella brutta roba complicata u.u
Potevi fare a meno di scriverla!

[MItaly]

Tecnologia pervasiva, ma ho parlato in sostanza della società disinformata, non preparata alla tecnologia che si forma idee scorrette su alcuni argomenti e si espone a rischi inconsapevoli.

Boh, non mi sembra fuori tema, era molto aperto come titolo.

Non preoccuparti, succede in molti linguaggi: spesso le operazioni con le stringhe vengono sottovalutate, e pensa che sei fortunato che in C++ sono mutabili, in molti linguaggi sono immutabili e non ti dico che può venirne fuori in mani inconsapevoli. Il fatto è che pochi se ne rendono conto purtroppo.

Era quello che dicevo ad un mio collega, ma secondo lui invece con le stringhe immutabili si possono fare diverse ottimizzazioni per casi come questo (tipo: substr potrebbe restituire semplicemente una slice - il puntatore punta a metà della stringa "originale" e il count viene adattato).
D'altra parte, nulla impedirebbe di farlo anche con stringhe modificabili in copy-on-write, anche se in C++ ci sono un po' di ostacoli ad implementarlo per substr (ad esempio, se non erro c_str() deve eseguire in tempo costante, e questo non è possibile senza allocare una nuova stringa nel caso di slice), e in generale anche le implementazioni che usavano il copy-on-write si sono convertite alla "short string optimization" perché con i constraint imposti dallo standard per il multithreading la cosa diventava più complicata.

Ma lui è gentile: ti pre-carica un sacco di roba che non userai ma dovrai consumare lo stesso solo per migliorare le prestazioni
Sei TU che vanifichi I SUOI SFORZI scrivendo quella brutta roba complicata u.u
Potevi fare a meno di scriverla!

Seriamente: tutte le varie cache, branch prediction, esecuzione speculativa & co. sono delle figate clamorose a livello di speedup, ma introducono una quantità di "stato nascosto" spesso difficile da dominare a priori. Lascia un po' atterriti come ormai l'unico modo sicuro per sapere se del codice gira veloce è fare profiling, visto che gli effetti per così dire "non classici" dei processori attuali spesso determinano miglioramenti o peggioramenti in velocità di diversi ordini di grandezza.

Related:
http://blogs.msdn.com/b/oldnewthing/.../10533875.aspx
http://stackoverflow.com/q/11227809/214671

[Scara95]

Boh, non mi sembra fuori tema, era molto aperto come titolo.

Si vedrà...

Era quello che dicevo ad un mio collega, ma secondo lui invece con le stringhe immutabili si possono fare diverse ottimizzazioni per casi come questo (tipo: substr potrebbe restituire semplicemente una slice - il puntatore punta a metà della stringa "originale" e il count viene adattato).
D'altra parte, nulla impedirebbe di farlo anche con stringhe modificabili in copy-on-write, anche se in C++ ci sono un po' di ostacoli ad implementarlo per substr (ad esempio, se non erro c_str() deve eseguire in tempo costante, e questo non è possibile senza allocare una nuova stringa nel caso di slice), e in generale anche le implementazioni che usavano il copy-on-write si sono convertite alla "short string optimization" perché con i constraint imposti dallo standard per il multithreading la cosa diventava più complicata.

Ha ragione, se non si prevedono stringhe terminate da NULL. Tuttavia ha torto in un altro punto: in altri casi (che sono più comunemente usate dai principianti tra l'altro) le stringhe immutabili rischiano di rendere peggio. Mi spiego meglio: nel caso si concatenino 2 stringhe i panorami possibili sarebbero questi:

Non hai memoria libera adiacente al blocco -> devi allocare una nuova stringa.

Hai memoria libera adiacente al blocco
|
-usi stringhe terminate da 0 -> non puoi sfruttare il blocco in quanto non c'è modo di unire le stringhe
|
-usi stringhe non terminate -> perdi compatibilità diretta con stragrande maggioranza librerie -> puoi sfruttare il blocco
-|
--devi usare una struttura dedicata (i.e. {size; string_pointer}) che copierai ad ogni passaggio funzione

In sostanza poi finiresti sempre e comunque con l'allocare una nuova stringa (nel caso della concatenazione)
N.B. il problema delle stringhe terminate o non si ripresenta uguale nel caso di substr.