reno a écrit 3879 commentaires

Ah oui, je me suis loupé aussi, mince!
Merci de m'avoir corriger.

Ça c'est une réactions aux vidéos de Jonathan Blow sur Jai.
Pas mal, mais dans Jai, tu peux avoir un pointeur sur un objet que tu change de SOA à AOS (ou vice versa) sans modifier le code et je ne crois pas que ça soit le cas ici, je vais essayer d'avoir + d'infos..

Tu réponds trop vite à Enj0lras.
Pour s'assurer qu'un index non-signé est valide pour un accès à un tableau,
c'est une opération: index < longueur.

Pour s'assurer qu'un index signé est valide pour un accès à un tableau,
c'est deux opérations: index < longueur ET index >= 0.

Un avis sur phoronix d'un propriétaire d'Odroid C1:
http://www.phoronix.com/forums/showthread.php?113338-Raspberry-Pi-2-Launches-With-Quad-Core-ARM-SoC&p=468097#post468097
Pas très élogieux..
Le C1 a un connecteur 'direct' Ethernet pas par USB, mais si ça marche aussi uniquement en 100Mbs, est-ce que c'est plus intéressant que le Raspberry Pi? Je ne sais pas, il faudrait mesurer: débit atteint, utilisation CPU..

J'ai lu sur un blog que c'était pour minimiser les risques liés aux changements, mais effectivement c'est dommage..

Merci pour ta réponse, en effet il faut connaître l'ordre pour la version simple, ça m'apprendra de survoler le PDF trop rapidement.

Non PAS "à vouloir chercher la performance"!

En pseudo-assembleur, la version 'sophistiquée':
xor Rx,Ry -> R1
and Rx,Ry -> R2
ushr R1,1 -> R1
add R1,R2 -> R1
4 instructions a décoder, 2 registres temporaires utilisés.

La version simple:
sub Ry,Rx -> R1
ushr R1,1 -> R1
add Rx,R1 -> R1
3 instructions a décoder, 1 registre temporaire utilisé.

Après ça peut dépendre du CPU..

Merci pour le lien, mais note que la version que je donne y est aussi dans le même chapitre 'x + (y - x)/2' ou
'x + ((y - x)>>1)' bonnet blanc et blanc bonnet..

La version '(x & y ) + ((x ^ y) >> 1)' ne s'exécute en 3 cycles que si tu peux faire 2 opérations en parallèle, donc dire que c'est mieux que 'x + ((y-x)>>1)', hum, d'un point de vue en mettre plein la vue ok, mais sinon pas vraiment non..

Et bien dans pas mal de langage si (a + b) dépasse l'entier maximum alors le résultat est indéfini ou tu as une exception, alors qu'avec (si a < b) milieu = a + (b - a)/2 il n'y a pas ce problème.

PS: Si a et b sont entiers alors ta formule (a + b)/2.0 est incorrecte: a + b a une valeur indéfinie AVANT la conversion en flottant, il aurait fallu écrire ((double)a + b)/2.0
et personnellement je n'aime pas l'utilisation des flottants pour des calculs entiers, c'est une source de bug bien vicieux.

Tu as probablement raison, mais je me souviens d'un livre ou un algorithme prouvé 'semi formellement' avait la perle suivant:
milieu de a,b = (a+b)/2.
J'avoue que quand j'ai vu ça j'étais mort de rire..

Well, I'm afraid that it all much too technical for me but thanks for your nice comment.
I didn't know that there were new formulation of QM under research.

Plus simple a utiliser..
Peut-être mais à titre personnel (et à mon grand regret) après avoir essayé de suivre des tutoriels sur Idris, ça me reste toujours hors de portée(1)!
Donc attention à ne pas sur-vendre non plus: programmer avec des preuve formelle ça reste beaucoup plus compliqué que programmer 'normalement'..

Après ce n'est pas une critique d'Idris ou des preuves formelles.

1: ou plus exactement quand je vois les efforts nécessaire rien que pour prouver des trucs simple, je n'en vois pas l'intérêt: je ne suis pas employé par Airbus..

Et bien c'est un peu agaçant de voire des réponses où l'auteur n'a pas lu le poste..

Personnellement je ne pense pas que les gc posent vraiment problème.

