Reprise du message précédent :
Flaie, va falloir que tu nous expliques comment tu fais, parce que t'es pas câblé comme nous.
Surtout quand on voit le code que tu produis, et encore, c'est pas sensé être ton langage le mieux maîtrisé.

Apparemment d'après les internet ça serait basé sur la séquence de Van Eck. Quelqu'un connait ?
https://rosettacode.org/wiki/Van_Eck_sequence

Celui d'aujourd'hui n'est pas spécifiquement compliqué, pour moi le seul trick c'était de comprendre comment consommer d'abord la liste, puis ensuite lire infiniment le last spoken (et aussi pas s'embrouiller sur la valeur à stocker).

Le code que j'ai posté c'est du code refactorisé, c'est normal qu'il soit concis, c'est pas celui qui m'a servi à soumettre la solution.
D'abord j'écris du code dégueux (deux boucles distinctes, avec 90% de copié collé), et si ça marche, je prends mes étoiles et ensuite je le rends "joli" pour les internets de l'élite

Oui j'avais bien compris que tu le faisais en 2 temps

Bon ben il s'agit bien de la séquence de Van Eck, jamais entendu parler jusqu'à aujourd'hui. Ca sert à quoi?

En prenant le code Kotlin de rosetta code et en initialisant avec mon input ça me donne bien le bon résultat.

@el_muchacho: Un petit one liner en Python: https://www.geeksforgeeks.org/progr [...] -sequence/ (voir méthode 2)

non mais j'arrive même pas faire la partie 1
 
Je ne comprends pas ce que je fais de faux la-dedans

Dion : le bouquin dont on parlait la dernière fois, j'ai réussi à avancer. Pour l'instant ça ressemble surtout à un publireportage pour GitHub

Déroule le truc à la main sur un exemple, tu comprendras vite.

par contre effectivement j'ai pas compris la partie 2...il doit manquer un 0.

Là ce que tu calcules dans ton exemple c'est le last spoken dont tu as besoin au prochain tour de boucle.

J'ai adapté le code Kotlin en Pythoin c'est très similaire sauf que je sais plus comment on cycle en python donc j'ai séparé les deux boucles que j'ai regroupées en une seule en Kotlin

Du coup je suis tombé sur cette vidéo qui explique la séquence de Van Eck https://www.youtube.com/watch?v=etM [...] umberphile j'adore le mec, on pourrait l'écouter parler des heures

