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

[Vuzi]

Sinon, totalement HS, mais là j'ai vraiment besoin d'aide. C'est pas vraiment de la prog (Mais ça reste dans le domaine et j'ai pas vu de topac sur les VMs), et je vois pas vraiment l’intérêt de créer un topic pour une simple demande d'aide ('fin si vous pensez que ce serait mieux, dites le et j'ouvrir un topic)

J'ai eu besoin d'utiliser quelque chose pour pouvoir lancer une VM pré-configurée, avec l'idée que n'importe quel dev de la boite puisse lancer le bouzin et runner ses tests automatiquement (Il s'agit de tests qui pourraient altérer son env de dev en plus d'avoir besoin de droits root, donc ils ont ait le choix de les runner dans une VM), et du coup j'ai utilisé Vagrant. Pour ceux qui ne connaissent pas, ça fait ce que je dis (Avec beaucoup de possibilité de config et choses très très intéressantes) en utilisant derrière VirtualBox (Ou autre, mais là je dois utiliser ça). J'ai tout fait chez moi en utilisant comme VM une Ubuntu 14 64 bit et tout fonctionne parfaitement, j'était bonheur.

Seulement quand j'ai voulu mettre ça sur le slave hudson qu'on m'a attribué, qui tourne sur Ubuntu 14 64bit (Ma machine de dev étant sur le dernier Debian), c'est un peu le drame. Mon Vagrant n'arrive plus à lancer de VM en 64 bit, qui se contente d'attendre en boucle de pouvoir s'y connecter en SSH avant de terminer sur une erreur de timeout. J'ai d'abord essayé une VM de Debian, pour le même résultat. Là où ça devient plus inquiétant c'est qu'en 32bit toutes les VMs que j'ai pu tester marchent sans problème, mais comme le projet de notre boite est uniquement en 64bit ça ne me sert pas à grand chose...