Ça c'est de l'assertion! Parles en aux développeurs qui font des jeux: 60 images/sec (16ms par image), ça va les intéresser..
Personnellement je travaille sur des générateurs réseaux et l'idée d'avoir un GC qui me rajoute des latences aléatoires, beurk..

Pas étonnant:
-Le C est simple a coder car le compilateur te laisse faire n'importe quoi, à débugger par contre..

-Ocaml et les autres langages fonctionnels ont un GC, ce qui simplifie beaucoup la programmation, mais tu en paye le prix à l'exécution..

Ton poste me laisse penser que tu n'as pas bien lu ce qu'on a marqué..

Un exemple, si tu marque "let maVar = 5;" il faut choisir le type entier pour maVar (i32 maintenant), autrement tu peux imposer a l'utilisateur de spécifier toujours la taille du type mais ça devient rapidement lourd..

Toi y en a comprendre?

Tu as un lien vers ce standard ?

Je n'ai pas de lien vers un standard Rust et j'ignore si ça existe ou pas, voici la discussion sur le comportement des entiers: http://www.reddit.com/r/rust/comments/2q40k2/a_tale_of_twos_complement/
le renommage int->size a eu lieu ensuite.

Et pour ce qui est de gcc, -ftrapv est réputé comme buggé
T’as un lien là-dessus ?

Le deuxième résultat de google sur ftrapv:
http://stackoverflow.com/questions/20851061/how-to-make-gcc-ftrapv-work

Bon il ne faut pas confondre spec et implémentation, maintenant comme le comportement de Rust inclue le trap par débordement par défaut (en mode non release), logiquement cela devrait être bien tester..

Mouais, l'intérêt de standardiser un comportement indéfini me semble relativement limité

L'intérêt est que quand ça arrive, ça devient beaucoup plus simple a débugger car en C/C++ comme le compilateur est libre de faire tout ce qu'il veut s'il sait une branche de code contient un comportement indéfini et ça peut être très, très compliqué a débugger..

En Rust, avoir une valeur indéfinie et non pas le comportement du programme indéfini simplifie le debugging au prix d'une faible perte de performance.

Et j'ignore pourquoi tu parles du comportement "modulo" ça c'était avant..

PS: il y a bien sûr des entiers avec le comportement "modulo" en Rust (Wrapped je crois) mais le problème est le comportement des entiers "normaux".

Ah oui pour la séparation des algorithmes et des optimisations pour les GPU: c'est Halide

Je parle du standard de Rust,
Et pour ce qui est de gcc, -ftrapv est réputé comme buggé j'ignore le statut actuel mais ça a été le cas pendant longtemps..

comme après la V1 il ne devrait plus y avoir de d'incompatibilité, il y a eu des grands traveaux sur les entiers: int/uint en isize/usize, mais pas seulement!
Avant les entiers étaient des types ´modulo', maintenant en mode non release il y a un trap en cas de débordement (signe ou pas) et en mode release, il y a 2 possibilités: le programme s'arrête, ou contine mais le résultat du calcul a une valeur indéfinie (en général le modulo, mais pas garanti) ce qui est très different du C ou le programme est indéfini.
Personnellement j'adore ces changements..

Une vidéo montrant comment un langage pourrait aller plus loin que le C++ pour permettre la réorganisation des données en minimisant les modifications du code: https://www.youtube.com/watch?v=ZHqFrNyLlpA

J'avais vu un papier qui permettait de spécifier l'algorithme numérique de manière indépendants "des recettes" pour pouvoir optimiser du code simplement, mais j'ai perdu le lien..

Un projet de CPU (pour le moment à l'état de 'slideware') qui est très intéressant c'est l'architecture Mill.
Ce qui est très intéressant c'est la quantité d'innovation qu'ils apportent, même si ça rend le projet compliqué à comprendre (comment ça il y a deux 'instruction pointer'? et les instructions sont décodés dans les deux sens??), mais c'est du 100% propriétaire.

A l'opposé il y a le RISC-V qui a l'avantage d'être libre, mais qui a l'inconvénient d'être très, très conservateur: grosso-modo une pale copie du MIPS qui n'a même pas de 'trap on overflow' sur les instructions entières que le MIPS a..

Merci, tout ça est bien au dessus de ma tête, mais c'est intéressant.

"signed particle formulation of quantum mechanics" quelqu'un aurait-il plus d'information sur ce sujet?