Reprise du message précédent :
http://www.mondaynote.com/2014/08/ [...] d-is-nigh/

 
C'est sur que ça pend au nez d'Intel. M'enfin ils vont pas se laisser faire.

 
c'est quoi la perf monothread d'un bon arm vs un bon x86 ? parce que bon, sur de l'utilisation desktop courante (qui est le problème dont on parle ici), la perf monocore joue encore un role central, y'a encore plein d'applis qui gèrent pas ou mal le multithreading (tout le monde fait pas du zip d'archive de 3TB pour prouver quer le multicore tabasse).
 
Je suis pas sur que les gens sont prêts à échanger une perte de perf contre du gain de batterie

pour des trucs genre C720 ca a bien marche mais c'est pas le meme marche

Pour la plupart des gens, je pense que si. La preuve c'est que les trucs genre Macbook Air avec des Haswell U anémiques se vendent bien.
 
Maintenant cet article est un bon ramassis de conneries:
- Intel explose n'importe quel SoC ARM en perf/Watt depuis un moment.
- Dans un laptop, c'est pas le CPU qui consomme le plus. De loin.
 
Là où il a raison, c'est au niveau du prix. Mais Intel va probablement pas arrêter de brader les Atom de si tôt.
Donc techniquement Apple n'aurait aucune raison de sortir un Macbook Air ARM, mais vu qu'ils ont l'IP, pourquoi pas.

Source ? et je parle de vrais tests, pas ceux faits par les marketeux d'Intel qui comparent du code ultra spécifique, écrit à la main en assembleur optimisé au petits oignons avec SSE3/AVX comparé à du ARM écrit en C pas optimisé compilé en mode debug.
 

Il y a quoi qui consomme plus à part l'écran ? le GPU peut potentiellement consommer plus, mais à part dans les jeux il n'est pas trop utilisé, les chipsets wifi ont été bien améliorés ces dernières années et consomment très peu. Les SSD consomment quasiment rien en Idle, et consomment juste 1 ou 2 watt mais c'est lors de débits très soutenus (500mo/s, donc pas longtemps)

http://www.microsoft.com/en-us/discover/1994/

edit: pour les lapins -> http://blogs.microsoft.com/firehos [...] -20-years/

pour les cookies clickers: http://particle-clicker.web.cern.ch/particle-clicker/

enfin il y a un ordre de grandeur entre les perfs ARM et x86 . Ceci dit il y a deja un fabriquant qui a fait le saut : microsoft. Win8 tourne sur ARM et sur x86. Le principal problème remonté : pourquoi on ne peut rien installer  ?  
Quand à la conso : ca a quand même un impact : l'arrivée de haswell a juste rajouté dans les 50% d'autonomie à tous les portabmes

après tout y'a surement un marché pour ça (encore qu'entre une bonne tablette et un laptop "performant", la zone est mince), moi je dis rien tant qu'on continuera à avoir du matos pour que ça aille vite si besoin (jeu, retouche photo, etc...)

Un mode d'emploi aurait été le bienvenu.

Je ne comprends pas à quoi sert la réputation. Je n'ai pas l'impression que ça change quoi que ce soit.

Des fois j'achète un upgrade marqué Because your science is so popular, you get 1.1 times more money for your reputation."" ... mais je ne gagne rien de plus, ni en auto, ni au click.

Edit: En fait ça augmente le funding par seconde. Sauf que ce n'est pas toujours visible.

http://en.wikipedia.org/wiki/List_ [...] hitectures
 
Et on notera qu'il n'y a plus de Surface (juste Pro) et que c'était pas Win8, à ce compte là Apple a fait le saut en 2007.

sauf que c'est pas une question de jeu d'instruction, mais de choix dans la conception du processeur ( performances high cost vs low-power low-cost) et de moyens/budget dans la R&D.  
Un ARM64 peu très faire aussi bien qu'un x86 au niveau performance. Il faut juste s'en donner les moyens et justement Apple a les moyens de le faire.
 
Et c'est un énorme moyen de pression d'Apple sur les prix d'Intel: vendez nous vos x86 pas trop cher sinon on fera nos processeur haute performance nous même.

wesh, topic d'expert. Quelle biographie de Mitterand vous conseillez? En general je prefere les autobiographie mais "Mémoires interrompus" me semble plus reflexion qu'historique.
 
 merci

