Bonjour,
Pour ce mois d’août, pas de pression, juste du fun ! L’idée serait de ne pas passer trop de temps à parvenir à une solution mais que cela émoustille un peu les neurones quand même…
Je vous propose d’afficher simplement l’heure et la date du PC en chiffres romains sur la face-avant. Cela avec l’heure en temps réel secondes comprises.
Par exemple :
Le 31/07/2013 à 14:26:29 donnerait
XXXI/VII/MMXIII
XIV:XXVI:XXIX
Pour départager les résultats, le vainqueur sera celui dont l’utilisation en mémoire du VI est la plus petite dans l’outil Profil >> performances et mémoire (tous les VIs lancés à la même heure).
Le gagnant aura une certification de son choix offerte.
Comme toujours, pas de DLL encapsulées, juste des VIs de la bibliothèque. Retour du code dans un fichier ZIP avec votre pseudo dans le Main
Pour que tous partent sur la même base d’affichage, je fournis la face-avant.
Je serais en congés jusqu’au 26 août et je ne pourrais pas toujours répondre d’ici là, mais vous pouvez m’envoyer vos codes (emmanuel.roset@ni.com), j’ai hâte de voir les solutions
Bon courage !
Emmanuel
Précision au 02/08/2013
Il est possible de s'arrêter à l'année 2059 dans l'affichage de la date en temps réel sur la face-avant.
La date peut être amenée à bouger en fonction de la source temporelle jusqu'à la date de 2059
Comme il n'y a pas de saisie manuelle du temps sur la face-avant, la synchronisation provient forcément du PC, d'un service serveur de temps ou autre...
Précision règles au 12/08/2013
Il n'est pas utile de mettre une boucle While et un bouton stop autour de votre code car il sera lancé par un noeud de méthode dans un programme bench et lu avec l'outil de profil et performances
Pour les codes que j'ai déjà reçus pas de soucis, je retirerai la boucle While pour le test.
En ce qui concerne le passage par zéro de l'heure, il faudrait ajouter un caractère 0 plutôt que de laisser vide le caractère afin que tous les programmes soient identiques.
En effet suite à un premier bench cela ce joue à 100 octets près pour les premiers et avec des méthodes complètement différentes ! et chaque caractère et choix de fonction compte
Précision au 13/08/2013
Aujourd'hui vous êtes 7 à optimiser vos codes pour descendre en dessous des 5k voir ...
Cependant comme précisé dans un post du 13/08, le découpage en Sous-VI ne rapportera pas en espérant libérer l'utilisation mémoire du Main à presque zéro...car la règle est que je vais additionner l'utilisation mémoire du main et des Sous-VI au total.
Donc cela peut rapporter un peu avec des Sous-VI réutilisés, mais pas tant que cela, voir faire pire. Cela ne concerne presque personne mais c'est juste au cas où.
Je confirme déjà par rapport aux codes reçus, qu'un seul VI est largement plus rentable dans ce cas.
je suis très impressionné par les choix de codage et vous serez surement intéressé de regarder les solutions des autres au final.
Résulats au 02/09/2013
Le temps est venu de dévoiler les résultats du challenge du mois d’août.
Une lutte acharnée c’est déroulée pendant l’été. Ce petit challenge romain finalement a été réalisé rapidement,en tout cas dans un premier temps.
Puis certains sont revenus sur leur programme et m’ont envoyé de nouvelles versions optimisées pour qu’il utilise le moins de mémoire possible.
Chaque jour les valeurs descendaient et un nouveau vainqueur possible se présentait. Quelque 14 personnes ont proposés des codes régulièrement.
Arrive le mois de septembre. Vérification de la conformité des codes... Puis pour départager les résultats, j’ai effectué des lancements successifs de tous les codes ensemble pour avoir une tendance.
Puis uniquement sur les 3 premiers pour éviter tous problèmes de chargement et avoir exactement la même heure affichée.
Je félicite donc Mathieu_R qui se détache vraiment avec un résultat autour des 2450 octets et a ainsi gagné une certification de son choix.
Je remercie vivement tous les participants qui ont activement contribués à réaliser des codes toujours plus optimisés à l’octet prêt.
Je vous invite à regarder les méthodes et solutions de chacun qui recèlent pas mal d’astuces.
Résultats totaux :
Vérification sur les quatre finalistes :
A bientôt pour de nouvelles aventures !
Emmanuel
Mise à jour au 18/09
Juste pour rappel, j'ai ajouté en lien tous les programmes des participants nommé : Tous les programmes et bench version LV 2010.zip
cela permet de voir les astuces utilisées par chacun. Ainsi que celui de sébastienM
Bonjour Emmanuel
Y-aura-t'il un changement d'année ?
Sans coder forcément en dur, est-ce qu'on peut se limiter à 2000-2059 ? (histoire de ne convertir que des chiffres entre 0 et 59 )
Nico
Bien vu, j'attendais la question . Alors oui en effet on peut s'arrêter à 59. Tous les chiffres affichés sont pour la plupart en base 60, sauf la date. Donc, calculs ou constantes seraient plus facile a coder en se limitant à 59. j'ajoute cette précision dans l'énoncé. Je laisse un peu de liberté sur les règles pour justement trouver des solutions sympas.
Pour l'acquisition du temps réel, l'heure/date à partir du PC ou serveur de temps semble la plus simple comme il n'y a pas de saisie manuelle dans l'énoncé de la face avant (indicateurs). Et donc pourra bouger naturellement, mais restera dans la plage de quelques années.
Suite a une remarque d'un participant, petite précision. Il n'y a pas de zéro dans les chiffres romains donc pour afficher minuit et plus soit 0h00 je propose plutôt que de laisser des espaces vides de placer un caractère O à la place. Cela ne devrait pas se produire très souvent car il n'est pas utile de mettre un zéro avant un autre chiffre, par exemple 1h05 s'écrira I:V et tous les autres sont des entiers non nuls jusqu'à 59...
Peut on utiliser un code m file avec l'outil mathscript ?
Oui, mathscript autorisé. il s'agit en fait d'une compilation en VI LabVIEW (mais difficile d'optimiser par le script ensuite)
Bonjour, n'hésitez pas à poster vos questions sur la communauté plutôt que de les demander par des Emails ! ce sera plus vivant et profite à tout le monde. (mais j'aime bien les Email aussi). Je sais que la concurrence est rude et les espions...
Aussi je vais répondre a vos interrogations :
- Est il possible d'utiliser des sous-VI ? Oui
- Comment sera faite plus précisément le test avec l'outil profil>> performance et mémoire ?
Le critère de sélection est le total d'utilisation en mémoire à partir de la colonne Octets min. Si il y a des Sous-VI alors ils seront additionnés
Normalement le découpage en Sous-vi n'augmente pas l'utilisation de la mémoire, cependant dans notre cas précis pour l'horloge, je conseille de tout faire en un seul VI, c'est plus facile à optimiser et évite les duplications et recopies.
Eviter aussi les variables locales ou globales, soignez les types et l'utilisation des tableaux
De très bon conseils sont ici :http://zone.ni.com/reference/fr-XX/help/371361J-0114/lvconcepts/vi_memory_usage/
- Pouvons nous envoyer d'autres versions de nos codes plus optimisés ?
Déjà merci de vos emails et de vos codes pas mal optimisés et si vous voulez en envoyer d'autres c'est sans problème, indiquez à la fin la version V1,V2.. mais évitez la V100 quand même ...
Emmanuel
Première version transmise, ça se ballade pour moi en dessous de 5ko... Et vous?
Bonjour tout le monde ! V2 envoyée, elle tourne autour de 4,15 ko. Premier challenge pour moi, je trouve ces challenges vraiment intéressants.
Haha, v2 en dessous de 4ko!
@Nico_EMC : en ce qui me concerne, le fait de limiter la plage à 0-59 ne m'apporte aucun gain de mémoire...
v3 envoyée, elle tourne autour de 2,74 ko
Impressionnant ! Pas de sous-VI et peu de fonctions mais astucieusement exploitées, je regarde ça de plus près...
Erratum, mauvaise interprétation des chiffres de l'outil Profile...
Je suis désolé Mathieu_R, avec les sous-VI cela fait un peu plus de 5k. mais l'horloge reste tout a fait juste et déjà très optimisée.
Peut-on savoir le meilleur record SVP ?
Quel est le format d'entrée des date et heure à afficher en chiffres romains ? Il n'y a pas d'indications dans le fichier "Main_Mon_pseudo_Chiffres romains.vi"...
En soi, le fait de limiter à la plage 0-59 ne me fait pas gagner d'utilisation mémoire... quoique un peu quand même en trichant avec la suppression de la plage qui nécessiterait l'affichage de "C" (100) et "D" (500) dans la date [le code n'est donc pas valable pour n'importe quelle date, mais puisque cette tricherie est autoriée ]
Au final, en utilisant comme entrée le VI donnant les date et heure courantes sous forme de cluster (mais est-ce la bonne entrée, rien n'étant indiqué dans l'énoncé ?), ma version 2 tourne juste en dessous de 4500 octets...
Okay, changement de fusil d'épaule, avec plage limitée à 0-59.
Avec la lecture du temps réel en chaîne de date & heure plutôt que sous forme de cluster, et en peaufinant, j'arrive à une version 3 tournant tout juste sous les 4 ko ( ~ 4070 octets). Mais pour descendre sous les 3 ko, je donne ma langue au chat
Le problème avec ces challenges, c'est que quand on commence à y réfléchir, on ne peut plus s'arrêter
Version 4 autour de 3900 octets... Maintenant, faut juste que j'arrive à décrocher
Même addiction J'ai beau avoir envoyé une v4 taillée au chausse pied pour l'utilisation mémoire, j'ai du mal à ne pas replonger, essayer d'immaginer quelque chose de différent, qui ferait mieux... Emmanuel, quelle est la date butoir pour ce challenge? Le 26/08?
Quelqu'un a t il une idée de quand fini le challenge?
edit : ARF, 1 min trop tard !
Par curiosité, vous descendez à combien ?
J'ai encore essayé divers trucs (addiction, quand tu nous tiens...), mais je n'arrive pas à mieux qu'autour de 3900 octets.
....mais c'est pas forcément une bonne idée de s'en inquiéter pour qui souhaite décrocher du sujet (moi le premier ^^).
D'une part, faut que je décroche faute de temps. D'autre part, le programme doit être basé sur une tout autre méthode que celle que j'utilise et avec laquelle je ne vois vraiment pas comment gagner encore plus d'1ko d'utilisation de la mémoire !
Je redonne donc ma langue au chat en attendant de voir les autres idées de code...
On arrête le challenge à la fin du mois pile, donc le XXXI/VIII/MMXIII à XXIII:LIX:LIX !!!
Désolé, je n'étais pas en ligne pendant quelques jours (vacances oblige !) et j'ai recu pas mal de programmes et mises à jour à analyser. De plus je planche sur le mois de septembre qui je l'espère sera "spécial" avec des signaux codés.
Moi aussi je deviens un peu dingue des chiffres romains à force de vérifier les codes et j'en vois partout, mais je m'amuse aussi a regarder vos différentes solutions qui seront bientôt dévoilées. Je pense que les astuces peuvent reservir un jour à tout le monde finalement...
Au fait, chaque jour le maillot de vainqueur change, donc je peux rien dire sur le minimum, mais ca tourne <3000
Pas d'inquétude sur la taille min/max dans profil mémoire les VIs sont lancés à la même seconde (mais aléatoire donc)
v4 envoyée. 2.54 ko en moyenne.
edit : ooooooooh, une nouvelle page rien pour moi!
Est-ce que la modification des propriétés du VI est autoriséee (désactiver le debugging, etc) ?
Je dirais oui, sinon ça relève de l'impossible de descendre aussi bas que les résultats postés précédemment.
Ca change pas mal de choses : juste en supprimant l'option d'activation de la mise au point, ma version 4 passe d'environ 3900 octets à environ 2750 !
Pourquoi pas, mais ça fausse un peu les comparaisons. Ne vaudrait-il pas mieux partir d'un copier-coller des diagrammes pour exécuter les différentes propositions dans des conditions semblables ?
Bon, au cas où, j'envoie une version 5 en supprimant juste le debugging de la 4
Je dirais plutôt que désactiver cette option faisait partie des combines à trouver pour faire chuter la mémoire.
Je dis bien faisait, parceque maintenant, bon, hin, vous m'aurez compris
Merci pour les résultats.
Concernant le résultat de GiulianoFranchetto, tu peux encore gagner quelques dizaines d'octets (et prendre la deuxième place) et ajoutant un "request deallocation" dans tes boucles.
Félicitation au gagnant et aux finalistes !
Mais serait-il possible d'avoir les codes en version autre que 2012 ?
Avec ma version LabVIEW 2011, je ne peux voir que... mon propre code
Merci d'avance,
HL
*** DISCLAIMER ***
Le code que j'ai proposé ne réponds (absolument) pas aux Guidelines de programmation LabVIEW. Je pense en particulier au fait d'empiler N fonctions incrémenter plutôt que d'utiliser une addition avec une constante, pas très lisible (bien que documenté). Je n'ai pas osé faire un Ctrl+U, mais je pense que ce serait catastrophique... Mais que ne ferait-on pas pour gagner quelques octets...
Certes cela ne répond pas à la charte "d'un code propre", mais cela répond au cahier des charges et toutes les astuces sont bonnes à prendre.
J'ai ajouté tous les codes en version LabVIEW 2010
Felicitations au gagnant
vivement le prochain, et merci pour le conseil adcpc!
J'ai découvert à l'occasion de ce challenge que chaqueterminal sur le connecteur d'un VI impacte la charge mémoire (16 octets/ terminal semble-t-il). Je crois que seul GiulianoFranchetto et moi avons joué sur ce levier. En utilisant le connecteur le plus simple - à un seul terminal, tu serais passé devant.
Euh Monsieur Roset, pourriez-vous vérifier votre dossier Spam svp ?
Vous n'avez pas utilisé la dernière version que je vous ais transmise samedi (donc dans les temps)
Et normalement comme çà je finis deuxième !
Arg !
Ce que j'ai remarqué c'est qu'il faut à tout prix éviter les tableaux de chaines, et faire des constantes chaines les plus courtes possibles. J'ai donc surtout travaillé sur ce point. (le résultat est dans ma dernière version, hum hum hum )
Et avec l'astuce du connecteur, j'aurais été à 2283o (gloups)
Et vous ?
En tout cas bravo Monsieur Reyrolle, et bonjour à Jean-Louis !
Après moultes vérifications, je n'ai rien dans la boite mail pour le 31. Spam compris. Je suis désolé. Pour éviter cela dans les prochains challenge, sachez que j'envoie un mail en retour au minimum avec la phrase "Bien reçu" comme accusé de réception.
En attendant, envoyez moi la version de samedi, je mettrai à jour le tableau d'honneur !
J'ai mis à jour le tableau avec le programme dont la date et l'heure à été vérifiée, SebastienM est bien 2 ème à 3 octets près Derrière Mathieu_R dans l'utilisation min mémoire, ce qui avait été défini comme règle de test. A noter qu'il utilise moins de blocs. En tout cas félicitations à tous les participants car cela a nécessité pas mal d'efforts d'optimisation. Je crois que c'est bénéfique car toutes les astuces pourront sûrement êtres réutilisées dans les développements futurs. Je pense que l'on renouvellera ce type de challenge mémoire un jour et vous aurez de l'avance, mais cette fois avec des programmes qui manipulent de plus gros volumes de données.
Est-il possible d'avoir la version finale du code de Sebastien, celle qui arrive en 2nde position (et de préférence, pas en LV2012) ? Merci d'avance, HL
Oui, pas de soucis, j'ai ajouté un ZIP du programme de Sébastien et j'ai ajouté une version LV 2010 avec la 2012
Merci.
Merci Emmanuel pour la patience ^^
J'utilise une boite gmail, mais je n'ai pas de problèmes habituellement.
J'utilise moins de blocs, mais l'occupation de la mémoire est légèrement supérieure à celle de Mathieu : cela est dû au fait que je n'ai pas trouvé (encore bravo), l'astuce du connecteur de VI unique.
Comme je disais plus haut, je serais à 2283 octets (et toujours 6 blocs) si je l'avais trouvé... les boules
Mais bon, c'était sympa à triturer.
A plus,
Sébastien