Reprise du message précédent :

from operator import itemgetter
m = min(enumerate(map(lambda bus: bus - (departure % bus), buses)), key=itemgetter(1))
print(m[1], m[0], m[1] * buses[m[0]])

Généralement on utilise `map` quand on a déjà une fonction qui fait le boulot à lui donner, sinon une gencomp va tendre à être plus courte, claire, et rapide:

from operator import itemgetter
m = min(enumerate(bus - (departure % bus) for bus in buses), key=itemgetter(1))
print(m[1], m[0], m[1] * buses[m[0]])

Betamax vs VHS. Pas le meilleur qui gagne mais le plus simple à utiliser et qui nécessite le moins d'effort côté soft Pour Apple c'est simple ya la maîtrise de bout en bout, pour le reste autour c'est autre chose.

En tout cas tant que tu aura pas un équivalent Intel pour ARM (AWS a aucun intérêt à sortir ça en dehors de chez eux, Apple c'est le Desktop, Nuvia trop petit et jeune). Mais comme le business d'ARM c'est pas le silicium mais la PI, ça va pas arriver demain. Cf encore mon article.

Je ne suis pas trop votre discussion là, je n'y connais rien... C'est quoi concrètement la complexité d'ARM ? Qui s'en soucie (ou devrait) ?

Les "concepteurs d'OS" comme Plam

from operator import itemgetter
m = min(enumerate(bus - (departure % bus) for bus in buses), key=itemgetter(1))
print(m[1], m[0], m[1] * buses[m[0]])

   
Effectivement, j'ai vérifié, c'est un chouilla plus rapide.

 
 
https://www.nickwilcox.com/blog/arm [...] ory_model/
 
Concrètement la plupart des applications s'en foutent car elle utilisent des mutex/sémaphores pour assurer le synchronisation entre 2 threads ce qui règle le problème. Pour les cas plus tricky (lockless synchronisation) il faut rajouter des barrières mémoire.

Alors je gagne ma vie grâce au C et à l'assembleur
Il faudrait que je me (re)mette au C++, que j'ai pas pratiqué depuis que je ne suis plus étudiant, mais c'est pas les projets-hobbies qui me manquent sur ce thème (RPi baremetal et Arduino). Et je sais déjà que je vais me retrouver à faire du C plus que du C++ en faisant AoC avec
 
L'idée c'est de m'essayer avec des langages un peu plus évolués et qui sont embarquables et de voir à quel point ils sont aboutis. J'ai pas mis Java car ça va être la misère avec la toolchain pour le seul MCU que j'ai qui irait. Micropython me fait de l'œil. Mais quand j'ai fait du Python sur PC pour bricoler vite fait un outil au boulot je me suis retrouvé à cheval entre du Python2 et du Python3 et j'ai trouvé ça insupportable
 
J'ai mis Lua car j'ai pu torcher un projet perso en 2 coups de cuiller à pot pour faire un genre de MQTT before it was cool avec NodeMCU, mais pas sûr que je puisse en faire avec autant de cibles que Micropython.
 
Embedded Rust ça fait quelques temps que je lorgne dessus, mais je vois pas de BSP pour les cartes que j'ai, donc standby.
 
Reste le debug effectivement. Pour Micropython ça a l'air mort, j'imagine qu'il faut exécuter le programme à la main dans l'interpréteur ?

ARM, c'est un CPU RISC contrairement aux CPU x86 qui sont du CISC. Du coup, le jeu d'instructions est plus simple mais de ce que je comprends des débats, y'a des mécanismes qui ne sont pas implémentés dans ARM qui le sont dans x86 et du coup, c'est au dév de devoir les implémenter, donc le grain de perfs côté ARM face au x86, tu le perds en coût de dév.

Rufo non, pas du tout, le modèle de mémoire est plus moins orthogonal au jeu d’instruction.
 

Certes, mais eux ils ne choisissent pas sur quoi ils tournent, plus ou moins par définition, si ?
Du coup c'est qui ces utilisateurs qui ne devraient pas se risquer à l'ARM parce que c'est plus compliqué ? Ou parce que ça risque de ne pas avoir le même comportement en prod qu'en dev (duh?)?

2 videos qui m'ont aidé à comprendre le théorème des restes chinois :
https://www.youtube.com/watch?v=zIFehsBHB8o
https://www.youtube.com/watch?v=ru7mWZJlRQg
 
Du coup j'ai implémenté ça pour la partie 2 aujourd'hui : https://github.com/ratibus/adventof [...] heorem.php
J'ai pas compté le temps précisément mais on est à au moins 2h pour lire et comprendre le théorème, ensuite l'implémentation a été "rapide" (30 minutes ).
 
Ca tourne vite

 
La première version de ma partie 2 mais qui ne scale pas : https://github.com/ratibus/adventof [...] olve_2.php
 
C'est cool en tout cas, on apprend des choses et je vais pouvoir apprendre à ma fille à optimiser ses horaires de prise de bus

C'est pas du tout une question de jeu d'instructions, c'est une question de modèle mémoire (ordre de visibilité des opérations entre les threads).
 
Ça a tellement aucun rapport avec le jeu d'instruction que sur le M1 Apple a un mode TSO pour faciliter l'émulation x86, et RISC-V a une extension TSO.

J'ai un peu simplifié, désolé. Par jeu d'instructions, j'entendais les instructions mais aussi toute l'architecture du CPU pipeline, décodage des instructions, gestion de la mémoire...).
Le x86 a beaucoup plus d'instructions que l'ARM et en plus, elles n'ont pas toute la même taille, d'où une complexité de décodage plus importante sur x86.

