Le topic de la programmation, string, chaînes, cuir et compagnie

**vectra** · 05/04/2012, 13h57

Envoyé par newbie06

Idealement, il aurait fallu passer le tableau en inverse flottant de tes valeurs pour ne plus avoir que des multiplications

Ca tend quand-même à déplacer du temps de calcul d'une procédure à l'autre, non?
Ou j'ai simplement pas compris la remarque...

**Monsieur Odd** · 05/04/2012, 14h30

Je dois chier un CRM modulable en PHP, sans utiliser de framework parce que personne ne pourra le maintenir à part moi sinon... (youpieboite).

J'ai bien mon idée sur comment bricoler un MVC mais j'ai pas trop de temps à perdre à refaire la roue. Toute idée pour faciliter la tâche serait la bienvenue.

**GrandFather** · 05/04/2012, 14h44

Ben... A part te dire de te baser sur un framework MVC existant, je ne vois pas trop quelle autre idée te ferait gagner du temps...

Tu peux quand même te bricoler un système MVC pas trop bancal en rassemblant diverses librairies, comme Doctrine pour les modèles et Smarty pour les vues, par exemple.

Et sinon, quelques conseils très généraux :

- Eviter au maximum les fichiers de configuration à gogo, programmer plutôt par convention ; en d'autres termes, prendre Rails comme modèle plutôt que Symfony.
- Faire en sorte que les contrôleurs soient les plus simples possibles, les règles métiers doivent être cantonnées aux modèles et la logique de présentation aux vues ; si chacune de tes actions fait des dizaines de lignes, c'est que tu as foiré quelque part ton pattern MVC.

**Tiramisou** · 05/04/2012, 15h43

Envoyé par Monsieur Odd

Je dois chier un CRM modulable en PHP, sans utiliser de framework parce que personne ne pourra le maintenir à part moi sinon... (youpieboite).

J'ai bien mon idée sur comment bricoler un MVC mais j'ai pas trop de temps à perdre à refaire la roue. Toute idée pour faciliter la tâche serait la bienvenue.

Fais du Rails.

**Monsieur Odd** · 05/04/2012, 15h51

Yey, ça a l'air marrant, j'ai chipoté un peu en Ruby hier pour la première fois, j'crois que je vais m'y mettre sérieusement.

**GrandFather** · 05/04/2012, 15h58

Ruby c'est le bien.

**Monsieur Odd** · 05/04/2012, 16h06

Ça peut pas être pire que Zend et sa doc de merde.

**GrandFather** · 05/04/2012, 16h13

Zend Framework, c'est le bien aussi.

Enfin, pour du php...

**Monsieur Odd** · 05/04/2012, 16h26

J'suis bien d'accord, j'ai beaucoup bossé avec Zend, mais toujours sur des projets existants, j'suis infoutu de démarrer un projet avec et la doc est nulle à chier.

**GrandFather** · 05/04/2012, 16h35

Avec Zend_Tool tu as un squelette d'application parfaitement fonctionnel en moins de deux minutes, création du layout et de la connexion à la BDD comprises.

Le problème de la doc, c'est qu'elle n'est qu'une doc de référence, on n'y trouve pratiquement aucun conseil méthodologique. Par contre, la bibliographie autour de ZF commence à bien s'étoffer, et on trouve énormément de ressources sur le net. Mais sinon je suis d'accord, la courbe d'apprentissage est assez raide au départ...

**Monsieur Odd** · 05/04/2012, 16h51

J'ai l'impression de souiller le topic avec mes problème de junior à la con.

Faudrait que je trouve la motivation pour attaquer du projet perso et un taf assez motivant pour ne pas passer mes journées à rien foutre entre deux problèmes à la con.

**Foudge** · 05/04/2012, 17h26

Envoyé par deathdigger

J'essaie de faire du WPF en C#, et je suis en train de butter sur le truc le plus con possible :
[..]
Sauf que ça marche pas. Quelqu'un pourrait m'expliquer le pourquoi du comment ?

Le DataContext est bon ?

**newbie06** · 05/04/2012, 18h44

Envoyé par vectra

Ca tend quand-même à déplacer du temps de calcul d'une procédure à l'autre, non?
Ou j'ai simplement pas compris la remarque...

Tu as dit que le range des valeurs par lesquelles tu divises est petit, <500 si je me souviens bien. Donc tu peux tres bien avoir un tableau pre-calcule qui contient les inverses flottant des entiers de 1 a 500.