intéressant le post mortem sur l'outage d'hier (version publique : la régulation automatique des quota a foirée de façon assez complexe, c'est pas juste un PgM qui a oublié de renouveller les quotas)
 
par contre la haine anti-google des gens m'inquiète toujours un peu, y'a plus rien de rationnel là dedans

C'est intéressant que parmis les trois gros Cloudeurs américains, seul Amazon ait l'air de réussir à limiter efficacement le blast radius des incidents

Y'a une haine anti tous les gros groupes.

ils ont quand meme plus souvent des zones entières down...j'ai pas de stats d'uptime, mais des pains comme il y a eu hier c'est extremement rare.
Les zones AWS qui tombent ça me parait bien plus fréquent.
 
Celui là était violent parce qu'il touchait un système ultra central et commun, ça n'arrive pas tous les jours non plus.
On ne sert pas exactement les mêmes volumes non plus

J'ai failli galérer pour la partie 2, obligé de faire tourner le code en version optimisée pour passer sous les 10 secondes... Et ma sale habitude d'utiliser les map<> de C++ pour gagner du temps était pénalisante dans ce cas.

À titre de comparaison en kotlin ça prend combien de temps à tourner ? (Perso je descends à 6.4s sur un coeur Xeon à 2.3 GHz; je soupçonne que ce n'est pas le processeur qui limite de toutes façons...)

4.67sec sur ma machine (Ryzen 3900x).
J'utilise les générateurs y'a sûrement de la perte de temps je vais voir si je peux faire descendre.
Faudrait tester sur un Apple M1.

Edit: tu as ton code ? je peux le compiler sur ma machine pour voir la diff.

# Day 15
 

Peux tu stp me faire un second et 3ème paragraphe qui ne répondent pas du tout à mon point ? J'ai besoin de texte à mettre en placeholder et je n'ai pas envie de googler lorem ipsum

 
En C++ c'est étonnant comme souvent on gagne à utiliser vector (en O(n)) plutôt que map (en O(log(n)) ou unordered_map en (en O(1)), c'est pas rien la puissance du cache CPU

oublie pas que t'as un malloc() aussi dans le tas. donc ton n log(n) peut assez vite partir en n^2

 
Ah oui c'est du même tonneau... Si tu es curieux, voilà ma solution :
 
https://code.sololearn.com/ca21a14a274a

 
En utilisant un IntArray plutot qu'une Map effectivement ça tombe à 725ms sur ma machine la partie 2, et 1ms la première.
 

 
Edit: @hephaestos ton code tourne en 18 sec chez moi, mais c'est dans WSL donc les perfs doivent pas être dinguos.

 
Ah oui pas con, on prend un peu de mémoire mais ça paie... Je descends à 1.5s
 
https://code.sololearn.com/cA22a235a17A

Rajoute un peu de const, et pour le vecteur tente de faire un reserve plutôt histoire d'éviter l’initialisation par défaut si le problème s'y prête.
vector<pair<int, int>> M;
M.reserve(N);
...
M.emplace_back(0, i);  // ou push_back

 
Il y a un communiqué quelque part ?

Vous en pensez quoi ? https://chromeisbad.com/

 
Ah non il faut l'initialiser, c'est un vecteur clairsemé (qui remplace la map précédente).
 
Par ailleurs, le temps d'initialisation des 30 millions d'entrées est de 66 ms, donc c'est pas le souci.
 
Maintenant, je suis à 40ns par itération, ça me parait pas absurde, c'est quoi, 3 cache miss ?

 
Je dirais ça oui. Pas de sort possible quelque part pour regrouper les données utiles (j'ai pas lu l'énoncé ) ? On itère souvent plus vite sur un vector trié

 
C'est à dire que je me sers de la position des éléments comme de la clé de lecture donc on ne peut pas changer leur position sans changer l'algorithme.

Ok  

edit : je viens de regarder l'énoncé, tu ne voulais pas écrire

plutôt que

ben ça répond : tu parles d'isolation :  
- AWS isole peut etre mieux, mais leur infra tombe plus souvent. Si t'es dans US-West je pense que tu t'en tapes un peu de leur isolation, ça tombe plus souvent
- google isole peut etre moins bien, mais en meme temps des outages de ce genre ça arrive super rarement
- ta comparaison implique que AWS == Google ce qui me parait pas très factuel en terme de traffic servi (même si AWS >> GCP, Google sert Google.com, Youtube, etc... sur la même infra, là où Amazon n'a qu'un gros site) donc ça met pas exactement le même stress sur les infra, et donc limite la validité de la comparaison
 
Pour le coup il y a quand meme eu un peu d'isolation, les load GCP qui tournaient déjà n'ont pas été impactées
 

non, juste ce qui a été répondu à la presse : problème sur un systeme de quota de stockage.
 

Du coup, je vais vérifier mes spams

 
Rien

En Python avec CPython, ton code tourne en 11,5s sur mon laptop (un Thinkpad T480s à basede  Intel Core i5-8250U), et avec PyPy, ça tombe à 5,2s.
Plutôt rapide, Python, aujourd'hui, franchement pas ridicule.

+1e9  

pareil, toutes ces opportunités de d'être un mystery shopper que je rate

Day 15 done en 19+8 minutes   (le temps de lire et d'ajouter 1 ligne à mon algo de la partie 1 ) : https://github.com/ratibus/adventof [...] _2.php#L23
 
Il m'a bien fallu 5 minutes pour comprendre l'énoncé de la partie 1  

Bon, j'ai eu mon annuel.
 
+5% cette année, je pense que je peux m'estimer content

Salut
 
J'essaie de comprendre la relation entre le binaire au format ELF et le mapping mémoire d'un programme. J'ai compilé mon programme sans pie pour que ce soit plus simple à analyser.
 
Segments elf en bref :

Mapping mémoire du processus :

 
Les 3 premiers segments LOAD sont chargé bien correctement en RAM aux adresse virtuelles voulues et avec les bon offsets de fichier.
 
C'est après que ça se complique.  
 
1. Le mapping mémoire suivant (0x403000-0x404000) correspond à l'offset 2000 dans le fichier, offset qui a déjà été mappé en RAM dans le segment précédent  . On dirait que le loader à chargé deux fois le même segment en RAM. J'ai fait un dump des deux zones mémoire et il y'a 2 chose bizarres.
 
La première c'est que je m'attendais à ce que, tel que la table des segments l'indique, seul les premiers 0x180 octets de données soient utilisés, le reste étant à 0. Or l'offset 0xe10 à 0xf90 contient dans les deux zone mémoire des données additionnelles qui divergent entre les deux mapping le reste des données étant identique.  
 
Pourquoi donc ce double mapping et quelles sont les informations additionnelles présentes dans les 2 mappings ?
 
2. Enfin le dernier mapping effectué (0x404000-0x405000), qui contient les globales du programmes, correspond à un offset dans le fichier (3000) qui n'est nulle part indiqué dans les segments. La section .data dans les "sections header" correspond bien à l'offset 0x3020 et à l'adresse 0x404020, le mapping semble donc juste.
 
Cependant la partie " Section to Segment mapping:" nous indique que le 5eme segment, qui aurait du être mappé dans le range 0x403000-0x404000, contient la section .data avec un offset de fichier à 0x02e10.  
 
Pourquoi donc les informations contenues dans le dernier segment ne correspondent pas aux information contenues dans les "sections header"? Je croyais que loader utilisait uniquement les segments pour charger et protéger les poritions du fichier en RAM, les "sections header" étant utilisé uniquement pour le debug?
 
Le full code

par les temps qui courent c'est plutôt très bien ça