et on me sort des inepties sur le refus d'évoluer et le confort,
Quelles inepties ? Tu bases tout ton semblant d'affirmation sur: "Alors que j'étais capable de dessiner des pièces, de les assembler et de simuler des mouvements avec la V5 assez facilement, j'ai arrêté de "faire mumuse" avec la V4 au bout de 20min, n'ayant pas réussi à faire quoi que ce soit.".
Ok donc par ce que tu as pas reussi a utiliser un outil dont tu n'avais pas besoin en 20min il faut absolument former les gens a un outil particulier ?
alors que la question initiale était de la pertinence d'utiliser ces logiciels au lieu et place de logiciels libres, et au passage,
Non ce que tu dis c'est qu'il faut absolument utiliser le bon logiciel autrement les gens n'arriveront jamais a rien et ne trouveront jamais de metier. Tu insistes lourdement que c'est un point important.
Maintenant dans la vraie vie, des changements de concepts ou d'outil tu en fais tous les mois… Y'a un probleme quelque part non ?
Tu veux dire que le jour où on te met une V6 entre les mains au bout de 20 minutes tu vas pleurer, convulser, puis aller pointer à l'ANPE pour le restant de tes jours ?
Ou alors tu vas prendre le temps qu'il faut pour suivre la même démarche qu'on t'a appris pour te servir de la V5. Ca risque de prendre un poil plus de 20 min voir même de bouffer de la doc cela dit…
Franchement je m'étonne que le taux de chomage ne soit pas plus élévé quand tu vois les équipes de bras cassés où dès que tu les sors de routine et leur zone de confort restent plantés sans capacité de remise en cause ou d'évolution.
Si les profs de techno doivent absolument former à la bonne version de Catia sous peine de compromettre le futur de leur élève on est mal barré :p
Pour le sexe… vu que tu ne t'appelles pas Dominique ou Claude… il reste très peu de suspense quand même.
Et par la même tu peux avoir une estimation de l'âge aussi.
Sisi y'a des boîtes qui te fournissent les statistiques d'âge à partir du prénom. Jamais eu le temps de croiser les données pour avoir un appercu de la précision par contre… Tout se vend et tout s'achête… mais y'a surtout plein de merdes qui se vendent. Mais vu que qualifier la précision est assez difficile et que c'est un marché de rigolo, y'a plein de pognon facile à se faire.
J'ai l'impression que tu veux absolument comprendre que l'un est mieux, plus difficile ou plus intéressant que l'autre alors qui n'est pas du tout le discour.
Tu peux tout mettre appeler HPC si tu veux, voir même informatique si ca te chante ;) Simplement je suis pas certain que le discour final soit beaucoup plus clair. Ce qui me parait plus intéressant que de savoir si oui ou non tel truc fait parti de telle définition arbitraire et floue.
Tu compares une web app à une application dédiée sous Android/iOS.
Absolument. Je compare ce qu'on m'offre par rapport à mon besoin. Je suis ouvert à tout si ça fait le job.
Miniflux est adaptif et rend très bien sur un androphone sans transfiguration "mobile", non pas que je sois contre.
Le rendu d'un article n'est pas le problème. La navigation beaucoup plus, et le rendu/configuration des listing un peu.
Et puis, il dispose d'une API si l'UI et UX ne te convenait pas.
Absolument. C'est pas le genre de truc qui m'amuse de faire, mais si personne ne se dévoue et qu'un jour j'ai du temps…
Mais je ne suis clairement pas un utilisateur de Feedly ou feu Google read, je n'ai aucune idée de l'expérience magique qu'ils peuvent offrir mais tu piques ma curiosité. :)
Absolument rien de magique du tout. Juste une configuration qui permet de tirer parti correctement d'un mobile. C'est à dire:
Gesture et/ou touche re-mappable pour la navigation. Typiquement utiliser volume +/- pour scroller entre les articles permet de survoler très très rapidement les listes
Configuration de l'affichage selon plusieurs layout. Selon les catégories tu peux choisir de faire défiler item par item ou 5 par 5 par exemple
Mise en cache, permet de scroller très rapidement en avant/arrière même avec un réseau tout poucrave.
Bref mon besoin c'est de pouvoir identifier rapidement les ~5% d'articles que je vais décider de lire en perdant le moins de temps possible pour cette tache.
Même si j'ai pas eu le temps de regarder ou de jouer avec, y'a pas un ligne de python dans Presto AFAIK.
Après ce qu'il faut bien comprendre, c'est que si tu veux un truc efficace tu dois construire un truc adhoc parfaitement adapté à un besoin précis. On ne peut pas comparer des choux et des carottes.
Quand tu parle de python, tu parles bien de python sans cython/pythran and co?
Oui.
Tu as beaucoup moins de hotspot précis et isolés que dans un contexte HPC.
Une fois que tu as le design et les algo corrects pour résoudre ton problème, il reste que tout ton code va grosso modo boucler de quelques centaines de millions à quelques milliers de milliards de fois. Dans ces traitements tu as beaucoup de code métier qui fait pas forcément grand de méchant chose mais qui coûte. Pas du tout adapté à une approche cython/pythran si python n'est pas capable de fait le job.
Après tu as quelques fois des vrais bon vieux Hotspot où tu peux te faire plaisir. Mais en général ca sert à rien de les optimiser avec toute la lourdeur que ca implique si tu rames sur le reste.
Bref c'est pour ca que Java/Scala sont pas mal utilisés dans ce domaine. C'est un compromis acceptable entre facilité et rapidité de déploiement/écriture et les perfs atteignables. Après dès que t'es sur une boucle qui demande du SIMD, tu prends une énorme tatane et tu fais un binding natif si c'est vraiment un job clé et qui va te coûter du pognon. Mais d'une manière générale on cherche pas l'efficacité mais simplement que ca tourne de manière acceptable. Contrairement au HPC, ca bouge beaucoup trop vite pour avoir le temps de peaufiner.
Je m'excuse si je passe à côté de quelque chose et je peux avoir tord mais ici j'arrive pas à voir ce que je manque: j'ai toujours cette vision de la compression de maillage 3d basé sur un octree et un ordre de morton où python me tue les performances par rapport au C++ (simd etc…)
Heu je crois qu'on dit la même chose:
C/C++ peuvent être très rapide et fortement tordu quand tu as une petite base de code à optimiser fortement.
Python ça permet d'écrire des trucs crado mais lent rapidement. Ca permet aussi d'optimiser des petits bouts de code précis quand tu as des hotspots.
Java c'est un compromis qui est relativement rapide tant que t'as pas de SIMD (pas d'auto-vectorisation du tout) au pire tu peux optimiser comme tu le ferais avec Python.
Ca veut pas dire qu'il faut jeter python, il a parfaitement ses usages. Surtout que très souvent les batchs de prod récurrents sont minoritaires. Mais tu semblais dire que ca ne change pas grand chose quand t'es IO bound, alors que d'expérience en big data grosso faut compter 3 à 10x plus lent qu'un truc écris proprement en Java. Franchement de l'IO bound au sens strict du terme, pas souvenir d'en avoir vu des masses. En général tes batchs suivent difficilement un flux disque ou réseau bien compressé comme il faut.
HPC on l'entend généralement au sens traditionnel du terme: supercalc, grille, cluster, top500, simulation, modèles numériques etc.
Affubler Hadoop, et tout l'écosystème du gros mot Big Data, d'HPC ça brouille vachement le message car c'est vraiment deux mondes très très différents qui n'ont pas grand chose en commun. Comme un cluster Cassandra tu vas pas lui coller le nom HPC même si il a quelques centaines de nœuds.
D'un côté Hadoop devient de plus en plus un scheduler via YARN, et de l'autre tout et n'importe quoi avec ses 200 sous/sur projets. Mais on reste très loin de l'univers, des problématiques et des solutions de l'HPC.
Pour python, je dirais plutôt que dans la majorité des cas du macro HPC, les performances sont largement suffisantes car le goulot d'étranglement sont les IOs (disques/réseaux) donc il n'est pas utile de se prendre la tête.
Heu non pas vraiment.
Si tu regardes tous les framework Python au dessus d'Hadoop et que tu restes sur des traitements simples, favorable à Python donc, tu prends un facteur entre 3 et 10.
Tout ca au dessus d'un truc qui est déjà très lent. Hadoop MR c'est scalable et tolérant aux pannnes par design (ce qui veut pas dire que son problème s'exprime de manière scalable en MR), mais l'efficacité est moyenne à mauvaise. Si tu construits un truc pour ton problème c'est normalement plusieurs dizaines d'ordres de grandeurs que tu gagnes.
Bref Python peut être un choix valable car 90% des jobs écrit sont fait à l'arrache et on se balance de leur efficacité modulo que ca tienne sur le cluster et que ca ne coute "que" 4x plus cher en matos. Mais dire que t'es IO bound et que Python ne change rien faut pas déconner. Sur les vrais jobs on bosse le design mais aussi énormement l'optim des implems de bas niveau ce qui donne des gains très significatifs.
Posté par ckyl .
En réponse au journal Small Issue Tracker.
Évalué à 8.
Dernière modification le 06 novembre 2013 à 23:45.
qq ms pour un select de 10000 éléments, c'est juste ultra lent. Sur un cpu ghz, cela fait un million de cycle ! une recherche avec strcmp() serait plus rapide.
Peut être, ou pas. Mais n'êtes vous pas train de vous toucher grave pour un truc qui n'a absolument aucune importance et dont on se fou totalement ? Bordel il veut écrire un bug tracker trivial pour des petits volumes. Qu'est ce que ça change en pratique que cette étape prenne 20µs ou 15ms ? C'est clairement pas l'étape qui prend du temps, et ca ne sera pas un bottleneck avant très très très longtemps. C'est un bug tracker ultra minimaliste quoi…
Si ca vous intéresse vraiment de sur-designer, sortez des benchs (avec des features hein, être rapide sur la V1 qui fait rien est toujours triviale) et des designs de solution simples, rapides et évolutives. Mais là on est vraiment en train de brasser du vent…
Oui c'est une voie. Maintenant il y en a d'autres, et sans analyser les besoins fonctionnels exacts de l'appli je ne m'avancerai pas sur la meilleure approche. Le coup de "Linus à dit", "Git fait ca donc c'est toujours ce qu'il faut faire", ou "j'ai regardé 3s ton problème de loin mais j'ai la solution" j'essaie d'éviter.
Parce que ce n'est pas la méthode habituelle dans le logiciel ?
Heu on essaye d'éviter hein.
Si on savait où on va et à quoi vont servir tous les choix faits, le développement n'aurait aucun attrait, aucun intérêt.
C'est exactement pour ca que souvent on essai d'éviter de deviner à quoi quelque chose va servir. Soit on le sait et on l'utilise, soit on le sait pas et on utilise le truc le plus simple pour ce que l'on sait maintenant. Effectivement avec du logiciel on peut on peut refactorer à l'infini gratuitement. Autant ne pas s'en priver plutot que de faire des choses plus complexe que nécéssaire.
Ici, on a du Release early. Release often, il est facile de trouver des problèmes dans un travail en progrès. La critique est aisée mais l’art est difficile.
J'ai du mal formuler mon message car je pense qu'on a ici un parfait exemple du bike shed et je ne comptais pas plus y participer plus que d'habitude.
Alors les aigris : camembert. Cela devient vraiment lourd.
Soit tu t'es trompés de personne, soit j'ai vraiment mal écrit. À aucun moment je n'ai critiqué le travail pour un point si trivial. Ce que je dis est assez simple et me semble constructif:
Tout d'abord on a 20 messages pour essayer de lui faire changer son système de nomage, ce que je ne fais pas. Soit, il choisira de facon éduquée. Maintenant je souligne juste que si on garde à l'esprit l'objectif initial, la plupart des solutions proposées semblent chercher à résoudre un problème… qui n'existe simplement pas. Un identifiant < 10000 n'a jamais posé problème.
Enfin que son discours sur pourquoi l'utilisation de SHA m'a laissé perplexe. D'une manière générale, si ca n'apporte rien actuellement et qu'on ne sait pas pourquoi ca va être utile c'est souvent qu'on peut s'en passer actuellement. Maintenant ca ne dis pas que ce sera une bonne ou une mauvaise décision à long terme pour ce produit, ni si c'est juste une mauvaise tournure de phrase. Je fais cette remarque par ce que ca peut amener à un échange intéressant (je suppose qu'il y a réfléchi et donc qu'il a quelques billes en réserve)
Après il faut voir de quoi tu as exactement besoin pour l'écriture et la lecture et de voir si ca s'implémente facilement ou si tu es en train de recoder une db ACID.
Il faut pas oublier qu'il designe un truc simple, qui n'aura jamais de problème de perf ou de scalabilité, et qui a très peu d'écriture. Ca laisse plein de marge pour implémenter un truc simple et robuste.
Ce n'est pas toujours un bon choix. Mais plutôt que de tout réinventer au niveau applicatif, comprendre et savoir tirer parti des mécanismes de l'OS, dont le VFS, ca permet de parfois des merveilles de simplicité et de performance. Combien de soft s'amuse à cacher dans des pages anonyme des pages déjà en cache par l'OS foutant une pression inutile sur le MM. L'exemple typique c'est Squid VS Varnish. À l'inverse savoir quand ca coute et qu'il vaut mieux bypasser est aussi utile. Haystack de Facebook est la première idée qui me vient à l'ésprit.
pouvoir gérer dix mille tickets à l'aise, ce qui me semble largement suffisant pour une équipe de 20 personnes pendant 5 ans.
En même temps vu tes objectifs n'es tu pas en train de sur-designer et d'inveter des problèmes à résoudre ? Un bête compteur jusqu'à 10000 ca ne pose aucun soucis à l'utilisation. On le fait depuis des dizaines d'année avec les différents VCS ou bug tracker sans me souvenir d'une fois où ca ait pu poser problème. Ca permet de communiqué sans aucune ambiguité et c'est facile à se souvenir.
C'est un peu comme dire que as utilisé SHA par ce que ca semblait pouvoir t'aider pour implémenter un truc sans trop encore savoir comment. Comme ca, ca ne me semble pas faire les choses dans le bon sens.
Heu le "tu" c'est toi/ton équipe/ton projet/ta boîte selon le cas. Bien évidement la décision est validée.
Et c'est justement ce que je disais. Ca passe de plus en plus dans les moeurs de remonter les patchs où d'open sourcer des briques qui n'ont pas de valeur business (ca te permet de construire ton produit mais y'a pas grand chose à en tirer pour ce que tu es prêt à investir). Bref c'est de plus en plus facile d'obtenir l'accord pour le faire.
Après certaines boîtes préfèrent centraliser les contributions pour se faire une belle vitrine, d'autres aux contraires demandent de ne jamais montrer leur nom.
C'est moche, mais jusqu'à présent, je n'ai jamais réussi à travailler pour une société qui prenait le logiciel libre au sérieux, autrement que pour un truc gratuit qui marche.
En général ca commence comme ca, puis tu découvres que ca marche pas toujours alors tu patches. Et comme ca te gonfle de maintenir des trucs internes (ou que ca fait de la pub gratos) tu upstream le tout.
Y'a de plus en plus de boîtes qui open source les briques de leur infra aussi. Ca coute pas grand chose et ca fait une bonne image.
Et sinon, pourquoi tu viens pas à Paris au fait, puisque c'est plus simple d'avoir un boulot ?
Par ce que quitte à aller s’enterrer dans une grosse ville avec un temps bien pourri, autant aller là où il y a à la fois des postes intéressants et les salaires qui suivent ? Donc pas Paris ;)
En fait j'arrive même pas à comprendre ce que tu veux dire.
Si c'est dire que le volume des postes où tu fais du libre est ridiculement petit par rapport au marché global je pense que tout le monde est au courant.
Bref allez dire à un jeune diplômer de faire des sacrifices quand il est au chômage dans un contexte économique pas évident
Je pense que c'est ton interprétation et ta contextualisation. Les sacrifices ça peut être financier, ça peut être de se bouger à l'autre bout du monde, ça peut être bosser comme un chien sur son temps libre pour se faire sa place, ça peut être créer sa boîte etc.
Il suffit de regarder les stats du chômage et d'arrêter de penser qu'on vie tous à Paris où il est plus simple d'avoir un boulot dans l'informatique
Faut pas déconner non plus. L'informatique se porte très bien. Trouver du taf d'autant plus pour un junior est relativement facile, puisqu'ils correspondent exactement à ce que le marché français recherche: pas cher. Vu le niveau moyen ridicule de la profession, il suffit de se sortir un peu les doigt pour passer "n'importe où" sans problème. Ça veut pas dire que tu auras le poste de tes rêves loin de là, mais que du taff y'en a contrairement à d'autres secteurs vraiment dans la merde.
Après il semble évidant que s'il n'y pas de marché local, et bien y'a pas de marché local. On peut tourner le truc dans tout les sens, la solution est uniquement de changer de métier où de localisation. Mais ça c'est valable pour tout le monde et tout les métiers non "de proximité".
Pourtant elle veut bien dire ce qu'elle veut dire. Si c'est gratuit, c'est qu'on se fait du fric sur ton dos.
Non. C'est très bête comme phrase par ce qu'elle laisse penser que c'est totallement binaire alors qu'il n'en est absolument rien.
Si un service est gratuit ca veut juste dire qu'il se finance autrement que directement via la facturation d'accès ou d'un abonnement. Cela peut être:
A perte ou sur fond propre (comme ici)
Via un autre moyen qui n'impact en rien l'utilisateur (typiquement tu fournis un service gratuit pour la visibilite qu'il t'offre ou pour t'en servir comme levier pour en rentabiliser un autre)
Via le temps de cerveau disponible de l'utilisateur
Via les données fournies par l'utilisateur. Et la encore l'échelle des pratiques est très très large.
Maintenant un service non gratuit à exactement les mêmes choix de financement en supplément de ce qu'il facture directement. Et beaucoup ne s'en privent pas.
La question n'est clairement pas binaire et simpliste comme on veut le rabacher. C'est comment se finance un service donné, et quelles choses trouvent tu acceptables (ce qui est tres subjectif).
J'avais raté son message et je ne peux que te seconder dans le fait qu'il raconte un peu n'importe quoi sur ce point là.
Le seul cas où un passage à null pourrait changer quelque chose c'est un objet à vie courte dans la young gen qui serait tenu par un objet dans la old gen en attente d'être garbagé. En gros tu viens de créer un objet que tu passes en référence à un veille objet qui va mourir). En pratique j'ai pas souvenir d'un seul problématique comme cas comme ça. Ça ne veut pas dire que ça n'arrive pas, mais que ça pose pas de problème, faire un GC de la old gen ca n'a rien d'un problème.
sachant qu'il fonctionne surtout par generation, et qu'il va donc parcourir toute la heap appartenant a une generation.
Plus que ça. Pour pouvoir collecter la young gen tu as besoin de parcourir aussi toute la old gen pour trouver les références rentrantes vers tes nouveaux objets. En pratique c'est optimisé avec des dirty cards qui sont utilisé comme des write-barriers pour ne parcourir que les pages qui ont été modifiés depuis la dernière collection plutôt que toute la old gen.
Si tu veux voir un peu comment fonctionne réellement les collections de young gen chez Hotspot je te conseil d'aller faire un tour chez Alexey Ragozin. Il a fait pleins de bons articles sur le fonctionnement du CMS et ca doit être un des derniers à comprendre comment il fonctionne en détail vu que les devs se sont tirés de chez Oracle… Les talks de Gil Tene sont pas mal aussi.
Ce n'est pas comme si l'équipe en était à son coup d'essai non plus… Rien de bien nouveau sous le soleil. Sauf que maintenant ils sont chez eux et n'ont pas le bâton d'un quelconque diplôme pour les limiter un peu. Donc ils font ce qu'ils ont toujours fait et un peu plus.
Mais je ne doute pas que sur le lot, ca sort quelques pisseurs de code flexibles, bien maléables et corvéables dont rêvent tant les startup parisiennes qui sponsorisent le truc. Par ce que le vrai problème à la base, souvenons nous, c'est qu'ils n'arrivent pas à remplir leurs postes. Bizarrement ca semble un problème Parisiano-Parisien… Vraiment étrange non ;)
[^] # Re: le libre à l'école, oui, mais par quel biais ?
Posté par ckyl . En réponse à la dépêche Des Inspecteurs Généraux de l'Éducation Nationale en table ronde chez Microsoft. Évalué à 2.
C'etait le sujet initial…
Quelles inepties ? Tu bases tout ton semblant d'affirmation sur: "Alors que j'étais capable de dessiner des pièces, de les assembler et de simuler des mouvements avec la V5 assez facilement, j'ai arrêté de "faire mumuse" avec la V4 au bout de 20min, n'ayant pas réussi à faire quoi que ce soit.".
Ok donc par ce que tu as pas reussi a utiliser un outil dont tu n'avais pas besoin en 20min il faut absolument former les gens a un outil particulier ?
Non ce que tu dis c'est qu'il faut absolument utiliser le bon logiciel autrement les gens n'arriveront jamais a rien et ne trouveront jamais de metier. Tu insistes lourdement que c'est un point important.
Maintenant dans la vraie vie, des changements de concepts ou d'outil tu en fais tous les mois… Y'a un probleme quelque part non ?
[^] # Re: le libre à l'école, oui, mais par quel biais ?
Posté par ckyl . En réponse à la dépêche Des Inspecteurs Généraux de l'Éducation Nationale en table ronde chez Microsoft. Évalué à 9.
Tu veux dire que le jour où on te met une V6 entre les mains au bout de 20 minutes tu vas pleurer, convulser, puis aller pointer à l'ANPE pour le restant de tes jours ?
Ou alors tu vas prendre le temps qu'il faut pour suivre la même démarche qu'on t'a appris pour te servir de la V5. Ca risque de prendre un poil plus de 20 min voir même de bouffer de la doc cela dit…
Franchement je m'étonne que le taux de chomage ne soit pas plus élévé quand tu vois les équipes de bras cassés où dès que tu les sors de routine et leur zone de confort restent plantés sans capacité de remise en cause ou d'évolution.
Si les profs de techno doivent absolument former à la bonne version de Catia sous peine de compromettre le futur de leur élève on est mal barré :p
[^] # Re: Quel est le problème ?
Posté par ckyl . En réponse au journal Bye bye Feedly. Évalué à 2.
Et par la même tu peux avoir une estimation de l'âge aussi.
Sisi y'a des boîtes qui te fournissent les statistiques d'âge à partir du prénom. Jamais eu le temps de croiser les données pour avoir un appercu de la précision par contre… Tout se vend et tout s'achête… mais y'a surtout plein de merdes qui se vendent. Mais vu que qualifier la précision est assez difficile et que c'est un marché de rigolo, y'a plein de pognon facile à se faire.
[^] # Re: Et MPI ?
Posté par ckyl . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 3.
J'ai l'impression que tu veux absolument comprendre que l'un est mieux, plus difficile ou plus intéressant que l'autre alors qui n'est pas du tout le discour.
Tu peux tout mettre appeler HPC si tu veux, voir même informatique si ca te chante ;) Simplement je suis pas certain que le discour final soit beaucoup plus clair. Ce qui me parait plus intéressant que de savoir si oui ou non tel truc fait parti de telle définition arbitraire et floue.
[^] # Re: Alternatives libres
Posté par ckyl . En réponse au journal Bye bye Feedly. Évalué à 3.
Absolument. Je compare ce qu'on m'offre par rapport à mon besoin. Je suis ouvert à tout si ça fait le job.
Le rendu d'un article n'est pas le problème. La navigation beaucoup plus, et le rendu/configuration des listing un peu.
Absolument. C'est pas le genre de truc qui m'amuse de faire, mais si personne ne se dévoue et qu'un jour j'ai du temps…
Absolument rien de magique du tout. Juste une configuration qui permet de tirer parti correctement d'un mobile. C'est à dire:
Bref mon besoin c'est de pouvoir identifier rapidement les ~5% d'articles que je vais décider de lire en perdant le moins de temps possible pour cette tache.
[^] # Re: Et MPI ?
Posté par ckyl . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 3.
Même si j'ai pas eu le temps de regarder ou de jouer avec, y'a pas un ligne de python dans Presto AFAIK.
Après ce qu'il faut bien comprendre, c'est que si tu veux un truc efficace tu dois construire un truc adhoc parfaitement adapté à un besoin précis. On ne peut pas comparer des choux et des carottes.
Oui.
Tu as beaucoup moins de hotspot précis et isolés que dans un contexte HPC.
Une fois que tu as le design et les algo corrects pour résoudre ton problème, il reste que tout ton code va grosso modo boucler de quelques centaines de millions à quelques milliers de milliards de fois. Dans ces traitements tu as beaucoup de code métier qui fait pas forcément grand de méchant chose mais qui coûte. Pas du tout adapté à une approche cython/pythran si python n'est pas capable de fait le job.
Après tu as quelques fois des vrais bon vieux Hotspot où tu peux te faire plaisir. Mais en général ca sert à rien de les optimiser avec toute la lourdeur que ca implique si tu rames sur le reste.
Bref c'est pour ca que Java/Scala sont pas mal utilisés dans ce domaine. C'est un compromis acceptable entre facilité et rapidité de déploiement/écriture et les perfs atteignables. Après dès que t'es sur une boucle qui demande du SIMD, tu prends une énorme tatane et tu fais un binding natif si c'est vraiment un job clé et qui va te coûter du pognon. Mais d'une manière générale on cherche pas l'efficacité mais simplement que ca tourne de manière acceptable. Contrairement au HPC, ca bouge beaucoup trop vite pour avoir le temps de peaufiner.
Heu je crois qu'on dit la même chose:
Ca veut pas dire qu'il faut jeter python, il a parfaitement ses usages. Surtout que très souvent les batchs de prod récurrents sont minoritaires. Mais tu semblais dire que ca ne change pas grand chose quand t'es IO bound, alors que d'expérience en big data grosso faut compter 3 à 10x plus lent qu'un truc écris proprement en Java. Franchement de l'IO bound au sens strict du terme, pas souvenir d'en avoir vu des masses. En général tes batchs suivent difficilement un flux disque ou réseau bien compressé comme il faut.
[^] # Re: Et MPI ?
Posté par ckyl . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 5.
HPC on l'entend généralement au sens traditionnel du terme: supercalc, grille, cluster, top500, simulation, modèles numériques etc.
Affubler Hadoop, et tout l'écosystème du gros mot Big Data, d'HPC ça brouille vachement le message car c'est vraiment deux mondes très très différents qui n'ont pas grand chose en commun. Comme un cluster Cassandra tu vas pas lui coller le nom HPC même si il a quelques centaines de nœuds.
D'un côté Hadoop devient de plus en plus un scheduler via YARN, et de l'autre tout et n'importe quoi avec ses 200 sous/sur projets. Mais on reste très loin de l'univers, des problématiques et des solutions de l'HPC.
[^] # Re: Alternatives libres
Posté par ckyl . En réponse au journal Bye bye Feedly. Évalué à 4.
Je viens d'essayer sur un téléphone. Bin vu l'UX que ca donne, c'est pas aujourd'hui que je vais abandonner feedly :(
[^] # Re: Et MPI ?
Posté par ckyl . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 6.
Attention il prend toujours Hadoop comme exemple de HPC, donc en fait il parle pas vraiment d'HPC ;)
[^] # Re: Et MPI ?
Posté par ckyl . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 4.
Heu non pas vraiment.
Si tu regardes tous les framework Python au dessus d'Hadoop et que tu restes sur des traitements simples, favorable à Python donc, tu prends un facteur entre 3 et 10.
Tout ca au dessus d'un truc qui est déjà très lent. Hadoop MR c'est scalable et tolérant aux pannnes par design (ce qui veut pas dire que son problème s'exprime de manière scalable en MR), mais l'efficacité est moyenne à mauvaise. Si tu construits un truc pour ton problème c'est normalement plusieurs dizaines d'ordres de grandeurs que tu gagnes.
Bref Python peut être un choix valable car 90% des jobs écrit sont fait à l'arrache et on se balance de leur efficacité modulo que ca tienne sur le cluster et que ca ne coute "que" 4x plus cher en matos. Mais dire que t'es IO bound et que Python ne change rien faut pas déconner. Sur les vrais jobs on bosse le design mais aussi énormement l'optim des implems de bas niveau ce qui donne des gains très significatifs.
[^] # Re: Finalement
Posté par ckyl . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 2.
C'est que t'en fait pas assez alors ;) Par ce que dans le vrai monde ca pique aussi les doigts.
[^] # Re: Absurde
Posté par ckyl . En réponse au journal Small Issue Tracker. Évalué à 8. Dernière modification le 06 novembre 2013 à 23:45.
Peut être, ou pas. Mais n'êtes vous pas train de vous toucher grave pour un truc qui n'a absolument aucune importance et dont on se fou totalement ? Bordel il veut écrire un bug tracker trivial pour des petits volumes. Qu'est ce que ça change en pratique que cette étape prenne 20µs ou 15ms ? C'est clairement pas l'étape qui prend du temps, et ca ne sera pas un bottleneck avant très très très longtemps. C'est un bug tracker ultra minimaliste quoi…
Si ca vous intéresse vraiment de sur-designer, sortez des benchs (avec des features hein, être rapide sur la V1 qui fait rien est toujours triviale) et des designs de solution simples, rapides et évolutives. Mais là on est vraiment en train de brasser du vent…
[^] # Re: identifiants faciles?
Posté par ckyl . En réponse au journal Small Issue Tracker. Évalué à 2.
Oui c'est une voie. Maintenant il y en a d'autres, et sans analyser les besoins fonctionnels exacts de l'appli je ne m'avancerai pas sur la meilleure approche. Le coup de "Linus à dit", "Git fait ca donc c'est toujours ce qu'il faut faire", ou "j'ai regardé 3s ton problème de loin mais j'ai la solution" j'essaie d'éviter.
[^] # Re: identifiants faciles?
Posté par ckyl . En réponse au journal Small Issue Tracker. Évalué à 7.
Heu on essaye d'éviter hein.
C'est exactement pour ca que souvent on essai d'éviter de deviner à quoi quelque chose va servir. Soit on le sait et on l'utilise, soit on le sait pas et on utilise le truc le plus simple pour ce que l'on sait maintenant. Effectivement avec du logiciel on peut on peut refactorer à l'infini gratuitement. Autant ne pas s'en priver plutot que de faire des choses plus complexe que nécéssaire.
J'ai du mal formuler mon message car je pense qu'on a ici un parfait exemple du bike shed et je ne comptais pas plus y participer plus que d'habitude.
Soit tu t'es trompés de personne, soit j'ai vraiment mal écrit. À aucun moment je n'ai critiqué le travail pour un point si trivial. Ce que je dis est assez simple et me semble constructif:
Tout d'abord on a 20 messages pour essayer de lui faire changer son système de nomage, ce que je ne fais pas. Soit, il choisira de facon éduquée. Maintenant je souligne juste que si on garde à l'esprit l'objectif initial, la plupart des solutions proposées semblent chercher à résoudre un problème… qui n'existe simplement pas. Un identifiant < 10000 n'a jamais posé problème.
Enfin que son discours sur pourquoi l'utilisation de SHA m'a laissé perplexe. D'une manière générale, si ca n'apporte rien actuellement et qu'on ne sait pas pourquoi ca va être utile c'est souvent qu'on peut s'en passer actuellement. Maintenant ca ne dis pas que ce sera une bonne ou une mauvaise décision à long terme pour ce produit, ni si c'est juste une mauvaise tournure de phrase. Je fais cette remarque par ce que ca peut amener à un échange intéressant (je suppose qu'il y a réfléchi et donc qu'il a quelques billes en réserve)
[^] # Re: pas mal !
Posté par ckyl . En réponse au journal Small Issue Tracker. Évalué à 0.
Single writer principle ?
Après il faut voir de quoi tu as exactement besoin pour l'écriture et la lecture et de voir si ca s'implémente facilement ou si tu es en train de recoder une db ACID.
Il faut pas oublier qu'il designe un truc simple, qui n'aura jamais de problème de perf ou de scalabilité, et qui a très peu d'écriture. Ca laisse plein de marge pour implémenter un truc simple et robuste.
Ce n'est pas toujours un bon choix. Mais plutôt que de tout réinventer au niveau applicatif, comprendre et savoir tirer parti des mécanismes de l'OS, dont le VFS, ca permet de parfois des merveilles de simplicité et de performance. Combien de soft s'amuse à cacher dans des pages anonyme des pages déjà en cache par l'OS foutant une pression inutile sur le MM. L'exemple typique c'est Squid VS Varnish. À l'inverse savoir quand ca coute et qu'il vaut mieux bypasser est aussi utile. Haystack de Facebook est la première idée qui me vient à l'ésprit.
[^] # Re: identifiants faciles?
Posté par ckyl . En réponse au journal Small Issue Tracker. Évalué à 7.
En même temps vu tes objectifs n'es tu pas en train de sur-designer et d'inveter des problèmes à résoudre ? Un bête compteur jusqu'à 10000 ca ne pose aucun soucis à l'utilisation. On le fait depuis des dizaines d'année avec les différents VCS ou bug tracker sans me souvenir d'une fois où ca ait pu poser problème. Ca permet de communiqué sans aucune ambiguité et c'est facile à se souvenir.
C'est un peu comme dire que as utilisé SHA par ce que ca semblait pouvoir t'aider pour implémenter un truc sans trop encore savoir comment. Comme ca, ca ne me semble pas faire les choses dans le bon sens.
[^] # Re: Exploitation du libre
Posté par ckyl . En réponse au sondage Vivez vous du libre?. Évalué à 4.
Heu le "tu" c'est toi/ton équipe/ton projet/ta boîte selon le cas. Bien évidement la décision est validée.
Et c'est justement ce que je disais. Ca passe de plus en plus dans les moeurs de remonter les patchs où d'open sourcer des briques qui n'ont pas de valeur business (ca te permet de construire ton produit mais y'a pas grand chose à en tirer pour ce que tu es prêt à investir). Bref c'est de plus en plus facile d'obtenir l'accord pour le faire.
Après certaines boîtes préfèrent centraliser les contributions pour se faire une belle vitrine, d'autres aux contraires demandent de ne jamais montrer leur nom.
[^] # Re: Exploitation du libre
Posté par ckyl . En réponse au sondage Vivez vous du libre?. Évalué à 7.
En général ca commence comme ca, puis tu découvres que ca marche pas toujours alors tu patches. Et comme ca te gonfle de maintenir des trucs internes (ou que ca fait de la pub gratos) tu upstream le tout.
Y'a de plus en plus de boîtes qui open source les briques de leur infra aussi. Ca coute pas grand chose et ca fait une bonne image.
[^] # Re: Des sacrifices : laissez moi rire !
Posté par ckyl . En réponse au sondage Vivez vous du libre?. Évalué à 8.
Par ce que quitte à aller s’enterrer dans une grosse ville avec un temps bien pourri, autant aller là où il y a à la fois des postes intéressants et les salaires qui suivent ? Donc pas Paris ;)
[^] # Re: Des sacrifices : laissez moi rire !
Posté par ckyl . En réponse au sondage Vivez vous du libre?. Évalué à 7.
En fait j'arrive même pas à comprendre ce que tu veux dire.
Si c'est dire que le volume des postes où tu fais du libre est ridiculement petit par rapport au marché global je pense que tout le monde est au courant.
Je pense que c'est ton interprétation et ta contextualisation. Les sacrifices ça peut être financier, ça peut être de se bouger à l'autre bout du monde, ça peut être bosser comme un chien sur son temps libre pour se faire sa place, ça peut être créer sa boîte etc.
Faut pas déconner non plus. L'informatique se porte très bien. Trouver du taf d'autant plus pour un junior est relativement facile, puisqu'ils correspondent exactement à ce que le marché français recherche: pas cher. Vu le niveau moyen ridicule de la profession, il suffit de se sortir un peu les doigt pour passer "n'importe où" sans problème. Ça veut pas dire que tu auras le poste de tes rêves loin de là, mais que du taff y'en a contrairement à d'autres secteurs vraiment dans la merde.
Après il semble évidant que s'il n'y pas de marché local, et bien y'a pas de marché local. On peut tourner le truc dans tout les sens, la solution est uniquement de changer de métier où de localisation. Mais ça c'est valable pour tout le monde et tout les métiers non "de proximité".
[^] # Re: Suivant
Posté par ckyl . En réponse au journal EnVadrouille, une galerie photo pour vos randos. Évalué à 1.
Tu ferais mieux d'utiliser le clavier. Je dis ça je dis rien.
[^] # Re: Blog sur 42 de l'intérieur
Posté par ckyl . En réponse au journal Un reportage radio dans la piscine de 42. Évalué à 5. Dernière modification le 30 octobre 2013 à 18:13.
Non. C'est très bête comme phrase par ce qu'elle laisse penser que c'est totallement binaire alors qu'il n'en est absolument rien.
Si un service est gratuit ca veut juste dire qu'il se finance autrement que directement via la facturation d'accès ou d'un abonnement. Cela peut être:
Maintenant un service non gratuit à exactement les mêmes choix de financement en supplément de ce qu'il facture directement. Et beaucoup ne s'en privent pas.
La question n'est clairement pas binaire et simpliste comme on veut le rabacher. C'est comment se finance un service donné, et quelles choses trouvent tu acceptables (ce qui est tres subjectif).
[^] # Re: Blog sur 42 de l'intérieur
Posté par ckyl . En réponse au journal Un reportage radio dans la piscine de 42. Évalué à 3.
Tu dis la même chose que moi. Tu l'as juste écris plutôt que de le laisser entendre ;)
Ca par contre non. Faudra arrêter un jour avec cette phrase qui si elle sonne bien ne veut rien dire.
[^] # Re: la réponse est évidente
Posté par ckyl . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
J'avais raté son message et je ne peux que te seconder dans le fait qu'il raconte un peu n'importe quoi sur ce point là.
Le seul cas où un passage à null pourrait changer quelque chose c'est un objet à vie courte dans la young gen qui serait tenu par un objet dans la old gen en attente d'être garbagé. En gros tu viens de créer un objet que tu passes en référence à un veille objet qui va mourir). En pratique j'ai pas souvenir d'un seul problématique comme cas comme ça. Ça ne veut pas dire que ça n'arrive pas, mais que ça pose pas de problème, faire un GC de la old gen ca n'a rien d'un problème.
Plus que ça. Pour pouvoir collecter la young gen tu as besoin de parcourir aussi toute la old gen pour trouver les références rentrantes vers tes nouveaux objets. En pratique c'est optimisé avec des dirty cards qui sont utilisé comme des write-barriers pour ne parcourir que les pages qui ont été modifiés depuis la dernière collection plutôt que toute la old gen.
Si tu veux voir un peu comment fonctionne réellement les collections de young gen chez Hotspot je te conseil d'aller faire un tour chez Alexey Ragozin. Il a fait pleins de bons articles sur le fonctionnement du CMS et ca doit être un des derniers à comprendre comment il fonctionne en détail vu que les devs se sont tirés de chez Oracle… Les talks de Gil Tene sont pas mal aussi.
[^] # Re: Blog sur 42 de l'intérieur
Posté par ckyl . En réponse au journal Un reportage radio dans la piscine de 42. Évalué à 3.
Ce n'est pas comme si l'équipe en était à son coup d'essai non plus… Rien de bien nouveau sous le soleil. Sauf que maintenant ils sont chez eux et n'ont pas le bâton d'un quelconque diplôme pour les limiter un peu. Donc ils font ce qu'ils ont toujours fait et un peu plus.
Mais je ne doute pas que sur le lot, ca sort quelques pisseurs de code flexibles, bien maléables et corvéables dont rêvent tant les startup parisiennes qui sponsorisent le truc. Par ce que le vrai problème à la base, souvenons nous, c'est qu'ils n'arrivent pas à remplir leurs postes. Bizarrement ca semble un problème Parisiano-Parisien… Vraiment étrange non ;)