Nicolas Boulay a écrit 16122 commentaires

Normalement, c'est l'employé qui peut se plaindre, l'inspection du travail, ou les syndicats.

Je connais des boites clientes qui refusent explicitement de l'autoriser. Officiellement, pour des raisons de légalité mais souvent pour empêcher la hausse des salaires.

"La première sécurité est la liberté"

C'est sûr, Jacques Lang n'aurait pas proposé un truc équivalent. C'est pas comme si le PS n'avait pas voté _pour_ au sénat.

"La première sécurité est la liberté"

Je suis d'accord avec toi. Mais cela n'empèche pas de se rappeler à leur bon souvenirs lors des élections. Qu'ils se rendent compte que ce n'est pas l'Élysée qui les élisent.

"La première sécurité est la liberté"

La première chose à faire et de trouver le nom des 16 députés UMP qui ont voté cette loi.

Sur pcinpact, on a les noms des votant non, mais pas les pour.

"La première sécurité est la liberté"

Je pense que l'impossibilité technique était la régulation de débit visant uniquement internet. Du point de vue du FAI, tout passe par le même lien.

"La première sécurité est la liberté"

Croire qu'un dsp ou autre peut être plus rapide qu'une implémentation purement hw est assez rigolo :)

Mais ne t'inquiète pas il y a souvent quelqu'un pour proposer d'utiliser un cpu sur la carte graphique.

"La première sécurité est la liberté"

Tu oublies aussi le biai imposé sur les moteurs de recherche pour les sites avec tampon "musique légal"...

"La première sécurité est la liberté"

L'ordre est définit même sans parenthèse.

a=b+c+d+e+f;

c'est a=((((b+c)+d)+e)+f);

"La première sécurité est la liberté"

Disons que c'est la personne qui test qui décide. Je voulais aussi faire un truc rapide.

Faire une campagne de test complet demande du matos vierge, et un temps fou. Là, c'est plus rapide, mais il faut maitriser l'environnement pour comparer.

"La première sécurité est la liberté"

Quant à n'être pas loin de 100% sur x86, n'est-ce pas simplement parce qu'il n'y a pas de traduction du tout et que le code userspace est exécuté nativement ?

Je ne crois pas. La traduction se fait toujours à la volé mais avec du 1 pour 1 la plus part du temps.

Ce qui doit tuer les perfs, c'est le fait de ne pas connaitre le type à la compile, tu es donc obliger de faire des vérifications et plusieurs chemins de calcul possible.

"La première sécurité est la liberté"

C'est le prix d'une carte de développement.

"La première sécurité est la liberté"

Dans l'embarqué, les solutions sont de toute façons de plus en plus intégrées (type OMAP/PowerVR), une puce graphique à part n'est pas appropriée !

C'est ce que je croyais aussi. (J'ai bossé sur le 3430). Puis j'ai entendu parler de bench du core 3D par rapport à du pure soft fait sur l'ARM. Ces puces sont tellement memory bound que le core 3d n'apporte rien en perf, en tout cas sur les cas simples.

Donc une petite puce 3D, avec sa propre mémoire accessible par le bus externe peut tout à fait exister.