La surface 2 est sortie en fevrier est en ARM . Mais effectivement, pas sur qu'il y a une s3. LA différence entre win8 RT et win8 Est la compilation. Sinon, les fonctionnalités sont quasi identiques ( a part quelques fonctionnalités legacy non portées).
 
 
Pour apple, je crois plus à la cannibalisation des mba pas un ipad boosté progressivement. (écran plus gros, clavier, détachable, de plus en plus d'appli de productivité , ...) .  

Clover Trail en 32 nm faisait déjà mieux que les SoC ARM de l'époque:
http://www.anandtech.com/show/6529 [...] r-analysis
http://www.anandtech.com/show/6536 [...] l-showdown
http://www.tomshardware.com/review [...] ,3387.html
 
Et aujourd'hui Bay Trail est beaucoup plus performant que Clover Trail.

Faut réfléchir en consommation moyenne lors de l'utilisation typique, par rapport aux composants dont la consommation est relativement incompressible, principalement l'écran en effet.
Dans un ultrabook, diviser le TDP par deux avec un CPU qui va mettre deux fois plus de temps pour finir les mêmes tâches, ça va faire diminuer l'autonomie.
Au passage, un GPU dédié dans un laptop c'est bientôt un concept du passé, ça sera fini avec Broadwell.
 
Et au delà de 15 W de TDP on est encore dans la science-fiction. On a aucune idée des perfs d'un ARM dans ce genre de configuration. Et surtout le process haut-performance d'Intel n'a pas de compétition.

 
Quelqu'un pourrait-il m'éclairer ?
 
j'avais ça comme prises :
 

 
J'ai pluggé une parafoudre sur le nas. Now la prise 2 marche plus, ras sur la 1  

Ptêt que le câblage c'est
1 - rien
3 - nesprelol
2 - nas
et quand t'as branché le paratruc ça a défoncé la prise
si tu le vires, 2 remarche ?

Ptin, bien vu, gg l'ancien proprio électricien
 
Et le problème, c'était en fait la 3 qui avait perdu un fil, prise branlante inside

Ce sera pas plus fini qu'avec Haswell.

On verra.

Je viens de me souvenir par hasard qu'il fut un temps, j'avais un compte AdSense... Je viens d'aller voir, et après longue recherche de mot de passe, j'ai fini par réussir à me connecter ... Y'a 69.75€ dessus (qui dorment dessus depuis des années sans doute Et qui ne rapporte plus rien depuis longtemps, le site sur lequel était la pub n'existe plus...
 
... Le pallier de paiement est à 70€, c'est ballot

 
ça me parait pas ballot au contraire bien joué google !

http://www.theguardian.com/technol [...] isco-penis

dites j'ai un petit soucis de modélisation. Je fais un parseur d'exif en python dans le but de faire un scanner de librairies pour faire des stats, etc...
ça supporte plusieurs formats d'image, qui n'ont donc pas tous la meme structure.
Selon le type de fichiers, j'ai des taches différentes à faire, sachant que certaines sont communes entre plusieurs type de fichiers (marquées en couleurs dans mon exemple). Après chaque IFD offset, les IFD sont structurés pareils, mais les tags dedans peuvent etre propre au format de fichier

J'ai représenter à la louche les éléments à parser selon les types de fichier, avec des codes couleurs pour montrer les éléments qui peuvent etre traités de façon commune

on voit que selon les types de fichiers :
- les taches à faires ne sont pas tout à fait les memes
- il y a des taches communes
- certaines taches communes demandent une vérification spécifique (par ex le marker TIFF qui vaut 42 ou RO, est tjs au meme endroit, et se lit selon le byte order mark)

j'ai pensé utiliser un design pattern command, en modélisant les taches ci-dessus comme des commandes que je peux rajouter dans une todo list, mais le truc c'est que j'ai besoin du résultat de certaines commandes pour faire les suivantes (eg : il me faut la BoM pour savoir comment lire la suite du fichier).
Je pensais contourner ça en faisant que les commandes puissent se décorer (pour pouvoir récupérer les résultats des commandes précédentes), ou alors en passant self à chaque commande, de sorte que les command puissent modifier des valeurs de la classe appelante, genre ça

class Parser:
    def __init__(self):
        self.BOM = None
        self.commands = []
 
    def add_command(self, command):
        self.commands.append(command)
 
    def parse(self):
        for c in self.commands:
            c.execute(self)
 
class Command:
    def __init__(self, parser):
        self.parser = parser
 
class parseBoM(Command):
    #calcul de la BOM
    self.parser.BOM = "little"
 
class parseTIFFMarker(Command):
    pass

Ajoutons à tout ça que je parse un fichier, et que le mieux est de le faire le plus séquentiellement possible, pour éviter des seek dans tous les sens

vous feriez ça comment ?

Si tu as envie de faire qq chose de propre, je dirais que tu peux traiter ton parser comme une machine d'états finie (d'ailleurs un parser en est une). Plutôt qu'un pattern command, j'utiliserais un automate d'états et je traiterais le problème sur le papier dans un premier temps, en définissant les états-transitions. Une fois ce travail fait, l'implémentation coule de source.