Ta nouvelle boucle ressemblerait a un truc du genre :

Code:

float inv_flt[501];

void normalise_valeurs(float *array, size_t *counts, size_t len)
{
     for (size_t i = 0; i < len; i++)
          if (counts[i]) array[i] *= inv_flt[counts[i]];
}

Ca sera probablement bien plus rapide sur CPU, mais pas sur GPU d'apres ce que dit Mogluglu.

---------- Post added at 18h44 ---------- Previous post was at 18h07 ----------

Allez je suis de bonne humeur

Code:

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#include <string.h>
#include <sys/time.h>

static inline uint64_t get_clock(void)
{
  struct timespec ts;
  clock_gettime(CLOCK_MONOTONIC, &ts);
  return ts.tv_sec * 1000000000LL + ts.tv_nsec;
}

#define S (1ul << 28)
#define M 501

void normalise_valeurs(float *array, size_t *counts, size_t len)
{
  size_t i;

  for (i = 0; i < len; i++)
    if (counts[i]) array[i] /= counts[i];
}

static float inv[M];

void normalise2(float *array, size_t *counts, size_t len)
{
  size_t i;

  for (i = 0; i < len; i++)
    if (counts[i]) array[i] *= inv[counts[i]];
}

int main(void)
{
  float  *a;
  size_t *c, i;
  uint64_t t1, t2;

  a = malloc(S * sizeof(a[0]));
  c = malloc(S * sizeof(c[0]));

  for (i = 1; i < M; i++) {
    inv[i] = 1.0f / i;
  }

  for (i = 0; i < S; i++) {
    c[i] = rand() % M;
  }

  for (i = 0; i < S; i++) {
    a[i] = (float)i;
  }
  t1 = get_clock();
  normalise_valeurs(a, c, S);
  t2 = get_clock();
  printf("%g ms\n", ((double)t2 - t1) / 1000000);

  for (i = 0; i < S; i++) {
    a[i] = (float)i;
  }
  t1 = get_clock();
  normalise2(a, c, S);
  t2 = get_clock();
  printf("%g ms\n", ((double)t2 - t1) / 1000000);

  return 0;
}

Sur un Xeon X5670 @ 2.93GHz:

Code:

-bash-3.2$ gcc44 -march=native -O3 -mfpmath=sse t1.c -o t1 -lrt
-bash-3.2$ ./t1
1154.44 ms
404.273 ms

Ouai c'est un vieux gcc qui ne supporte probablement pas ce CPU, mais le but etait pas de faire le plus rapide, juste de montrer que mon idee semble bonne

**Møgluglu** · 05/04/2012, 18h47

Envoyé par newbie06

Ouai c'est un vieux gcc qui ne supporte probablement pas ce CPU, mais le but etait pas de faire le plus rapide, juste de montrer que mon idee semble bonne

Et une fois la boucle vectorisée ?

**deathdigger** · 05/04/2012, 18h51

Envoyé par Foudge

Le DataContext est bon ?

Je sais même pas ce que c'est

Si je pige bien, faut que je fasse un this.DataContext = mesips.mes_ips dans le Main() ?
Et si je veux rajouter d'autres choses à binder ailleurs, ça marche comment ?

EDIT : Ok j'ai pigé :

Code:

            this.DataContext = this;

A ajouter.

**newbie06** · 05/04/2012, 19h39

Envoyé par Møgluglu

Et une fois la boucle vectorisée ?

La boucle originale n'est pas vectorisable (pas de division SIMD il me semble) et pour la seconde j'en sais rien parce qu'il y a une indirection quand même. Et puis je pense que le compilo de merde que j'ai utilisé sache vectoriser

**vectra** · 05/04/2012, 19h51

Je reviens d'une session Tesla, mais purée ca traçe...

Je reviens vers vous dès que possible, ils sont en train de fermer le labo (Alsace oblige).

**LeBonDieu** · 05/04/2012, 19h57

Envoyé par vectra

Je reviens vers vous dès que possible, ils sont en train de fermer le labo (Alsace oblige).

Pourquoi, ils t'enferment dedans ? Remarque, tu es en Alsace. À une autre époque....

**Tomaka17** · 05/04/2012, 20h02

Parce que demain c'est férié, bande de français de l'intérieur

**vectra** · 05/04/2012, 22h25

Niewbie, j'avais effectivement pas compris ton idée, et à y repenser, je trouve ca vraiment pas mal. En tous cas, merci de t'être donné autant de mal.