Le marché existe. Nvidia/ati font la course à la puissance et aux fonctionnalités. Il s'intéresse moins à l'intégration des drivers (gestion multiécran, gestion d'énergie) ou à la stabilité.

Nouveau aura toujours un metro de retard sur les sorties des cartes. Pour ATI ,j'attende de voir qq choses de concret. J'ai trop été deçu avec eux lors des ATI 8500 qui ont été ensuite fermé.

"La première sécurité est la liberté"

Le FPGA c'est pour le développement. La carte aura moins de fonctionnalité que les carte ati/nvidia du point de vue accélération HW mais sera rapide. Plus je pense que les cartes bas de gamme actuelle.

Le prix visé est 100$.

"La première sécurité est la liberté"

J'avais vu ce genre de test. Je voulais vraiment avoir un test avec un bloc de 1 octets seulement.

Je suis d'accord que je teste plus que la vitesse du SSD. Mais si le sous-système disque du kernel est mauvais le SSD ne sert à rien.

L'intéret d'utiliser un fichier de vouloir faire ce que l'on veut.

Si on veut tester un disque en raw, on peut attaquer directement /dev/sd??

Ou encore, on peut tester avec des remplissages progressifs du disque.

Et surtout on peut tester, sans vider son disque actuel.

"La première sécurité est la liberté"

Le plus complexe lors de l'écriture d'un bench est de savoir très exactement ce que tu benches.

Pour s'y retrouver et ne pas être dans un cas encore plus éloigné de la réalité, je suis rester simple : un lseek64+un write et rien d'autre.

J'ai choisi de ne pas utiliser le fwrite() qui rajoute encore une couche de buffer.

Toute la chaines influence les résultats : le kernel avec sa couche vfs et son cache, le scheduler io,le système de fichier, le controleur hw, et finalement la mémoire de masse.

Si on veut des testes reproductibles, il faut spécifier l'état du système. On peut rajouter une lecture de l'état du scheduler ou le taux de remplissage du disque.

"La première sécurité est la liberté"

$ wio lataillequetuveux leNomDeFichierQueTuVeux.avecUneExtensionSiTuVeux

:)

C'est bien un bench. A priori, un pire cas pour les SSD.

"La première sécurité est la liberté"

Non, cela serait une erreur. Les ios disques continue en arrière plan. De plus le lseek peut prendre aussi du temps. Je considère le temps passé dans les quelques calculs de la boucle sont complètement négligeable devant les IOs.

Un get_tick doit prendre 32 cycles...

"La première sécurité est la liberté"

Oui. C'est le pire cas qui est intéressant et le cas moyen.

"La première sécurité est la liberté"

Il y a une autre explication. Dans un but de clareté, j'ai coupé à 2 chiffres après la virgule.

Si tu as un gros système RAID, les données remplissent des caches. Ensuite, il faut tout vider, ce qui peut être très long.

Vu que cela touche le min et la moyenne, je penche pour une IO qui dure très longtemps. Genre 100s. Cela explique un chiffre comme 0.001 io/s. Et cela explique que la moyenne aussi soit touché.

"La première sécurité est la liberté"

Cela sent le bug. 0.0 est impossible, c'est le nombre io/s, je fais 1000 io et je divise le temps pris par la fréquence.

En tout cas, c'est une machine de cinglé ton truc pour avoir des chiffres pareil. C'est un SSD intel ?

"La première sécurité est la liberté"

Tu n'as pas de carte 3D intel par exemple. Il y a aussi le marché de l'embarqué.

"La première sécurité est la liberté"

Le moteur 3D HW ne sera pas libre. Pas tant que les créateurs seront rentrés dans leur frais.

Il y a trop de risque de se faire doubler par des chinois avant que la boite ai suffisamment de cache pour vivre.

"La première sécurité est la liberté"

Le projet a commencé il y a longtemps.

L'idée est de faire une carte qui "suffit" pour de la bureautique (et les jeux du type de ceux que l'on trouver sous Linux). Elle sera rapide pour tout ce qui est "fonction fixe".

L'intérêt est ailleurs : dans la stabilité des drivers (plus de plantage à cause de la 3D), la qualité de la sortie vidéo,...

"La première sécurité est la liberté"

C'est curieux de vouloir comparer la vitesse de l'interpréteur Python avec qemu qui n'est pas loin de la vitesse de 100% sur x86. La vitesse de python est connu pour être faible ;)

Le problème de cache est très théorique. Pour un seul bytecode, combien d'instruction à exécuter avec le dispatch ?

"La première sécurité est la liberté"

Qu'est-ce que tu n'as pas compris dans la phrase : un label permettant aux usagers de ce service d’identifier clairement le caractère légal de ces offres ?

"La première sécurité est la liberté"