Le truc étonnant, c'est que les VMs n'entrent pas dans un état indiquant une quelconque erreur (Comme ça pourrait être le cas si elles n'arrivaient pas booter, non ?), et que forcément Vagrant ne peut pas détecter d'erreur (Puisque pour VirtualBox il n'y en a pas, forcément). Et j'ai passé mon aprem hier dessus, et je ne vois pas de raison logique pour que ça ne fonctionne pas. Du coup dans le désordre :

- En utilisant vboxmanage guestcontrol execute j'arrive à envoyer des commandes sur mes vm en 32 bit (En les ayant démarré à la main, puisque de toute façon vagrant se charger de les télécharger et ajouter à VirtualBox, j'ai juste à les lancer), alors que celle en 64bit m'affichent inexorablement "VBoxManage: error: The guest execution service is not ready (yet)"

- Est ce qu'il est possible que le problème soit que la machine est incapable de gérer des VMs en 64bit ? Ça m'étonnerait beaucoup parce-que ça me semble être le truc con-con de se dire que "de toute façon le problème ne vient pas de chez moi mais de chez eux" et que le boot devrait merder et non pas fonctionner (non ?), y'a un moyen de vérifier ? Ou de forcer quand même le lancement le cas contraire ?

- Incompatibilité ? J'ai essayé avec de vielles versions, et les dernières, et le problème reste le même. De ce que j'ai trouvé sur le net, les gens qui avaient ce genre de problème n'avaient pas config la virtualisation dans leur bios (Mais encore une fois ça me semble trop gros pour être ça), ou alors e sombres problèmes qui n'ont aucune rapport avec mon blème...

- Mes tests ce sont fait sur des VMs étant logiquement livrée avec les même choses en 32 et 64, ayant testé sur ma machine de dev tout se passe parfaitement bien. Donc je ne pense vraiment pas que ça vienne des VMs en elles même.

Pour mon maître de stage ça vient de Vagrant, et j'ai pas envie d'avoir à tout refaire avec des scripts merdiques (Qui refont en moins bien ce que fait Vagrant, mais c'est pas le sujet) pour me retrouver exactement face au même problème. Du coup j'aimerais soit prouver que ça vient bien de Vagrant, au cas où je le lâche, ou de Virtualbox, ou encore de la machine. Et si des canards généreux avaient simplement des pistes ou des idées je serais vachement content là :/

[Teocali]

Pour les slices, je serais tenté d'écrire a[3:] plutôt non ?
(Je ne suis pas expert Python, hein, c'est une question)

En gros, les slices Python, c'est L[start:end:step]. En gros, si tu veux inverser ta liste, tu fais L[::-1]. L[3:] te retourne ta liste a partir de l'index 3. et apres, tu peux commencer a mixer les index negatifs et les step aussi, et ca devient drole. Mais pas forcement pratique.

[Orhin]

Les VM c'est hasbeen, go sur les containers (Docker ).

[Vuzi]

Les VM c'est hasbeen, go sur les containers (Docker ).

Oui surtout pour ce qu'on veut y faire, mais le maître de stage veut à tout prix des VMs, et c'est pas vraiment à moi de décider.

Oui monsieur. A vérifier dans les options du bios.

Y'aurais pas un moyen sans ? Parce-que j'ai pas d'accès physique à la machine, et si je dérange la personne qui se charge de ça autant que j'ai des arguments à faire valoir pour étayer ma théorie (Sinon je sais que je vais me faire jeter pour le coup, en plus ils sont un peu en rush...)

J'avais vu des choses du style chercher les flags de virtualisation http://www.cyberciti.biz/faq/linux-x...amd-v-support/ et effectivement je n'ai pas vu de flag de virtualisation, alors que sur ma machine de dev si...

[kpouer]

j'utilise JEDIT avec un ou deux plugin.
mais au final on finit par utiliser leur saleté (parce que recharger les fichiers dans leur 'ide' c'est rapidement fastidieux).

Si c'est jEdit c'est très bien sinon bouhhh.

[Sp1d3r]

En gros, les slices Python, c'est L[start:end:step]. En gros, si tu veux inverser ta liste, tu fais L[::-1]. L[3:] te retourne ta liste a partir de l'index 3. et apres, tu peux commencer a mixer les index negatifs et les step aussi, et ca devient drole. Mais pas forcement pratique.

Une copie de ta liste. Nuance qui peut avoir son importance.

D'ailleurs, pour copier une liste, il faut faire l1=l2[:] (l1=l2 correspond à "l1 et l2 désigne la même liste.")

[ducon]

Ou L1=list(L2).

[Sekigo Le Magnifique]

Rien à voir.
Aujourd'hui on m'a montré que [-1] sur une liste Python allait chercher le dernier élément.
Quel triso, pardon quadrisomique qui n'écrit que des joujoux one-liner peut imaginer un truc pareil ?

Personnellement, je n'ai jamais eu de bugs sur ça. Et c'est une feature que j'apprécie. Parce que je trouve ça logique.
Par contre, un truc sur lequel je me suis fais avoir pas mal de fois dans le passé, c'est le slicing:

>>> [][10:20]
# Ne lève pas d'erreurs et retourne une liste vide.

J'ai un espèce de blocage mental sur ça. Je l'utilise plus par automatisme qu'autre chose. Je comprend la logique, mais je ne l'accepte pas dans mon subconscient.
C'est très con, parce que j'ai découvert que ça levait pas d'erreurs après plusieurs années de pratique.

Edit: et en parlant des trucs qui me casse le plus les couilles en python.
La "piscine des discussions". multiprocessing.pool.ThreadPool
C'est une vrai saloperie. Pour une seule raison: ça ne te lève pas l'erreur automatiquement, et tu perds la traceback. Un des interêts de python, c'est ses messages d'erreurs qui te prennent par la main.
Et c'est un putain de besoin courant et primaire (quand ton principal goulot d'étranglement est sur les IO). Avoir une pool de thread que tu enclenches au besoin, et qui gèle le programme si tous les threads dans la pool sont occupés.
multiprocessing.pool.ThreadPool, c'est un truc qui n'est même pas dans la doc (enfin, il n'est pas documenté), il traine là, si pour une raison mystérieuse, y a multiprocessing.Pool qui fonctionne pas. Et j'ai rien trouvé qui le remplace dans la stdlib.

[fougny]

Si c'est jEdit c'est très bien sinon bouhhh.

Je ne sais pas si c'est JEdit ou Jedit ou JEDIT
mais c'est jedit : http://www.jedit.org/


Et il est tres bien, je trouve, pour les langages 'exotiques' (en l'occurrence progress 4gl) qui ne sont pas (ou tres mal) gérés par les autres éditeurs plébiscités.
Ses plugin le rende assez versatile.

[Tramb]

Je ne vois pas où est la logique que l[-k] = l[n-k] renvoie le dernier élément.
Ou alors si, on dit que les tableaux sont en arithmétique modulo, mais il faudrait que l[n+k] = l[k]. Ah mais non on ne choperait plus les erreurs de bornes. Bah ouais, exactement!
Si tu computes un indice négatif par erreur (ça arrive, les erreurs), ça te renvoie silencieusement n'importe quoi. Pour que Dédé puisse écrire l[-1] au lieu de l[len(l)-1], on cache une erreur dure à débugger pour michel qui écrit l[i] avec i qui sort d'un appel de fonction compliqué. Cette feature a été pensée pour des valeurs d'index *immédiates* et non issues d'un calcul. Comme d'hab dans ce genre de langage jouet, tu simplifies l'écriture du cas simple en passant de 3 secondes à 1 seconde et tu compliques le débugging du cas compliqué, et là on ne parle pas de secondes.

Pareil que slicer une liste vide à des éléments qui n'existent pas ne renvoie pas d'erreur, c'est complètement absurde. Tu reconnais toi-même que tu t'es fait niquer par ce comportement.
D'autant plus que [][3] renvoie une exception.
Formellement tu as tout le temps l[a:a] = [l[a]] sauf quand l = []. Pas consistent pour un sou. Mais bon si ça permet de gagner 3 caractères sur un super script Python...

Oui, je hais Python et toutes ses groupies qui pensent que Guido a inventé quoi que ce soit

[kpouer]

Je ne sais pas si c'est JEdit ou Jedit ou JEDIT
mais c'est jedit : http://www.jedit.org/


Et il est tres bien, je trouve, pour les langages 'exotiques' (en l'occurrence progress 4gl) qui ne sont pas (ou tres mal) gérés par les autres éditeurs plébiscités.
Ses plugin le rende assez versatile.

Ah bravo c'est bien lui, j'en suis l'un des développeurs, ça fait plaisir de voir un utilisateur ici

[Orhin]

Oui surtout pour ce qu'on veut y faire, mais le maître de stage veut à tout prix des VMs, et c'est pas vraiment à moi de décider.

Vu ce que tu nous racontes en ce moment, transmets lui cordialement de ma part que c'est un con.

[Tramb]

Vu ce que tu nous racontes en ce moment, transmets lui cordialement de ma part que c'est un con.

Résoudre un problème technique (genre faire tourner le truc dans une VM) en ditchant la VM et en proposant Docker, ça me paraît assez con aussi.
On ne connaît pas le dixième des contraintes du projet qui ont conduit à ce choix. Si j'avais eu 10 balles pour tous les stagiaires qui ont voulu résoudre des problèmes en "passant sous Linux", en "passant en C++11", en "passant à OpenGL", en "faisant une dll/so", en "utilisant une extension gcc qui fait exactement ça", en "utilisant plutôt telle lib à la place, elle est mieux" (et j'en passe) avec le petit bout de leur lorgnette...
Je ne dis pas qu'il ne faut jamais rien remettre en question, hein. Juste qu'il ne faut pas systématiquement se dire que les mecs avant n'ont aucune idée de ce qu'ils faisaient.

[Orhin]

Je ne parlais pas de ce problème en particulier mais plutôt de l'ensemble des décisions prises par son maitre de stage depuis le début.
Sinon oui tu as raison, c'est dur de juger lorsqu'on ne détient pas toutes les informations, mais il faut avouer qu'on trouve dans certains projets une inertie sur les technos utilisées qui peut être couteuse en terme de dev.

[Tramb]

Après je ne dis pas que le mec n'est pas un tocard hein, ils abondent dans l'informatique

[kpouer]

En tout cas je connaissais pas Docker, j'en ai pas l'utilité dans mon boulot vu qu'on fait du kernel, mais pour le reste ça peut être intéressant.

[Tomaka17]

en "passant en C++11"

Ca c'est vrai par contre

[Tramb]

Tsss tssss...

[fougny]

Ah bravo c'est bien lui, j'en suis l'un des développeurs, ça fait plaisir de voir un utilisateur ici

Et bien bravo pour le logiciel il est tres pratique (aussi pour ouvrir de tres gros fichiers).
Et si j'ai un problème, maintenant je sais ou venir me plaindre

[vectra]

http://www.akkadia.org/drepper/

http://www.akkadia.org/drepper/cpumemory.pdf

"What Every Programmer Should Know About Memory"
114 pages

Je ne suis qu'une merde


ps: lien découvert par:
http://codearcana.com/posts/2013/05/...bandwidth.html

[Tomaka17]

Ouai enfin c'est plutôt "what every programmer that deals with very-very-low-level stuff should know about memory".
Tant que tu sais ce que c'est un cache et que tu comprends que les données groupées en mémoire sont accessibles plus rapidement et que le SIMD c'est bien, t'as pas besoin de lire le reste.

Dans le même genre, j'ai ce lien sous la main, aka. "exemple concret de comment exploiter une faille de type buffer overflow" : http://insecure.org/stf/smashstack.html

[Tramb]

http://www.akkadia.org/drepper/

http://www.akkadia.org/drepper/cpumemory.pdf

"What Every Programmer Should Know About Memory"
114 pages

Je ne suis qu'une merde


ps: lien découvert par:
http://codearcana.com/posts/2013/05/...bandwidth.html

C'est un papier devenu un classique et très intéressant.
Mais, comme dit Tomaka, tu peux très bien te débrouiller avec une fraction de ces connaissances.

[vectra]

Je viens de tester le non_temporal store de chez AVX (aussi dispo en SSE), et ça marche vraiment bien sur mon Core i5.
Me tarde de rentrer au labo pour voir l'influence définitive sur les perfs, mais ça a l'air prometteur

Par contre, pour le même en load, c'est pas encore gagné cette histoire. Il n'y en a que pour le si256 (AVX) et le si128 (SSE) et pas le ps (float 32 bits).
En cherchant un peu, j'ai trouvé un hack dans une bibliothèque du Cern, mais j'ai pas encore toutes les skills

template<> Vc_ALWAYS_INLINE Vc_PURE m256 VectorHelper<m256>::load(const float *m, StreamingAndAlignedFlag)
{
return avx_cast<m256>(concat(_mm_stream_load_si128(reinte rpret_cast<__m128i *>(const_cast<float *>(m))),
_mm_stream_load_si128(reinterpret_cast<__m128i *>(const_cast<float *>(&m[4])))));
}

La gueule de ma thèse en microscopie, je crois que les rapporteurs vont se tirer une balle avant moi


Et pour finir le WE en beauté:

http://www-db.in.tum.de/~finis/x86-i...sheet-v2.1.pdf

[Tramb]

Un si128 c'est plus ou moins un ps (même register set).
Tente un _mm_castsi128_ps(_mm_stream_load_si128(p)) !

Le cast sera gratos sur toutes les archis modernes (il fut un temps/des archis où tu te tapais une pénalité quand tu alternais opérations flottantes et entières sur un xmm mais c'est révolu).

Et oui, des chercheurs qui voient du code efficace, ça va leur faire tout drôle :D

[vectra]

Dans la salle, y'aura des chercheurs qui se sont tellement vendus à Labview qu'ils ont décidé de faire de notre IUT un centre de formation.
Ils se vendent pour des licences moins chères, c'est affligeant

Alors c'est clair que nous, avec notre code d'aquisition ET de traitement en C++, on va un peu les taquiner
D'autant que le peu de code Labview dont j'ai hérité m'aura, mais alors bien bien pourri la vie


J'ai essayé le coup, j'ai encore un peu de mal:

float* counts; // a été alloué en aligné sur 32 

for(...; i += 8)
{
 __m256 cnt = _mm_castsi256_ps(_mm256_stream_load_si256(&counts[i]);
}

Le souci est que le tableau counts est toujours en float. Je vais voir si je peux le caster aussi...

[Tramb]

Voilà, et tu castes ton pointeur comme un gros chacal.
Pense à mettre const et restrict aussi

Bon, ceci dit le non-temporal, ça dépend vraiment de tes datasets et de tes cache.
Tu peux même perdre de la performance si tu les relis plus tard et qu'ils auraient tenu dans ton working set.
Fais-toi des define pour tester facilement avec/sans et ce PAR SITE, pas globalement Un store peut être pertinent alors que le load d'à côté peut être contreproductif. Et tu mets les résultats de tes expériences en commentaire dans le code avec la date pour t'en souvenir (/vieux briscard)

[vectra]

const pour préciser qui est lu et qui peut être écrit, et __restrict__ pour spécifier que les tableaux ne se recouvrent pas.

La prochaine étape, ça sera d'injecter du code assembleur

[Tramb]

Exactement !

Ça, je pense que tu devrais éviter. Il faudrait te taper tout le scheduling à la main et il peut changer d'un CPU à l'autre. Et tu perdrais la compat gcc/msvc.
Bref, nonnonnon

[vectra]

Bon, c'est pas gagné

void normalize_AVX_nt(const float *data_real, const float *data_imag, 
		      float *out_real, float *out_imag, 
		      const float *counts, size_t len)
{
  size_t i;
  assert(len % 8 == 0);

  const __m256i* icnt = (const __m256i *) counts;
  const __m256i* ireal = (const __m256i *) data_real;
  const __m256i* iimag = (const __m256i *) data_imag;

  // registers contain 256 bits, i.e 8 float words of 32 bits 
  //#pragma omp parallel for num_threads( NUM_THREADS )
  for (i = 0; i < len; i+=8) 
    {
      // cnt = counts[i]
      //       __m128i _mm_stream_load_si128 (__m128i *p);
      //      __m256 cnt = _mm256_stream_load_si256(&counts[i]);
      __m256 cnt = _mm256_castsi256_ps( _mm256_stream_load_si256(&icnt[i]));

      // ar = data_real[i], ai = data_imag[i],
      //       __m256 ar = _mm256_stream_load_ps(&data_real[i]);
      //       __m256 ai = _mm256_stream_load_ps(&data_imag[i]);
       __m256 ar = _mm256_castsi256_ps( _mm256_stream_load_si256(&ireal[i]));
       __m256 ai = _mm256_castsi256_ps( _mm256_stream_load_si256(&iimag[i]));

      // cnt <= max ( 1, cnt )
      cnt = _mm256_max_ps(cnt, _mm256_set1_ps(1.0f));
      // div = 1 / cnt
      __m256 div = _mm256_div_ps(_mm256_set1_ps(1.0f), cnt);

      // data_real[i] *= div
      __m256 resr = _mm256_mul_ps(ar, div);
      __m256 resi = _mm256_mul_ps(ai, div);

      // data_imag[i] /= cnt
      _mm256_stream_ps(&out_real[i], resr);
      _mm256_stream_ps(&out_imag[i], resi);;
    }
}

L'erreur est assez incompréhensible, mais je ne suis plus en état de poursuivre. Je verrai demain avec des neurones régénérés, plus ou moins...

In file included from /usr/lib/gcc/x86_64-linux-gnu/4.9/include/immintrin.h:43:0,
                 from TestMoyenneAVX.cc:10:
/usr/lib/gcc/x86_64-linux-gnu/4.9/include/avx2intrin.h: In function ‘void normalize_AVX_nt(const float*, const float*, float*, float*, const float*, size_t)’:
/usr/lib/gcc/x86_64-linux-gnu/4.9/include/avx2intrin.h:905:1: error: inlining failed in call to always_inline ‘__m256i _mm256_stream_load_si256(const __m256i*)’: target specific option mismatch
 _mm256_stream_load_si256 (__m256i const *__X)
 ^

[Tramb]

Mmmmmh "target specific option mismatch"
Tu as bien -march=core-avx2 ou un truc du genre ?
T'es sûr que ta target aura bien l'AVX 2 d'ailleurs ?