tu es sûr de ton contre exemple là??    si 20 est la soluce, 21 serait un multiple de 4 et 22 un multiple de 6... sauf erreur ce n'est pas le cas. et d'ailleurs pour moi tu ne peux pas avoir 2 id de bus pair consécutifs, car aucuns de leurs multiples ne seraient consécutifs...

C’est pas le sujet, ça n’importe que dur les micro-opts et c’est principalement à l’avantage d’arm (et devoir LDR avant ton ADD parce que t’as pas d’adressage indirect ça casse pas trois pattes à un canard). Le problème dont on parle est https://preshing.com/20121019/this- [...] dered-cpu/

Non, j'ai merdé.
Je réessaie:
x,4,x,x,x,6,x,13
La bonne réponse est 19 :
t+1 = 20 (4 part)
t+5 =  24 (6 part)
t+7 = 26 (13 part)

Donc pour être impacté, il faut 1. écrire ses propres mutex, et 2. pas correctement ???

Oui et non, le problème c’est principalement que du code peut marcher sous x86, et être subtilement buggé sous arm. Techniquement le code a jamais été correct mais ça rend pas des race conditions super bas niveau pots faciles à debugger, et si t’as pas une machine arm pour faire ton debugging t’as vraiment aucune chance.
 
L’essai le note d’ailleurs:
 

Ah ok, je vois, merci pour l'article. Donc dans certains cas, certaines libs/instructions, uns fois compilées pour de l'ARM risquent de ne plus fonctionner comme elles devraient et donc créer des bugs qu'on aurait pas en x86. Ca fait donc partie de ce que j'appelais "certains mécanismes" qui existent en x86 et pas sur ARM (ici, le réarrangement de la mémoire), non ?

mon code renvoie bien 19    (en ayant juste modifié ma ligne "inc = bus_ids[0][0]" en inc = 1 parce que le premier élément du tableau est "x"...)
il itère de 1 en 1 jusqu'à 7, puis de 6 en 6 donc 13, 19 et à 19 ça matche.

En patient de hacks : t'as trouvé un moyen de transférer les hacks d'un os à l'autre ? Je viens d'upgrader en os rare, mais impossible de transférer ping et autres.
Idem pour les mods de fringues.

Je crois qu'on peut pas les retirer. J'ai pas creusé, j'en ai tellement qu'à chaque fois j'en ai mis des nouveau.

D'ailleurs, l'up du cyberdeck dès le début, il fait plaisir quand tu hack souvent. Ping pour voir tous les trucs à hack + enemies, tu charges un daemon pour désactiver toutes les caméras et c'est ez mode

Vu que j'ai du rembourser ma dette, plus attendre de chopper 35000 Eddies ça a pris un peu de temps.
Mon kif du moment c'est le Snipe qui charge, j'ai fait un headshot critique a 1350hp
Je viens aussi de chopper un pompe avec un chargeur, du coup il se recharge hyper vite, c'est très violent.

Du coup faut que je retourne acheter certains daemons

 
Ça répond pas à la question prioritaire : est ce que vous êtes déjà allés aux putes ?

Bien sur (in game, je précise).

Day, done.  
Retour à du moins matheux

T'as trouvé un mask qui évite de faire de la manip de string comme un gros dégueu ?

Non mais c'est parce que tu l'initialises à 1, mais 1 n'est pas une solution pour le premier bus. Tu devrais l'initialiser à 3 avec un incrément de 4, pour que ce soit cohérent.
 
À ce moment là, il va aller de 1 en 1 jusqu'à 3, puis de 4 en 4 jusqu'à 7, puis de 24 en 24 en sautant 19.
 
Dit autrement, l'algorithme ne marche pas si on a:
 
3,4,x,x,x,6,x,13

#2 gros sac à boucles avec des manips de tableaux de caractères, c'est très sale
 
même Flaie t'as pas un truc sexy pour le #2 ?

En Kotlin/PHP/Python avec un générateur c'est relativement sexy (ou Ruby's Fiber).
 
J'avais codé ça avec en recursif avec une liste d'adresses en paramètres que je remplissais, mais c'est plus joli avec un générateur.  
Copyright twitter où j'ai vu passer l'idée tout à l'heure, sur le coup j'y ai pas pensé.  
C'est marrant en Python je les utilises souvent, en Kotlin j'y pense encore jamais

 
Oui (en gros t'as une mini lap dance et une vue genre film erotique, et voilà). Ça casse pas 3 pattes à un canard mais c'est rigolo une fois.
 
J'ai passé ma journée hier à faire les side missions pour faire de l'argent, ça avance bien (dans ce genre de jeu j'aime bien me booster à coté, sinon les missions de l'arc principal peuvent devenir assez difficiles)
J'en chie avec les missions "beat on the brat" : je dois pas avoir les bonnes stats, je prend 4 coups et je tombe alors que je mets 10 coups aux jumeaux et je leur enlève max 10% de leur vie
 
 

installé hier, il est vraiment bien ( la 1080ti souffre un peu )

 
En effet il pense vite le type !

 
c'est pas si moche vu d'ici...j'étais parti pour générer la liste d'adresses sous forme d'arbre mais finalement c'était trop simple de juste concaténer des string...

 
je confirme
 
5950X plus en stock, 3080 plus en stock, heureusement que je peux jouer en 1080p

T'avais pas dit que tu en avais trouvé dispo, des 5950X en Suisse ?

si, le temps que je passe la commande y'en avait plus
y'a plus rien nulle part
 
c'est pas grave, j'attends. Au pire la 3080ti sortira d'ici là

 
https://www.platformonomics.com/202 [...] home-game/  

Kenshineuh t'as dis que c'était easy