Je pense que la taille du tableau est certainement prédictible en borne haute selon le nombre d'hologrammes acquis. Comme en plus je me situe dans un processus itératif, et que ce tableau ne change pas, on peut considérer qu'il ne coûte rien à créer.

Sur GPU, il y a moyen d'en tirer profit aussi. Ca serait intéressant de le mettre dans une mémoire plus rapide que la mémoire globale afin de limiter le coût de l'accès mémoire supplémentaire (genre mémoire texture?). Ceci dit, le crunch CPU/GPU est déjà tel que le résultat risque d'être moins pestaculaire.

Y'a à creuser...

Ouais, donc voila les résultats obtenus sur une Telsa C2050, en mode ECC et en économie d'énergie:

Code:

/home/vectra/ProjetTOMO/CUDA>TestMoyenne6 -size $(expr 512 '*' 512 '*' 512) -block 512 -show 16

block: 512 1 1
grid: 32768 8 1
::: start cuda call
::: stop cuda call in 0.0175526(s)

Ca fait 30x mon CPU environ, c'est pas trop mal.

Maintenant, le calcul complet: 2 tableaux de 512^3 float divisés par un tableau d'int de 512^3:

Code:

::: start cpu call
::: stop cpu call in 1.25111(s)  (la machine de test Tesla possède un Xeon assez lent)

block: 512 1 1
grid: 32768 8 1
::: start cuda call
::: stop cuda call in 0.0273531(s)

Je pense que la bande passante du GPU y est pour beaucoup. Y'a moyen d'évaluer précisément combien de temps on passe à faire des opérations arithmétiques ou des accès mémoire, sinon? (sur cpu comme gpu).

