Concernant le vol, je serais curieux de savoir si il n'est pas possible de mettre un daemon sur la machine qui permet de localiser le voleu. Peut-être un système qui met à jour un DNS avec l'adresse IP en cour.
Il faudrait ensuite pouvoir activer la prise de photo avec la webcam. Et bien sûr faire en sorte que tout cela soit sécurisé:)
Concernant le timing des instructions, il faut voir qu'il s'agit de minimal donc, sans cache miss, sans page miss, sans erreur de prédiction de branchement. Cela peut rajouter des dizaine à des centaines de cycles au timing indiqué..
Les performances sont un des buts de Lisaac bien sûr.
Pour te donner l'anecdote, lors des premiers test du code mpeg2, lisaac était à 15% de l'exemple en C en utilisant gcc 2.95. Quelques années plus tard et une bonne dose d'optimisation de lisaac, l'exemple C est toujours 15% plus rapide. Pourquoi ?car gcc 4.3 donne du code 30% plus rapide que gcc 2.95.
Il est inutile de vouloir courir en parallèle de gcc, il sera toujours plus rapide. L'idée est de réutiliser au maximum ses avancés. Si on reste haut niveau, toutes les optimisations restent valable avec d'autres compilateurs.
La vectorisation est à la limite. Par exemple, gcc vient d'introduire Graphite ( http://en.wikipedia.org/wiki/Polytope_model ) pour réduire les boucles. C'est un an de boulot minimum pour l'intégrer dans un compilateur. Et pourtant les perspectives sont énormes en optimisation haut niveau (et avec des maths complexes). D'un autre coté, on utilise gcc et gcc utilise déjà cette optimisation. Pour lisaac, il "suffit" de produire du code gentil pour gcc (pas de pointeur, beaucoup de scalaire,...)
Il faut voir aussi que Ben fait de la recherche. Il ne peut pas "vendre" un papier sur une technologie avec autant de papier que l'auto-vectorisation.
Le projet a plus d'intérêt à partir sur des optimisations hors de porté de gcc. Par exemple, on pourrait faire la chasse au copie inutile ou au tableau temporaire.
Je veux bien croire que c'est des doubles doses, mais c'est pas vraiment le moment de creuser le trou de la sécu pour un truc qui fait moins de mort qu'une grippe saisonnière.
Moi, je dirais qu'elle est passé dans tous les foyers avec enfants (sur une dizaine) de mes collègues. A chaque fois toute la familles y passe ou presque, il y a souvent des classes fermées quelques semaine.
Sur la totalité, quelques enfants ont été très malade, les autres beaucoup moins.
Tu as aussi des trucs plus anodin comme ce que fait les réseau sociaux de nos adresses emails. Ou encore de ce qui passe par "les chat" et l'exemple de msn qui va scanner toutes urls transmises.
Un autre truc qui me fait peur, c'est l'inconscience des autres. Il ne te viendrait jamais à l'idée de mettre sur facebook une photo "compromettante" (rien de plus qu'une soiré arrosée) et pourtant un de tes amis peut trouver cela très drôle de tout mettre en ligne et de "taguer" la photo. (photo présenté bien sur par ton futur ex employeur lors du premier entretien). il y a aussi la fonction agenda qui peut contenir les coordonnées de ses amis dont ne sait ce qu'en fait facebook.
MS a un coup énorme à jouer pour contrer google sur le thème : on vous fait payer les logiciels, mais vos données sont plus importantes et on ne vous les "emprisonnes" pas.
C'est d'autant plus facile avec les déclarations limites du pdg de google.
Ne mélange pas ce qui existe et ce qu'il est possible de faire. Lisaac produit du C89 car en l'état actuelle des choses, il n'y a aucun intérêt à produire autre chose sauf à être incompatible.
Je pense que si il produit autre chose, cela sera du "C99 gcc" avec les bonnes extensions.
Concernant la vectorisation automatique, gcc en fait déjà pas mal tout seul comme un grand. Je penche plutôt sur le fait de faire des boucles qui s'automatise facilement. Vu la quantité de matière grise mis sur ce genre de problématique, je ne pense pas que l'on puisse faire une grosse différence.
Donc, en gros, on pense s'appuyer sur GCC pour faire la vectorisation, et sur l'utilisation de lib qui manipulerait directement soit les types vectoriels de Gcc ("v4sf",etc...), soit de l'assembleur mais c'est encore moins portable.
Concernant la taille de blocs en fonction du cache, on peut faire 2 stratégies : l'une dynamique en utilisant une lib qui donne la taille des caches, l'autre qui prend une taille "catch all" : 32 Ko qui correspond à une taille très courante de cache L1.
Concernant les versions de ton code, la version octave serait aussi utile pour l'utiliser comme version "haut niveau" de référence pour coder en Lisaac.
Ton rêve serait donc de pouvoir d'écrire ton algo en style "Octave" mais en ayant les perfs du C, c'est à dire sans copie inutile, et faisant du strip mining (traitement par bloc) ?
Plus que la mesure de latence, je pensais à l"utilisation des bases de donnée d'IP. Aujourd'hui on sait parfaitement situer chaque IP sur chaque DSLAM. j'imagine que si les échanges se font au niveau DSLAM, la vitesse est beaucoup plus grande.
Un moment, j'avais imaginé un système de p2p de socket UDP. Normalement un peu n'importe quoi pourrait passer dedans. L'idée est de faire de la redirection, avec au minimum un entrant et 2 sortant.
Ce qui est amusant avec udp est que tu peux spoofer l'adresse d'émission sans que cela est trop de conséquence.
Pour être performant, il faudrait ajouter une fonction d'agrégation pour augmenter la bande passante en entré, cela serait marrant de streamer de la vrai HD.
Le deuxième point méga complexe est la localisation des données. Il me semble que le système de hash distribué fonctionne bien (mldonkey ?).
Reste ensuite la base de donné distribué pour faire les recherches, et là c'est pas franchement le top. J'imagine qu'un moteur de recherche distribué est un projet à part entière. C'est encore plus complexe que l'application p2p classique car il y a les modifications à gérer (il y a beaucoup d'écriture par rapport au read only du p2p).
Un dernier point serait d'avoir un réseau p2p qui respecte la localisation géographique. Il me semble qu'il y a des tentatives de RFC pour connaitre la topologie du réseau physique pour optimiser les échanges dans les tuyaux des FAI. On peut aussi utiliser les bases de données géographiques déjà disponnible.
Cela a un gros avantage : c'est quasi impossible de scanner un réseau si on est toujours connecté aux personnes les plus proche. (par exemple pour transmettre une demande de connexion, on choisi l'ip la "plus proche" par rapport au demandeur)
L'avantage d'un streaming de flux arborescente, c'est que la voie de retour ne semble pas nécessaire, il n'y aurai donc pas de moyen de remonter à l'origine. Pour se brancher il suffirait de connaitre un noeud du réseau. Cela descend une demande dans l'arbre pour qu'une feuille envois le flux.
Pour éviter les nœuds "méchants", on peut utiliser de la signature crypto, un nœud méchant est alors signalé plus haut. Pour éviter les signalements abusifs, on demande une reconnexion au nœud connu en précisant que l'on n'aime pas tels nœuds.
J'ai du mal à comprendre, vous utilisez des fonctions tellement évoluer en openGL que les implémentations incomplètes de ATI et la lenteur des intel posent problèmes ?
Intel est lent je veux bien le croire mais il me semblait que leur implémentation d'opengl était correct.
[^] # Re: Merci pour ce test.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Quelle rigolade
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Quelle rigolade
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 2.
"La première sécurité est la liberté"
# vol
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Remboursements de licences windows sans renvoi de PC, c'est possible. Évalué à 3.
Il faudrait ensuite pouvoir activer la prise de photo avec la webcam. Et bien sûr faire en sorte que tout cela soit sécurisé:)
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
http://chl.be/glmf/articles.linuxmag-france.org/lm32/hackC.h(...)
Concernant le timing des instructions, il faut voir qu'il s'agit de minimal donc, sans cache miss, sans page miss, sans erreur de prédiction de branchement. Cela peut rajouter des dizaine à des centaines de cycles au timing indiqué..
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Beaucoup de lecture en perspective !
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Pour te donner l'anecdote, lors des premiers test du code mpeg2, lisaac était à 15% de l'exemple en C en utilisant gcc 2.95. Quelques années plus tard et une bonne dose d'optimisation de lisaac, l'exemple C est toujours 15% plus rapide. Pourquoi ?car gcc 4.3 donne du code 30% plus rapide que gcc 2.95.
Il est inutile de vouloir courir en parallèle de gcc, il sera toujours plus rapide. L'idée est de réutiliser au maximum ses avancés. Si on reste haut niveau, toutes les optimisations restent valable avec d'autres compilateurs.
La vectorisation est à la limite. Par exemple, gcc vient d'introduire Graphite ( http://en.wikipedia.org/wiki/Polytope_model ) pour réduire les boucles. C'est un an de boulot minimum pour l'intégrer dans un compilateur. Et pourtant les perspectives sont énormes en optimisation haut niveau (et avec des maths complexes). D'un autre coté, on utilise gcc et gcc utilise déjà cette optimisation. Pour lisaac, il "suffit" de produire du code gentil pour gcc (pas de pointeur, beaucoup de scalaire,...)
Il faut voir aussi que Ben fait de la recherche. Il ne peut pas "vendre" un papier sur une technologie avec autant de papier que l'auto-vectorisation.
Le projet a plus d'intérêt à partir sur des optimisations hors de porté de gcc. Par exemple, on pourrait faire la chasse au copie inutile ou au tableau temporaire.
"La première sécurité est la liberté"
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 2.
Sauf que les morts en question ont 30 ans pas 90.
"La première sécurité est la liberté"
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 3.
En gros, le virus une fois dans les poumons, c'est le système immunitaires de personne en très bonne santé qui détruise les voies respiratoires.
Donc, tu es pile dans la tranche d'age qui meurt le plus.
"La première sécurité est la liberté"
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 3.
Sur la totalité, quelques enfants ont été très malade, les autres beaucoup moins.
"La première sécurité est la liberté"
[^] # Re: Apparemment beaucoup d'infractions
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le SFLC contraint de passer à l'étape ultime pour faire respecter la GPL. Évalué à 8.
"La première sécurité est la liberté"
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: De suite...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bing et Firefox.. Évalué à 2.
Un autre truc qui me fait peur, c'est l'inconscience des autres. Il ne te viendrait jamais à l'idée de mettre sur facebook une photo "compromettante" (rien de plus qu'une soiré arrosée) et pourtant un de tes amis peut trouver cela très drôle de tout mettre en ligne et de "taguer" la photo. (photo présenté bien sur par ton futur ex employeur lors du premier entretien). il y a aussi la fonction agenda qui peut contenir les coordonnées de ses amis dont ne sait ce qu'en fait facebook.
"La première sécurité est la liberté"
[^] # Re: De suite...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bing et Firefox.. Évalué à 6.
C'est d'autant plus facile avec les déclarations limites du pdg de google.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je pense que si il produit autre chose, cela sera du "C99 gcc" avec les bonnes extensions.
Concernant la vectorisation automatique, gcc en fait déjà pas mal tout seul comme un grand. Je penche plutôt sur le fait de faire des boucles qui s'automatise facilement. Vu la quantité de matière grise mis sur ce genre de problématique, je ne pense pas que l'on puisse faire une grosse différence.
Donc, en gros, on pense s'appuyer sur GCC pour faire la vectorisation, et sur l'utilisation de lib qui manipulerait directement soit les types vectoriels de Gcc ("v4sf",etc...), soit de l'assembleur mais c'est encore moins portable.
Concernant la taille de blocs en fonction du cache, on peut faire 2 stratégies : l'une dynamique en utilisant une lib qui donne la taille des caches, l'autre qui prend une taille "catch all" : 32 Ko qui correspond à une taille très courante de cache L1.
Concernant les versions de ton code, la version octave serait aussi utile pour l'utiliser comme version "haut niveau" de référence pour coder en Lisaac.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Mais avant de savoir ce qu'il est possible de faire ou de ne pas faire, il faut déjà avoir une idée assez précise de ce que l'on voudrait.
C'est vraiment dommage que ton code soit fermé. Cela aurait fait une bonne référence, pour un bench pour voir l'effet d'optimisation.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
J'ai tout bon ?
"La première sécurité est la liberté"
[^] # Re: p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Application de P2P moderne. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Application de P2P moderne. Évalué à 2.
Mon truc c'est plus du streaming.
"La première sécurité est la liberté"
# p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Application de P2P moderne. Évalué à 3.
Ce qui est amusant avec udp est que tu peux spoofer l'adresse d'émission sans que cela est trop de conséquence.
Pour être performant, il faudrait ajouter une fonction d'agrégation pour augmenter la bande passante en entré, cela serait marrant de streamer de la vrai HD.
Le deuxième point méga complexe est la localisation des données. Il me semble que le système de hash distribué fonctionne bien (mldonkey ?).
Reste ensuite la base de donné distribué pour faire les recherches, et là c'est pas franchement le top. J'imagine qu'un moteur de recherche distribué est un projet à part entière. C'est encore plus complexe que l'application p2p classique car il y a les modifications à gérer (il y a beaucoup d'écriture par rapport au read only du p2p).
Un dernier point serait d'avoir un réseau p2p qui respecte la localisation géographique. Il me semble qu'il y a des tentatives de RFC pour connaitre la topologie du réseau physique pour optimiser les échanges dans les tuyaux des FAI. On peut aussi utiliser les bases de données géographiques déjà disponnible.
Cela a un gros avantage : c'est quasi impossible de scanner un réseau si on est toujours connecté aux personnes les plus proche. (par exemple pour transmettre une demande de connexion, on choisi l'ip la "plus proche" par rapport au demandeur)
L'avantage d'un streaming de flux arborescente, c'est que la voie de retour ne semble pas nécessaire, il n'y aurai donc pas de moyen de remonter à l'origine. Pour se brancher il suffirait de connaitre un noeud du réseau. Cela descend une demande dans l'arbre pour qu'une feuille envois le flux.
Pour éviter les nœuds "méchants", on peut utiliser de la signature crypto, un nœud méchant est alors signalé plus haut. Pour éviter les signalements abusifs, on demande une reconnexion au nœud connu en précisant que l'on n'aime pas tels nœuds.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
"La première sécurité est la liberté"
# google: "Reducing HTTP latency with SPDY"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Shared Dictionary Compression over HTTP (SDCH). Évalué à 2.
google se lance aussi dans un autre protocole : SPDY.
"La première sécurité est la liberté"
[^] # Re: Tout ceci reste scandaleusement compliqué
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Clubic nous explique comment se faire rembourser Windows. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: La troidé sous X.Org
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 2.
Intel est lent je veux bien le croire mais il me semblait que leur implémentation d'opengl était correct.
"La première sécurité est la liberté"