Mostra notizie nelle discussioni
  • Avatar
    ☺
    Scritto da
    Giambo
    il 2013-09-24 08:03:19.0 alle 2013-09-24 08:03:19.0
    Trollate totali: 42885
    Alextg, Argent
    Che fine ha fatto ? Non ci dedichi piu' tempo ora che e' completo (E inutilizzabile) ?
    `"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo
    • Avatar
      ☺
      Scritto da
      altg
      utente che non utiene
      il 2013-09-25 00:36:29.0 alle 2013-09-25 00:36:29.0
      Trollate totali: 11540
      Re: Alextg, Argent
      > Che fine ha fatto ? Non ci dedichi piu' tempo ora che e' completo (E inutilizzabile) ?

      Macche`, aspetto l'ispirazione.
      Intanto mi sto rompendo il cazzo su Lino3.
      Un pochino si`, eh?
      Penso che si`, e` pronto, e salta fuori un'altro dettagliuccio.

      Alla fine per lo stack probing ho adottato, per default, la soluzione "pochi, maledetti e subito", che consiste nel probing di tutta un'area di stack di dimensioni non esagerate (1 milione di unita` per thread, cioe` 4 megabytes ma NON 4 mebibytes, con il resto di 48576 unita` allocato come red zone). Pero` su opzione si puo` tornare al probing in real-time al momento della costruzione di grossi call frames. Pero` non la consigliero`, e` deleteria per la performance. Meglio pochi, maledetti e subito: nell'impostazione di default, il modulo di run-time fa il commit di tutto lo stack di un thread prima di far partire qualsiasi thread, cosi` il call frame e` allocato senza pensieri sottraendo un numero ad ESP e mappando un registro come puntatore base. Tra creazione e distruzione del call frame passano 5 cicli soli. A fare il probing, anche solo per capire se e` il caso di toccare le pagine successive, servirebbero 7 cicli in piu`, cioe` sul mio 2.8 GHz un quattrocentomilionesimo di secondo in piu` per chiamata. Inaccettabile: Linoleum considera importanti anche i miliardesimi di secondo. Ficoso

      PEro` mi sto rompendo il cazzo, voglio fare quel che viene dopo. In lacrime
      • Avatar
        Scritto da
        Non Autenticato
        il 2013-09-25 00:44:57.0 alle 2013-09-25 00:44:57.0
        Re: Alextg, Argent
        > > Che fine ha fatto ? Non ci dedichi piu' tempo ora che e' completo (E inutilizzabile) ?
        >
        > Macche`, aspetto l'ispirazione.
        > Intanto mi sto rompendo il cazzo su Lino3.
        > Un pochino si`, eh?
        > Penso che si`, e` pronto, e salta fuori un'altro dettagliuccio.
        >
        > Alla fine per lo stack probing ho adottato, per default, la soluzione "pochi, maledetti e subito", che consiste nel probing di tutta un'area di stack di dimensioni non esagerate (1 milione di unita` per thread, cioe` 4 megabytes ma NON 4 mebibytes, con il resto di 48576 unita` allocato come red zone). Pero` su opzione si puo` tornare al probing in real-time al momento della costruzione di grossi call frames. Pero` non la consigliero`, e` deleteria per la performance. Meglio pochi, maledetti e subito: nell'impostazione di default, il modulo di run-time fa il commit di tutto lo stack di un thread prima di far partire qualsiasi thread, cosi` il call frame e` allocato senza pensieri sottraendo un numero ad ESP e mappando un registro come puntatore base. Tra creazione e distruzione del call frame passano 5 cicli soli. A fare il probing, anche solo per capire se e` il caso di toccare le pagine successive, servirebbero 7 cicli in piu`, cioe` sul mio 2.8 GHz un quattrocentomilionesimo di secondo in piu` per chiamata. Inaccettabile: Linoleum considera importanti anche i miliardesimi di secondo. Ficoso
        >
        > PEro` mi sto rompendo il cazzo, voglio fare quel che viene dopo. In lacrime

        Non ci capisco niente di tutto questo technobabble, mi sento tagliato fuori. Triste
        • Avatar
          ☺
          Scritto da
          altg
          utente che non utiene
          il 2013-09-25 05:18:28.0 alle 2013-09-25 05:18:28.0
          Trollate totali: 11540
          Re: Alextg, Argent
          > > > Che fine ha fatto ? Non ci dedichi piu' tempo ora che e' completo (E inutilizzabile) ?
          > >
          > > Macche`, aspetto l'ispirazione.
          > > Intanto mi sto rompendo il cazzo su Lino3.
          > > Un pochino si`, eh?
          > > Penso che si`, e` pronto, e salta fuori un'altro dettagliuccio.
          > >
          > > Alla fine per lo stack probing ho adottato, per default, la soluzione "pochi, maledetti e subito", che consiste nel probing di tutta un'area di stack di dimensioni non esagerate (1 milione di unita` per thread, cioe` 4 megabytes ma NON 4 mebibytes, con il resto di 48576 unita` allocato come red zone). Pero` su opzione si puo` tornare al probing in real-time al momento della costruzione di grossi call frames. Pero` non la consigliero`, e` deleteria per la performance. Meglio pochi, maledetti e subito: nell'impostazione di default, il modulo di run-time fa il commit di tutto lo stack di un thread prima di far partire qualsiasi thread, cosi` il call frame e` allocato senza pensieri sottraendo un numero ad ESP e mappando un registro come puntatore base. Tra creazione e distruzione del call frame passano 5 cicli soli. A fare il probing, anche solo per capire se e` il caso di toccare le pagine successive, servirebbero 7 cicli in piu`, cioe` sul mio 2.8 GHz un quattrocentomilionesimo di secondo in piu` per chiamata. Inaccettabile: Linoleum considera importanti anche i miliardesimi di secondo. Ficoso
          > >
          > > PEro` mi sto rompendo il cazzo, voglio fare quel che viene dopo. In lacrime
          >
          > Non ci capisco niente di tutto questo technobabble, mi sento tagliato fuori. Triste

          E non ti ho ancora detto dell'ultima ottimizzazione di stanotte: invece di leggere l'ID del thread corrente chiamando educatamente GetCurrentThreadId e spendendo un centinaio di cicli macchina nella API ufficiale, mi sembra che stia funzionando perfettamente anche l'andarsi a prendere direttamente il thread ID nel thread info block (TIB) accessibile dal descrittore FS all'offset +24h. Si ottiene lo stesso risultato in due cicli esatti. Pero` dicono che il formato del TIB di Win32 non sia proprio ufficiale, pero` Wine lo copia, e tutti lo usano, sicche` e` uno standard di fatto. Imbarazzato

          accludo diapositiva:
          Immagine postata dall'utente

          eh si`, con l'immagine si capisce tutto meglio, vero? Fantasma

          **Modificato dall'autore il 25.09.2013 05:40**
          • Avatar
            ☺
            Scritto da
            altg
            utente che non utiene
            il 2013-09-25 06:09:40.0 alle 2013-09-25 06:09:40.0
            Trollate totali: 11540
            Re: Alextg, Argent
            > > > > Che fine ha fatto ? Non ci dedichi piu' tempo ora che e' completo (E inutilizzabile) ?
            > > >
            > > > Macche`, aspetto l'ispirazione.
            > > > Intanto mi sto rompendo il cazzo su Lino3.
            > > > Un pochino si`, eh?
            > > > Penso che si`, e` pronto, e salta fuori un'altro dettagliuccio.
            > > >
            > > > Alla fine per lo stack probing ho adottato, per default, la soluzione "pochi, maledetti e subito", che consiste nel probing di tutta un'area di stack di dimensioni non esagerate (1 milione di unita` per thread, cioe` 4 megabytes ma NON 4 mebibytes, con il resto di 48576 unita` allocato come red zone). Pero` su opzione si puo` tornare al probing in real-time al momento della costruzione di grossi call frames. Pero` non la consigliero`, e` deleteria per la performance. Meglio pochi, maledetti e subito: nell'impostazione di default, il modulo di run-time fa il commit di tutto lo stack di un thread prima di far partire qualsiasi thread, cosi` il call frame e` allocato senza pensieri sottraendo un numero ad ESP e mappando un registro come puntatore base. Tra creazione e distruzione del call frame passano 5 cicli soli. A fare il probing, anche solo per capire se e` il caso di toccare le pagine successive, servirebbero 7 cicli in piu`, cioe` sul mio 2.8 GHz un quattrocentomilionesimo di secondo in piu` per chiamata. Inaccettabile: Linoleum considera importanti anche i miliardesimi di secondo. Ficoso
            > > >
            > > > PEro` mi sto rompendo il cazzo, voglio fare quel che viene dopo. In lacrime
            > >
            > > Non ci capisco niente di tutto questo technobabble, mi sento tagliato fuori. Triste
            >
            > E non ti ho ancora detto dell'ultima ottimizzazione di stanotte: invece di leggere l'ID del thread corrente chiamando educatamente GetCurrentThreadId e spendendo un centinaio di cicli macchina nella API ufficiale, mi sembra che stia funzionando perfettamente anche l'andarsi a prendere direttamente il thread ID nel thread info block (TIB) accessibile dal descrittore FS all'offset +24h. Si ottiene lo stesso risultato in due cicli esatti. Pero` dicono che il formato del TIB di Win32 non sia proprio ufficiale, pero` Wine lo copia, e tutti lo usano, sicche` e` uno standard di fatto. Imbarazzato
            >
            > accludo diapositiva:
            > Immagine postata dall'utente
            >
            > eh si`, con l'immagine si capisce tutto meglio, vero? Fantasma

            Mah, si`, a ogni modo e` meglio se non lo metto nel RTM come unico modo di ottenere il thread ID. Farei forse meglio a metterlo come stringa di linguaggio macchina in una libreria specifica di Win32, e poi puntarci una label. Quando l'applicazione vuole il modo veloce seleziona il suo indirizzo nel puntatore "thread resolver", se no ci lascia quello ufficiale che usa GetCurrentThreadId. Mi fa l'idea che prima o poi possa far girare le scatole...
<softv>

Pagina generata in 89 millisecondi

Utenti attivi: 12 nell'ultimo minuto, 23 negli ultimi cinque minuti, 46 negli ultimi 15 minuti