Sinon, voici sur la Tesla le test du code quasi-complet qui calcule la moyenne des projections, met ca dans un volume compatible avec cuFFT, calcule la FFT, puis copie le résultat (soit l'image volumique stéréo de notre sympathique diatomée) sur deux volumes locaux 512^3 prêts à être visualisés vu qu'ils sont déjà du bon côté du bus PCI express, les canaillous!

Code:

/home/vectra/ProjetTOMO/CUDA>TestMoyenne8 -size $(expr 512 '*' 512 '*' 512) -block 512 -show 16

N: 134217728 (16 shown) | blocksize is:512

::: start push real & imag  //(2 volumes 512^3 float chacun!)
::: stop push real & imag in 0.179678(s)
::: start push count
::: stop push count in 0.0895081(s)
TPB: 512 | BC: 262144 | GridX: 32768 | GridY: 8

block: 512 1 1
grid: 32768 8 1
::: start moyenne
::: stop moyenne in 0.0265406(s)  //calcul de la moyenne et copie du résultat dans un volume complexe compatible cuFFT
::: start fft
::: stop fft in 0.286176(s)  // sur CPU, fftw avec wisdom prend au moins 0.7s sur 3 threads, et décroissance logarithmique selon le nbre de threads... 
::: start detangle
::: stop detangle in 0.0206626(s)  // ca prend plus d'une seconde sur CPU

Ca nous fait 0.33s hors transport PCIe, c'est vraiment rapide. D'autant que, à terme, lorsque la projection située en amont sera effectuée elle aussi sur GPU, il n'y aura presque plus de transport.
Pour l'instant, sur CPU, on en est à 4-5s, hors projection toujours.

Je suis joie.
Bon, faut que je digère tout ca et que je revienne ensuite. J'aimerais savoir utiliser openMP pour blinder la partie CPU avec des parallel-for, mais le dernier essai n'a pas marché.
A++,

**Møgluglu** · 05/04/2012, 22h25

Envoyé par newbie06

La boucle originale n'est pas vectorisable (pas de division SIMD il me semble) et pour la seconde j'en sais rien parce qu'il y a une indirection quand même. Et puis je pense que le compilo de merde que j'ai utilisé sache vectoriser

C'est marrant, sur le forum x86-adv un certain newbie06 m'avait assuré que gcc était capable de vectoriser des boucles non-totalement-triviales. Ça devait être quand gcc-4.4 était la version cutting-edge, d'ailleurs.
Et DIVPS existe depuis le Pentium 3, et quand bien même elle n'existerait pas ça serait une raison ridicule pour refuser de vectoriser. :chieur:

Ce que je veux dire, c'est que l'astuce des inverses précalculés n'est bénéfique que sur du code naïf non-optimisé, même sur CPU. Bon courage pour vectoriser une indirection en SSE.

**newbie06** · 05/04/2012, 23h54

Envoyé par Møgluglu

C'est marrant, sur le forum x86-adv un certain newbie06 m'avait assuré que gcc était capable de vectoriser des boucles non-totalement-triviales.

Faut le virer : soit il racontait des conneries à l'époque, soit il en raconte maintenant

Ça devait être quand gcc-4.4 était la version cutting-edge, d'ailleurs.
Et DIVPS existe depuis le Pentium 3, et quand bien même elle n'existerait pas ça serait une raison ridicule pour refuser de vectoriser. :chieur:

Ce que je veux dire, c'est que l'astuce des inverses précalculés n'est bénéfique que sur du code naïf non-optimisé, même sur CPU. Bon courage pour vectoriser une indirection en SSE.

Ha vi y'a divps. Mais ça m'étonnerait que ce soit pipelinée. Faut tester

Je continue de parier sur la version avec pré-calcul (sur CPU je veux dire).

**TiNitro** · 06/04/2012, 00h14

Envoyé par Tomaka17

Parce que demain c'est férié, bande de français de l'intérieur

Mais fouiii, c'est guand même ingroyab ils sachent pas ça ceux là. Nous on est Fouiquende maintenant, on met les oeufs dans le jardin !

---------- Post added at 00h14 ---------- Previous post was at 00h11 ----------

Envoyé par Møgluglu

C'est pour être sûr que le compilo ne puisse pas optimiser, ce con?

Désolé plutôt occupé en ce moment, et pas très assidu. Mogluglu, tu peux expliquer ? De mon point de vue ça remplace le calcul d'index (incrément + multiplication entière) par une addition, tu veux dire que le compilateur est capable de le faire tout seul ? Ou j'ai pas compris ?

**vectra** · 06/04/2012, 01h01

Je n'ai honnêtement jamais compris cette histoire de vectorisation SSE. C'est trop loin hors du champ de mes compétences, je pense :/

**Møgluglu** · 06/04/2012, 02h40

Envoyé par newbie06

Ha vi y'a divps. Mais ça m'étonnerait que ce soit pipelinée. Faut tester

Je continue de parier sur la version avec pré-calcul (sur CPU je veux dire).

Non, le diviseur n'est pas pipeliné (ça n'a pas vraiment d'intérêt sur un CPU généraliste), mais il est répliqué. DIVPS prend 5 à 12 cycles comme DIVSS, mais vu que le diviseur est court ça sera plus souvent 5 cycles que 12. Par rapport à 4 accès au L1, moi je continue à parier sur la division.

Envoyé par TiNitro

Désolé plutôt occupé en ce moment, et pas très assidu. Mogluglu, tu peux expliquer ? De mon point de vue ça remplace le calcul d'index (incrément + multiplication entière) par une addition, tu veux dire que le compilateur est capable de le faire tout seul ? Ou j'ai pas compris ?

Ça s'appelle la réduction de force (strength reduction). C'est une optim très basique et aucun compilateur depuis les années 70 n'a d'excuse pour ne pas la faire si elle est bénéfique.

Par contre, ça fait potentiellement perdre de l'information. Quand il voit t[42] et t[51], le compilo sait que ça désigne des emplacements différents et peut réordonner les accès comme ça l'arrange. Quand il voit deux pointeurs p et q, il n'en a aucune idée et doit considérer que ça désigne potentiellement le même emplacement (aliasing) et qu'il ne doit toucher à rien. Donc ça doit rester une optim du compilateur fait au dernier moment (enfin, middle-end plutôt).
Le code plein de pointeurs est un merdier immonde à optimiser, et sera en général bien plus lent à la fin que le code écrit proprement avec des index.

Envoyé par vectra

Je n'ai honnêtement jamais compris cette histoire de vectorisation SSE. C'est trop loin hors du champ de mes compétences, je pense :/

Bah c'est comme le GPU, sauf que c'est le compilateur qui assemble les threads en warps plutôt que le matériel.

Au lieu de traiter les itérations de la boucle une par une, il les fait 4 par 4 en utilisant des instructions SSE travaillant sur des vecteurs de 4 éléments. Bien entendu, le compilo n'y arrive jamais.

**vectra** · 06/04/2012, 10h06

Au pire, y'a moyen de gratter quelque chose en utilisant directement une instruction SSE?

**newbie06** · 06/04/2012, 11h03

Envoyé par Møgluglu

C'est marrant, sur le forum x86-adv un certain newbie06 m'avait assuré que gcc était capable de vectoriser des boucles non-totalement-triviales. Ça devait être quand gcc-4.4 était la version cutting-edge, d'ailleurs.
Et DIVPS existe depuis le Pentium 3, et quand bien même elle n'existerait pas ça serait une raison ridicule pour refuser de vectoriser. :chieur:

Ce que je veux dire, c'est que l'astuce des inverses précalculés n'est bénéfique que sur du code naïf non-optimisé, même sur CPU. Bon courage pour vectoriser une indirection en SSE.

C'est vectorise ca ?

Code:

00000000004005e0 <normalise_valeurs>:
  4005e0:       48 85 d2                test   %rdx,%rdx
  4005e3:       74 4b                   je     400630 <normalise_valeurs+0x50>
  4005e5:       31 c0                   xor    %eax,%eax
  4005e7:       eb 23                   jmp    40060c <normalise_valeurs+0x2c>
  4005e9:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
  4005f0:       f3 48 0f 2a c9          cvtsi2ssq %rcx,%xmm1
  4005f5:       f3 0f 10 04 87          movss  (%rdi,%rax,4),%xmm0
  4005fa:       f3 0f 5e c1             divss  %xmm1,%xmm0
  4005fe:       f3 0f 11 04 87          movss  %xmm0,(%rdi,%rax,4)
  400603:       48 83 c0 01             add    $0x1,%rax
  400607:       48 39 c2                cmp    %rax,%rdx
  40060a:       76 24                   jbe    400630 <normalise_valeurs+0x50>
  40060c:       48 8b 0c c6             mov    (%rsi,%rax,8),%rcx
  400610:       48 83 f9 00             cmp    $0x0,%rcx
  400614:       74 ed                   je     400603 <normalise_valeurs+0x23>
  400616:       7d d8                   jge    4005f0 <normalise_valeurs+0x10>
  400618:       49 89 c8                mov    %rcx,%r8
  40061b:       83 e1 01                and    $0x1,%ecx
  40061e:       49 d1 e8                shr    %r8
  400621:       49 09 c8                or     %rcx,%r8
  400624:       f3 49 0f 2a c8          cvtsi2ssq %r8,%xmm1
  400629:       f3 0f 58 c9             addss  %xmm1,%xmm1
  40062d:       eb c6                   jmp    4005f5 <normalise_valeurs+0x15>
  40062f:       90                      nop    
  400630:       f3 c3                   repz retq 
  400632:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
  400639:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

0000000000400640 <normalise2>:
  400640:       48 85 d2                test   %rdx,%rdx
  400643:       74 30                   je     400675 <normalise2+0x35>
  400645:       31 c0                   xor    %eax,%eax
  400647:       66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
  40064e:       00 00 
  400650:       48 8b 0c c6             mov    (%rsi,%rax,8),%rcx
  400654:       48 85 c9                test   %rcx,%rcx
  400657:       74 13                   je     40066c <normalise2+0x2c>
  400659:       f3 0f 10 04 87          movss  (%rdi,%rax,4),%xmm0
  40065e:       f3 0f 59 04 8d 40 12    mulss  0x601240(,%rcx,4),%xmm0
  400665:       60 00 
  400667:       f3 0f 11 04 87          movss  %xmm0,(%rdi,%rax,4)
  40066c:       48 83 c0 01             add    $0x1,%rax
  400670:       48 39 c2                cmp    %rax,%rdx
  400673:       77 db                   ja     400650 <normalise2+0x10>
  400675:       f3 c3                   repz retq 
  400677:       66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
  40067e:       00 00

Aucune idee si c'est de la merde ou pas.

EDIT : au fait y'a une optim avec la version avec multiplication : on peut se passer du test != 0 ; il suffit de dire que inv[0] = 1 et ca le fera.

EDIT 2 : en fait je suis con : la version originale avec div n'est pas vectorisable à cause du test != 0, n'est-ce pas ?

**ElGato** · 06/04/2012, 12h27

Envoyé par Møgluglu

Quand il voit t[42] et t[51], le compilo sait que ça désigne des emplacements différents et peut réordonner les accès comme ça l'arrange. Quand il voit deux pointeurs p et q, il n'en a aucune idée et doit considérer que ça désigne potentiellement le même emplacement (aliasing) et qu'il ne doit toucher à rien. Donc ça doit rester une optim du compilateur fait au dernier moment (enfin, middle-end plutôt).
Le code plein de pointeurs est un merdier immonde à optimiser, et sera en général bien plus lent à la fin que le code écrit proprement avec des index.

Très honnêtement, avec des compilateurs pas trop crétins et pour des plateformes mainstream, c'est à relativiser.
C'est évidemment parfaitement valable pour du code "un peu complexe", hein ! Mais quand t'as une série de blocs indépendants, le compilateur est assez malin, spécialement si tu fais de l'optimisation globale (bon, c'est pas toujours possible...)

