Version imprimable
Dans Lsinclar-2
A enlever
Pour le code suivantCode:memset(URL, 0, 2048); /* initialise tableau de char */
le transformer enCode:
2
3
4
5
6
7
8
9
Ton code va encore plus pulser avec les memset en moins...Code:
2
3
4
5
6
7
8
9
10else if (flag) { URL[b] = '\0'; puts(URL); flag = b = 0; } } /* if tag */ } /* if " ou ' */ else if (flag) URL[b++] = buf[n];
j'ai pas bien compris les nouveaux results :aie: .
j'envoie un code qui se revele etre 3 fois plus rapide que le precedent sur ma machine ... et j'ai un score 4 fois plus pourrit ... rien compris :aie: :aie: (ptetre a cause du champs de bit et le fait que tu compile en -O3 ... m'enfin ... j'ai pas trop le temps de chercher la.)
j'obtiens plutot ça moi:
/!\ attention: je ne met pas en doute les resultats, j'essaye seulement de comprendre !Code:
2
3
4
5
6
7
8
9
je sais pas pourquoi je rate trop d'urls (je connais rien au html ... donc forcement j'ai fait une bourde ^^). d'ailleurs si on veux bien m'expliquer ce que je rate ....
voila le fichier "de base" sur lequel je travaille pour tester la validité de mon algo:
resultat:Code:
2
3
4
5
6
7
8
9
10
11
12
13<html> <body> <a href="niveau_1">1</a> <A HREF="niveau_2">2</A> <a href=niveau_3>3</a> <a class="" href=niveau_4>4</A> <a href=niveau_5 onclick="alert('<a href=bad_url_5>')">5</a> < a href=niveau_6 >6</a> <a hhref=bad_url_7>7</a> <aa href=bad_url_8>8</a> <img src=img_1></img> </body> </html>
-edit-Code:
2
3
4
5
6
7
8
hmm hmm. j'ai une petite idée du pourquoi du comment mon code as un probleme pour trouver toutes les urls.
sur: http://2007.perso.orange.fr/Dark_Ebola.c.htm
const char *refs[] =
{"IMG\0","SRC\0","HREF"
};
alors que sur: http://www.developpez.net/forums/att...4&d=1154876086
const char *refs[] =
{"img\0","src\0","href"
};
ça peux etre une piste ... je dis ça, je dis rien :mrgreen: (en tout cas en majuscule ça parse plus rien du tout ... normal je fait un superbe tolower sur tout ce qui est entré.)
?Citation:
Envoyé par Ti-R
Mmmhhh... Elle est disponible où cette fameuse wblnks.html ?
ça as ete posté y me semble par pirus ... y'as un moment !Citation:
Envoyé par David.Schris
disponible ici: http://www.mozilla.org/newlayout/tes...ss/wblnks.html
Ah oui, pardon. Désolé. Manque de sommeil je crois.Citation:
Envoyé par Dark_Ebola
Merci :)
Les résultats varient BEAUCOUP selon la page de test. Toujours par souci de transparence on va distribuer la suite d' outils dont Foobar a participé à l' élaboration.Citation:
Envoyé par Dark_Ebola
J'ai effectivement modifié la casse dans ton code, parce que sinon il ne trouvait aucune URL dans ma page de test:cry: . L' objectif n°1 est de se baser sur les mêmes paramètres avant de mesurer quoi que ce soit, la question récurente des balises à prendre en compte ou pas :cry: .
En parlant de pirus il est ou?
Il a dit qu'il déménageait, non ?Citation:
Envoyé par Lunixinclar
Il faut lui laisser le temps de poser ses balises...
C'est franchement bizzare, car "Lsinc-3-Ti-R" devrait être plus rapide que "Lsinclar-2"...
8O
Appel de memset vs affectation d'un caractère.... il ya pas photo... :?
J'ai été productif ce soir...
Je sais pas pourquoi mais j'ai eu pleins d'idées....
Je n'ai plus de limite de taille de liens....
Et un nouveau code plus rapide que la v0.2 qui fonctionne mieux que la v0.3 bugguée, voici la v0.4
Ti-R : stdin n'est seekable que parce que ton shell fait une affreuse magouille en utilisant l'indirection.
a mon avis tu limite grandement les systemes compatibles avec ton code a cause de ça.
exemple de ce que je raconte:
dans le premier cas, ça marche tres bien, indirection vers un fichier. dans le second ça ne marche plus, stdin n'est pas seekable.Code:
2
3
4
5
6
7
8
9
10
11
12
Je rajoute ma maigre contribution au Défi si c'est possible (il me semble que les inscriptions ne sont pas fermé, donc j'ai codé un p'tit machin entre hier et aujourd'hui :) )
Mon prog implémente tout bétement un automate pour reconnaitre les url à afficher, donc rien de sorcier. Il est encore pas mal optimisable (j'ai pas farfouillé les détails de syntaxe encore) mais l'idée globale et l'ordre de grandeur du temps d'éxécutions sont déjà là :D (j'pense pas que le temps d'exécution puisse varier de plus de 25% en gardant cette base :) )
Ca sera pas le plus rapide normalement, mais j'espère ne pas être non plus le plus lent :lol:
D'après conception et tests il reconnait pas mal de syntaxes différentes :) (mais ne semble pas exhaustif d'après des comparaisons avec les progs Ti-R :? )
Soyez indulgent, je ne code en C que depuis environ 6 mois :mrgreen:
Il l'est bel et bien. C'est indiscutable: virer memset() est grand et économe.Citation:
Envoyé par Ti-R
Sur le tableau publié hier soir (Wed Aug 9 00:38:13 2006 GMT+1), seulement 13 microsecondes de différence: c'est infime, sur 10 tests.Si infime que représentatif sur 10 séries de tests? Non. Cette distance est d'autant plus infime que sur 30 tests réalisés, ton amélioration est clairement mise en évidence.
Dans la même optique, l' algo TiR-2 est parfois plus lent que Ti-R-1. Mea culpa je fais de mon mieux. Je jure que je n'ose même pas bouger la souris quand un test se lance. On va améliorer ça en faisant la moyenne de 20 séries de tests, eux-même appelant 40 fois chaque exe. Les résulats seront plus représentatifs.
Et on va même faire mieux que ça.
Dans son dernier post, Dark a pointé du doigt ce qui cloche.
"Un escalier de fer ... Un couloir étroit et obscur... Au fond de ce couloir une porte entr'ouverte d'ou nous parviennent les accords d'une musique, qui en ce lieu parait irréelle".
Je veux être juste. Les mesures sont faussées. Comme l' ont souligné Ti-R (+ Tchetch et quelqu'un d'autre en page 3) il faut mesurer la fonction, rien d' autre. Idéalement manipuler un pointeur de char en mémoire ça aussi a été dit. Lancer le chrono haute précision, lancer la fonction, et stopper le chrono sur retour de fonction. Néanmoins elles sont faussées pour tout le monde c'est un signe d' égalité dans la malchance. Sur de petits fichiers, et en admettant que tous les algos sont valides, les premiers sont derniers, et les derniers sont premiers (c'est ce que disait un jésuite, apparemment il avait raison). Mais sur de gros fichiers, les ratios s' affirment. Se place alors en position centrale la validité des algos, mieux vaut-il un rapide qui fait n'importe nawak ou un costaud pas rapide mais qui envoie des gifles comme Obelix. Il faut de tout pour faire un monde. Le compromis (ni trop lent ni trop rapide, ni trop puissant ni trop flemmard) n'est pas envisageable, pourtant il est là.
J'ai envie de m' excuser. Pas la science infuse. Rien que confronter son code au regard des autres est si enrichissant. C'est la force de l' Open-Source. C'est ce que permet ce forum. Que c'est instructif tous ces algorithmes, c'est fascinant. Que de remises en question. Les débutants y apprennent autant qu'un vieux briscard s'amuse à donner son avis sur la relativité. Il y a autant d' approches qu'il y a de programmeurs. Je ne veux de mal à personne, juste vivre mieux dans un monde meilleur. Mettre ses forces en commun pour faire avancer l'ensemble, naïvement, comme le code natif. Seul l' assembleur compte -il est indissociable du C- pour un processeur donné. Jusqu'à preuve du contraire les applis les plus puissantes sont en C, pas en C++, et qui peut le moins peut le plus. La vie c'est le vice à l' étude. La différence trie. Mes motifs sont bien meilleurs que mes méthodes. Etre le plus lent n'est pas blâmable, être le plus rapide n'est pas louable, la loi des contraires fait des merveilles. Une leçon d' humilité pour qui a des leçons a donner et à recevoir. Même sur 10 tests, parfois l' algo 2 de tchetch ou Ti-R est plus rapide que l' algo 1 du même auteur.
Oui les algos ne sont pas semblables.
Oui les résultats sont faux. Ce ce que dit une machine à l' instant t ne peut être généralisé ni imposer son dogme. Même si tous ses services sont désactivés, la couche réseau inhibée, tout processus killé. Oui il vaut mieux un mauvais capitaine que deux bons, indépendamment de la justesse qu'ils pourraient mettre en oeuvre. En ce sens le benchmarking de langages est plus aisé que le benchmarking d'algos, par conséquent moins répandu. Mais il paie en nature.
- "Et pourquoi crois-tu q"il a changé de nom?"
- "ehe.. Quand je cherche quelqu'un je le trouve toujours. C'est pour ça qu'on me paie".
- "Tiens Sentenza, voilà les 500 dollars que je te dois",
- "Ah...J'allais oublier... Il m' a donné 1000 dollars. Et sais-tu pourquoi?"
A y perdre son latin.
Pas bon de comparer une camionette et un 38 tonnes. Soit une appli est dédiée à sa tâche, soit elle tend à devenir une lib forcément plus générale, moins précise, plus lourde. Un paradigme qui mène à des choses comme le runtime .NET ou java, panacées absolues fourrées de tritons. Sur une page de bookmarks firefox (qui inclut pleins de bytes pour les icones) Dark_Ebola est moins rapide que Foobar; mais sur wblnks de mozilla Foobar est plus lent. Vas comprendre. A ça aussi il y a une explication.
Humilité est le maître mot.
On a construit quelque chose de superbe, tous ensemble. Chacun apportant sa pierre dans un objectif commun. Je veux dire bravo, et respect. Il a fallu s' accrocher. J'ai vu le moment où l'écriture des outils de mesure étaient bloqués, problème insurmontable. A ce moment-là je me suis dit "c'est maintenant qu'il ne faut pas flancher" et encore une fois merci à Foobar, un bon programmeur parmi les autres, qui dit ce qu'il va faire et qui fait ce qu'il dit. Les scientifiques sont ceux par qui le mal et le bien arrive. L'hexadécimal est à la précision et l' imprécision ce que le dit et le non-dit sont à la littérature.
Je deviens poète là, stop. Le langage C a plus de 40 ans et n'a jamais été détrôné. Preuve en est que C et C++ cohabitent, chacun son rôle, chacun à son niveau. Vive la programmation, vive le C. Linux est une autre histoire.
Je veux voir les expressions régulières et l' utilisation de strstr().
Toute nouvelle contribution et/ou modification et/ou commentaires sont acceptés sans limite de temps aucune.
Trop bon Ozwald :mouarf: Je teste ça mais rien n'est définitif tant que Jedai n'a pas validé les algos :mrgreen:
Et bien.... :roll:
Tu as pas peur :mouarf:Citation:
Oui il vaut mieux un mauvais capitaine que deux bons
Dark Ebola, oui la v4 n'est pas si bonne que cela...
On magouille comme on peut :mouarf:
J'ai des idées de fusions v4/v1... peut être une v5... :roll:
Et bien voici la v5...
Bon je crois que je suis arrivé au bout de mon concept...
Donc voila, je pense que cela sera ma dernière version (pas mon dernier mot) ;)
Le défi continu, et qui c'est, peut être que d'autres idées fleurirons, ou des concepts encore plus performants naîtrons.... ou que le concours évoluera...
Bon he bien je crois que j'arrive aussi un peu au bout des idées pour ce code. Je penses gagner 3-4 ms sur ces dernières optimisations. Pour une améliorations sensible, il faudrait supporter moins de cas, mais je ne veux pas le faire.
Par contre en compilant avec l'options -DCOUNT_LINK, on obtient le nombre de liens trouvé et l'option -DCOUNT_TIME donne le temps pour parser la page. Ces données sont envoyées sur stderr !
T.
salut,
voici un petit truc qui repond (?) aux criteres du concours.
les regles etant plus simples que prevu, il n'y a donc pas de support javascript, commentaires, etc..
il s'agit d'une machine a etats. les deux choses importantes sont:
- la table ctt qui sert a associer une classe a chaque caractere: "WS" (espace, tab, '\n' etc..), "uri", "uns" (caracteres "unsafe" dans les uri, mais qu'on rencontre souvent), "qt" (quotes), etc..
- la table stt qui donne le nouvel etat en fonction de l'etat courant et de la classe du caractere en cours.
la methode n'est pas correcte du point de vue logique, car il n'y a pas de separation entre analyse lexicale et analyse grammaticale (par exemple, les caracteres composant le "a href" sont consideres comme des entites grammaticales, ce qui est ma foi fort moche, mais suffisant pour extraire simplement les "a href"). cela dit, "ca marche", et ca devrait aller assez vite (pour info, l'executable genere par icc est entre 25 et 30% plus rapide que celui genere par gcc).
on peut aller plus vite en supprimant l'etape intermediaire de conversion "caractere -> classe de caractere", mais la table d'etats devient alors plus lourde (la taille du fichier etant un parametre d'evaluation, j'ai prefere faire quelque-chose de relativement court).
la table d'etats se reconstruit facilement a la main (je viens de la gribouiller sur une feuille avant de l'encoder dans le source, tous les cas tordus n'ont donc pas ete testes a fond).
-pirus.
Une nouvelle série de 20 tests dit toujours la même chose:
http://perso.wanadoo.fr/2007/resultats.htm
:mrgreen: Plutôt que d' essayer de regagner les 900 ms qui nous sépare (perte de temps puisque chacun suit aveuglément ses propres règles :roll: ) j'ai commencé les tests sur windows, le batch est presque OK.
Tu peux aussi mettre mon vieux code (tiens je le remets ici pour te faciliter la tâche), je pense qu'il doit être un peu plus rapide. Mais bien sûr il gérait moins de cas (largement plus que ce qui est demandé de toute façon).
Je te mets également une version légèrement plus rapide de mon nouveau code.
--
Jedaï
je suis déçu par la page de test: http://perso.orange.fr/2007/liens/PageTest.txt
je pensais qu'il fallait parser le html du monde "reel" :aie:
avec des problemes d'espace, de tabulation, de minuscule//majuscule etc ...
ce qu'il serait interressant c'est d'avoir une page de test concrete avec la liste de tous les cas a gerer ... dans l'etat actuel des choses, tout le monde as suivit ses propres idées quand a ce qui doit etre parsé ou non.
+1 :roll:Citation:
ce qu'il serait interressant c'est d'avoir une page de test concrete avec la liste de tous les cas a gerer ... dans l'etat actuel des choses, tout le monde as suivit ses propres idées quand a ce qui doit etre parsé ou non.
On compare un peu l'incomparable... mais c'est comme cela :D
Cela vaut aussi pour la lecture/écriture du flux.... chacun à suivit sa méthode, peut être certaines sont plus optimisées que d'autres...