http://python-3-patterns-idioms-te [...] chine.html

https://github.com/oxplot/fysom

merci je vais regarder ça
 
j'ai regardé, j'ai meme commencé à modéliser la machine (et je me suis souvenu que j'étais une merde en modélisation ).
 
C'est ce que je voulais, mais je crains une chose : y'a potentiellement une vingtaine de format d'image, chacun avec sa petite spécificité. J'ai peur qu'au final la state machine devienne hyper complexe, et dure à modifier / étendre. Je soupçonne aussi que je devrais fréquemment modifier le truc au fur et à mesure de mes découvertes et du rajout de formats (le standard jpeg est dévoyé au possible, par ex le standard exif dit qu'un jpeg exif ne doit pas contenir de marker app0 (JFIF), pour autant j'ai trouvé des jpeg où c'est le cas. T'as aussi des cas où y'a plusieurs app markers avec le meme numéro au sein d'un fichier ce qui n'est théoriquement pas possible selon la spec.
je pense que le problème vient du fait que ça reste des formats différents. Par exemple tu écrirais pas un parseur de csv et un parser XML dans le meme parser, même si potentiellement tu peux être amené à faire la meme chose dans certain cas.
 
disons qu'une implémentation hyper naive du truc, ce serait d'avoir 20 parsers, qui font chacun leur truc.
Le premier refactoring serait de mutualiser les taches communes dans des méthodes réutilisables, mais je dois continuer à décrire quelque part l'enchainement des taches.

Je ne connais pas Python, mais l'héritage de classe doit te permettre de masquer une partie de la complexité en la déléguant à une classe/type.

tain c'est un bordel ce truc...
un app marker contient 1 à n IFD
chaque IFD contient 1 à N tags
le contenu du tag est dans l'IFD si il fait moins de 4 bytes, sinon le contenu devient l'offset où aller chercher la valeur (qui peut donc etre hors de l'IFD).
tu peux donc pas te dire : cool, je prends mes IFD, et je joue dedans, il te faut toujours la main sur le fichier...
 
du coup je pense que je vais le coder dégueulasse une fois pour chaque parser, je refactorerai après quand j'aurais les idées claires sur ce qui est mutualisable
 

oui clairement, chaque classe connait sa liste d'actions à faire...mais là je me bats avec l'imbrication des taches.
En gros les mecs ont été radins sur les bytes de marquage, donc en gros tu peux pas découper ton fichier en bloc et jouer dans les blocs, tu dois avoir la main dessus pour te balader partout dedans, c'est un jeu de piste

Bordel, on peut utiliser des regexp dans les contraintes CHECK de postgre   . Plus jamais je touche à du MySQL volontairement.

C'est ce que j'allais te recommander. C'est bourrin mais ça a des avantages: 1) c'est plus simple car les machines d'état sont simplifiées. Tu te fais la main avec des formats simples et au fur et à mesure, tu t'attaques à des formats plus tordus, 2) si tu te bananes, tu ne flingues qu'un format de fichier, pas tous en même temps, et ça t'évite d'avoir à retester tous les formats à chaque changement, 3) il faut que chaque format soit une implémentation stricte de sa spec. Tu ne veux pas une machine d'état dont certains noeuds n'ont rien à voir avec le format à implémenter, mais appartiennent à un autre format, sous prétexte de mutualisation. Sinon bonjour la maintenance dans le futur.

je sens que ça va merder ...

je rattrape mon retard GoT, je viens de finir l'épisode S03E07, j'attaque le 8 c'est le S03E09 qui est le fameux épisode super violent ?

Probablement.

je sais plus si j'ai vu la s03 ou si c'est la s02 ?  
y'a une s4 en court  ?

 
c'est parti  

Elle est finite, s04e10 a été diffusé le 15 Juin.

\o/ j'ai vaincu !

>>> b'Canon\x00'
>>>b'Canon EOS 5D Mark III\x00'

plus qu'à refactorer pour industrialiser le bordel.

J'aimerais bien avoir les gars qui ont écrit la spec JPEG, la spec EXIF et la spec TIFF6.0 pour leur dire ma façon de penser sur leur doc de merde... c'est ambigu au possible, et donc je suis pas surpris que les gens qui ont fait des implémentations concrêtes ont fait n'importe quoi.

yep
on en est au s0403 ici

mouai... bof... juste des meurtres et du sang comme depuis le début quoi...

oui il n'est pas aussi exceptionnel qu'on le dit