J'explique : je bosse en ce moment sur des routines de traitement de signal basiques, en C, avec uniquement des flottants 32 bits. Je compile pour des processeurs "modernes" (Intel, AMD grand public qui ont au moins du SSE2). Chaque opération est réalisée dans son bloc indépendant ; genre un bloc "synthèse de bruit" qui va dans un bloc "filtrage" qui va dans un bloc "multiplication"...
J'ai dû pas mal étudier la chose pour comprendre comment optimiser, et dans la pratique, faire un truc du genre :

Code:

for (blablabla) {
  *out++ = gain * *in++
}

sera systématiquement compilé avec les variables temporaires qui vont bien. C'est même le cas pour des opérations légèrement plus complexes (mettons du filtrage, par exemple).
Même pas besoin de __restrict - qui aide parfois, malgré tout, dans des cas très particuliers. J'ai pas encore pu comparer à l'utilisation de C++, avec itérateurs & co, mais je m'attends à aucun changement.

Pour la vectorisation automatique, msvc (que je suis obligé de me coltiner) est très fruste : y'a quasiment rien. Pas de déroulement de boucle, l'utilisation du SSE réduit à sa plus simple expression (il faut le lui dire explicitement mais il n'utilise que les instructions SSE scalaires : mulss par exemple). Je crois que c'est amené à changer avec la prochaine version, pas sûr...
gcc ne peut faire que mieux.
En revanche dérouler la boucle pour pipeliner tout ça donne toujours de très bons résultats de perf, même si encore une fois msvc est parfois assez débile. Il réorganise peu ou mal les instructions, n'utilise pas forcément les registres : par exemple, quand j'écris explicitement "charge 4 flottants, puis fais 4 multiplications, puis stocke-les", lui est souvent capable de me compiler ça en "je charge un flottant, je le multiplie, je le stocke * 4".
Je pense qu'à ce niveau c'est plus le CPU qui fait le boulot tout seul, mais dans ce domaine j'y connais tellement que dalle que je me contente de constater les gains de perfs.
Enfin passer en SSE augmente quasi-systématiquement les perfs, jusqu'à un vrai facteur 4 dans mon cas. Les seuls cas moins rapides sont les cas où j'ai des branches (un peu comme le test de Vectra plus haut), que je "traduis" en général par un masque que j'applique...Mais là je pense que c'est moi qui ne code pas suffisamment bien.

Bref, mes deux centimes. Je précise que je suis pas du tout spécialisé en info à la base, j'apprends sur le tas, donc tout ça vient juste du décorticage que j'ai pu faire des programmes sur lesquels je bosse. Dans mon cas particulier, par exemple, je me cogne de toute la problématique de la mémoire (le volume de donnée est très, très réduite), pas de cache miss ou autres problèmes.

**rOut** · 06/04/2012, 13h26

A ce propos, j'ai eu à écrire une fonction affichant le dump hexa+ascii d'un tableau d'octets en C, et la version qui fonctionnait le plus rapidement était à base de pointeurs justement. Je l'avais faite avec des tableaux et des indices, et ce n'était pas plus rapide. Alors oui, c'est pas très joli avec les pointeurs et les ++, et je suis déçu que ça aille plus vite comme ça...

http://pastie.org/private/kiuehrfujqe0ngswozphcg

**deathdigger** · 06/04/2012, 15h31

Quelqu'un peut m'expliquer pourquoi en C#, microsoft a décidé qu'une collection ne pouvait être modifié par un autre thread ?
Je regarde partout, ça fait chier tout le monde (obligé de créer son propre type de collection comme ici : http://www.codeproject.com/Articles/...ableCollection ), et je vois pas quoi ça constitue une faille de sécurité

Discussion: Le topic de la programmation, string, chaînes, cuir et compagnie

Outils de la discussion

Règles de messages