La différence entre live et un enregistrement peut avoir plusieurs sources et pas forcément en rapport avec la qualité brut de l'enregistrement.
Déja en live, le son te parvient différemment avec des rebonds qui ne sont pas reproduit par un système stéréo. Il parait qu'il y a des techniques de "mur de son" en étude pour reproduire ses effets.
il y aussi la qualité du matos d'écoute. Certe, je parle de branlettes un peu plus haut mais il y a une vrai différence entre un système à 200€ et un a 4 000€. Au dessus, le facteur "j'ai payé tellement chère que cela doit être bien" doit l'emporter.
Il y a aussi les conditions d'écoute, la qualité de la pièce d'écoute, etc...
La différence, c'est que pour avoir de la vrai hifi, tu commences à mettre 300€ dans l'ampli et 1000€ par enceinte HP.
Tu as des hifi du pauvre avec des kit ampli dont j'ai oublier le nom à 30€ et le moins chère de JBL avec des enceintes au rapport qualité prix imbattable à 120€ de mémoire.
Cela reste plus couteux que de passer de windows à Linux...
Je suis entièrement d'accord avec toi ! (même si je laisse penser le contraire).
Je répondait surtout à l'autre personne qui vantait les SACD alors que la plus part des enregistrements sont des ressortis d'enregistrement de CD avec un filtre anti-souffle. Bref, le machin qui te détruit les hautes fréquence justement.
Mais, c'est vrai qu'un bon système peut faire des merveilles sur un CD. Pas besoin d'une source de folie, si la suite ne suit pas derrière. Dans un budget hifi, on parle de 50% pour les haut parleur, 30% pour l'ampli. Donc, je n'imagine pas le prix à mettre pour réellement profiter d'un SACD correctement enregistré.
96/24, c'est le DVD-Audio. Le SACD, c'est presque 3Mhz!
C'est presque 3 Mhz certe mais sur 1 bit..
Il utilise le principe "sigma delta". Je ne me trompe pas. En gros, c'est l'erreur entre le signal reconstituer en sortie et l'entré qui est codé. Quand on moyenne le signal, on retrouve le signal d'origine (à condition de filtrer correctement l'entré !)
De mémoire, si tu as un signal a 20khz max, et que tu veux le sampler sur 1 bit, tu dois doubler la fréquence d'échantillonnage pour avoir l'équivalent sur 16 bits. Il doit y avoir des astuces dans le cas du SACD qui ne fait que 64 fois la fréquence d'un CD soit une équivalence de 6 bits.
Pour que ton signal sois carre il a un paquet d'harmoniques. Pour ton signal a 22khz sois carre, tu dois au moins choper 3 harmoniques, donc monter a 100 khz pour echantillionner.
Je veux bien que tes trips ressentes les basses mais pas les aigües !
"le son du microsillon est plus chaud, j'en connais des masses"
C'est le cas ! Le microsillon tout comme les amplis à lampes déforment énormément le son : la courbe d'amplification n'est pas plate et à tendance à compacter le spectre.
Je sais c'est "Hipe" d'avoir un ampli à tubes. Mais je suis sur que cela doit être possible d'avoir le même son avec un effet numérique... Mais, c'est sûr cela sera moins jolie sur la commode.
Et la source, elle ne s'arrête pas à 22khz! Le Super-Audio CD monte à 100khz
96 khz et 24 bits, il me semble. 144dB de rapport signal sur bruit contre 96 pour un CD 16 bits.
Manque de bol, quasiment aucun enregistrement est fait à la base pour cette précision. Un des gros problème est l'application de filtre anti souffle qui détruise les hautes fréquences et les détails. Le silence est en effet autour de 70 dB.
Et d'ailleurs un très bon ampli ne restitue rarement plus que 100/110 db de snr sois en gros le SNR de 19 bits ...
Et le sur-echantillonnage permet justement à des CD classiques de monter à 50khz.
C'est ça que j'appelle la branlette. Comment tu veux tiré de l'information supplémentaire d'une source limité à 22khz !
Pour avoir cherche un ampli audiophile pas trop mal, j'ai pu me rendre compte a quel point le monde de l'audiophile se confine a de la bonne branlette, les nerds avec le Ghz a cote, c'est vraiement des rigolo !
Les trucs genre mp3/ogg coupe a 16khz sans que cela fasse hurler.
L'exemple typique concerne les cables audio, le top du top est le cable OFC de 2.5mm2 a 3e le m. C'est deja chere mais tu entends la difference... or tu trouves des cables a 10 000e ! Evidement personne ne veut faire de teste en double aveugle avec...
Bref ton 1 et ton 2, c'est pour les personnes qui font le concours de la plus grosse. A quoi sert de monter a 50 khz si ta source s'arrete a 22Khz ? A rajouter du bruit ?
Quand a l'histoire de surechantillonage, je crois que tu dois te melanger. On parle de source numerique ! Du point de vue qualite, tu as la tenu de l'horloge (le jitter) et le fait de ne pas faire d'erreur de lecture (correction en tenant compte du codage reed solomon). Et rien d'autre.
Pour ton histoire de lissage, tu devrair relir le theoreme de shannon...
"Bien entendu. Mais pourquoi un compilo C le fait par fichier .c ?"
J'en sais trop rien. Sans doute une histoire de limitation des compilateurs C à l'époque ou l'on avait 512Ko de mémoire.
On est d'accord. Mais comment allez vous gérer l'intégration avec le langage C que vous proposez dans le langage ? Dès qu'un bout de code apparaît vous désactivez quelles optimisations ?
L'inclusion du C permet la réutilisation de lib, il ne faut pas chercher plus loin...
Tu crois que dans l'embarqué ils ne se soucient pas du tout de la modularité, de la lisibilité du code ?
C'est aussi l'intérêt d'un langage de haut niveau par rapport au C.
Dans un cas, on parle d'un compilo de haut niveau qui peut gérer différentes structures de controle et dans l'autre, il s'agit de lib wraper dans du sucre syntaxique par modif du compilo.
Au final, à part que la solution 2 est moche, je ne vois pas vraiment de différence.
"Le code c'est quoi dans un projet, à allez à la louche 25% du temps ? gagner 20% de temps sur 25% d'un projet ? C'est où la révolution ?"
On ne doit pas bosser sur les mêmes projets...
"Ca ne répond en rien à la problématique que j'ai posée concernant lea divergeance d'intérêt entre les algos d'optimisation globale et le besoin de modularité..."
Quand tu es au niveau d'optimisation d'une lib, tu peux déjà faire beaucoup plus que le faire par fichier .c comme le C actuellement. C'est un boulot prévus cette année, il me semble, la modularité.
"avant de chercher à optimiser, il faut voir le gain global potentiel par rapport à l'effort mis en place, c'est pour ca que j'essai de replacer dans un contexte réel les gains potentiels d'optimisation que pourrait apporter Lisaac..."
Je ne vois pas de quoi tu parles. De l'effort sur un programme particulier ou sur le compilo ? C'est évidement vrai pour un programme particulier. C'est faux pour le compilo dont les efforts bénéficient à tous les programmes.
"1- La question doit être posée différement : quelle est la difficulté de constuire un programme "optimale" en Lissac par rapport à la difficulité d'optimiser un code en C ?
Autre question : 2 - pourquoi les mêmes optimisations ne peuvent-elles pas être appliquées à un autre langage ?
Mince tu viens d'avoir une crise d'intelligence ! C'est les 2 points essentiels qui ont amené la création de Lisaac.
Lisaac ayant une sémantique de plus haut niveau, le compilo peut faire plus de choses que dans d'autres langages. Le principe de l'algo d'étude du flot peut marcher sur tous les langages je pense. Il marche bien avec Lisaac, c'est un plus.
Niveau optimisation automatique, il y a plein de choses infaisables en C : notamment, tu ne peux pas toucher le layout mémoire des données, or pour la vectorisation automatique cela peut être nécessaire. L'utilisation de pointeur te fait pointer sur un trou noir et les alias peuvent être compliqué à détecté.
"T'as émis l'hypothèse que tu comprenais pas ce que je disais ou qu'on parlait pas de la même chose ?"
Tu parlais de l'embarqué d'une façon un peu "à coté de la plaque". Dans l'embarqué, tu veux un code qui marche, un développement rapide, une empreinte mémoire minimum.
Il n'y a aucun intérêt à personnalisé cela. Je ne comprends pas pourquoi tu te focalise la dessus. Le seul intérêt est d'avoir un compilo qui ne comprends que l'évaluation retardé de blocs, ainsi tout le reste est dans la lib. Le compilo est donc hyper simplifié et peut donc faire des choses puissante comme la preuve.
"mais tu as de grosses lacunes en informatique théorique.
et toi en informatique pratique."
Ontologia bosse pour un éditeur il me semble...
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens
Manque de bol pour toi, il a été prouvé que le nombre de ligne de code est directement proportionnel au temps passé à écrire/valider le truc.
Que cela soit en C, en Perl, en assembleur, c'est le nombre de ligne qui détermine le temps passé et quelques soit le langage.
Donc, c'est évidement un argument primordial en développement logiciel.
Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac
Mais qu'est-ce que l'on s'en fout ! Dans n'importe qu'elle langage tu peux écrire des horreurs, pourquoi cela serait différent en Lisaac ?
"Concernant la vitesse, je doute que vous obteniez des gains exceptionnel style de facteur 4 ou 5. Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"
toi peut-être pas...
"Parcqu'un OS c'est pas un simple encodeur."
Et là paf, tu passes pour une andouille. sisi. Isaac est un projet d'OS, à la base. Et il tourne déjà très bien...
"Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"...
"Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ?" ..."Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là"
On a compris que tu ne comprends rien à l'optimisation, c'est pas la peine de l'étaler autant. Dans certain cas, tu peux avoir des facteurs 10 entre un mauvais et un bon code. Le but de lisaac sera d'avoir le bon code. Donc, certe, entre un code C tuné à mort et lisaac, tu aura 1% de mieux en lisaac (et 30% de ligne de code en moins). Mais entre du C normal et du Lisaac, tu pourras avoir des facteurs 2 ou plus.
"Sans parler du fait que même dans le monde de l'embarqué des critères comme la portabilité et la sécurité peuvent être mis en avant..."
Pourquoi tu parles de trucs qui tu ne connais pas ? La portabilité pour un code qui ne bougera pas... Certe java commence à arriver, mais c'est tellement rien en comparaison de tous les trucs en C !
J'imagine que pour la sécurité, tu parles de la sureté de fonctionnement et non d'attaque logiciel... Cela n'aurait rien à voir et surtout on s'en fout beaucoup dans l'embarqué, c'est rare d'avoir un train ou une voiture branché sur internet...
"Quel va être l'intérêt du gain de perf sachant que le gros boulot d'optimisation sera surtout à faire au niveau de la VM ?"
C'est évident que les optimisations de haut niveau n'ont aucun intérêt. C'est bien connu... sic... (surtout pour un langage qui à la base crache du C, re-sic)
Il n'y pas encore de mode strict, mais cela n'est pas le plus compliqué à utilisé même si cela a peu de sens. Lisaac n'est pas prévus pour tourner dans une jvm, sont but est d'être un langage rapide (+ que le C) et productif (que ruby/perl/python).
Si tu parles sécurité, c'est d'un point de vue attaquant. Je préfaire parler de respect de la spec. C'est déjà énorme par rapport à ce qui existe actuellement.
Tous les discussions qu'il y a ici, c'est pour prendre la température et avoir des avis de personne diverse et varié. Et si on ne parle pas plus des features à venir, c'est parce qu'elle n'existe pas encore.
Ontologia balance ses réflexions pour avoir du retour. Le but n'est pas de faire de la pub pour Lisaac. Ce qui est horripilant de ta part, c'est de condamner le langage sans le moindre doute, en y connaissant si peu.
Si tu veux, l'auteur de Lisaac est à situer entre ceux de Java, des pures codeurs, et ceux de OCaml des pures universitaires. Benoit est dans la catégorie pur codeur universitaires... Il utilises ses outils tous les jours et connait les concepts avancé "universitaires". Cela fait la différence.
[^] # Re: Son
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
Déja en live, le son te parvient différemment avec des rebonds qui ne sont pas reproduit par un système stéréo. Il parait qu'il y a des techniques de "mur de son" en étude pour reproduire ses effets.
il y aussi la qualité du matos d'écoute. Certe, je parle de branlettes un peu plus haut mais il y a une vrai différence entre un système à 200€ et un a 4 000€. Au dessus, le facteur "j'ai payé tellement chère que cela doit être bien" doit l'emporter.
Il y a aussi les conditions d'écoute, la qualité de la pièce d'écoute, etc...
"La première sécurité est la liberté"
[^] # Re: Travailler le son
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 3.
Tu as des hifi du pauvre avec des kit ampli dont j'ai oublier le nom à 30€ et le moins chère de JBL avec des enceintes au rapport qualité prix imbattable à 120€ de mémoire.
Cela reste plus couteux que de passer de windows à Linux...
"La première sécurité est la liberté"
[^] # Re: Travailler le son
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
Je répondait surtout à l'autre personne qui vantait les SACD alors que la plus part des enregistrements sont des ressortis d'enregistrement de CD avec un filtre anti-souffle. Bref, le machin qui te détruit les hautes fréquence justement.
Mais, c'est vrai qu'un bon système peut faire des merveilles sur un CD. Pas besoin d'une source de folie, si la suite ne suit pas derrière. Dans un budget hifi, on parle de 50% pour les haut parleur, 30% pour l'ampli. Donc, je n'imagine pas le prix à mettre pour réellement profiter d'un SACD correctement enregistré.
"La première sécurité est la liberté"
[^] # Re: Son
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
C'est presque 3 Mhz certe mais sur 1 bit..
Il utilise le principe "sigma delta". Je ne me trompe pas. En gros, c'est l'erreur entre le signal reconstituer en sortie et l'entré qui est codé. Quand on moyenne le signal, on retrouve le signal d'origine (à condition de filtrer correctement l'entré !)
De mémoire, si tu as un signal a 20khz max, et que tu veux le sampler sur 1 bit, tu dois doubler la fréquence d'échantillonnage pour avoir l'équivalent sur 16 bits. Il doit y avoir des astuces dans le cas du SACD qui ne fait que 64 fois la fréquence d'un CD soit une équivalence de 6 bits.
"La première sécurité est la liberté"
[^] # Re: GLMF bizarre!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
La photo finit aussi en jpeg avant impression.
"La première sécurité est la liberté"
[^] # Re: GLMF bizarre!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
Pour que ton signal sois carre il a un paquet d'harmoniques. Pour ton signal a 22khz sois carre, tu dois au moins choper 3 harmoniques, donc monter a 100 khz pour echantillionner.
"La première sécurité est la liberté"
[^] # Re: GLMF bizarre!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: GLMF bizarre!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Son
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 5.
"le son du microsillon est plus chaud, j'en connais des masses"
C'est le cas ! Le microsillon tout comme les amplis à lampes déforment énormément le son : la courbe d'amplification n'est pas plate et à tendance à compacter le spectre.
Je sais c'est "Hipe" d'avoir un ampli à tubes. Mais je suis sur que cela doit être possible d'avoir le même son avec un effet numérique... Mais, c'est sûr cela sera moins jolie sur la commode.
Et la source, elle ne s'arrête pas à 22khz! Le Super-Audio CD monte à 100khz
96 khz et 24 bits, il me semble. 144dB de rapport signal sur bruit contre 96 pour un CD 16 bits.
Manque de bol, quasiment aucun enregistrement est fait à la base pour cette précision. Un des gros problème est l'application de filtre anti souffle qui détruise les hautes fréquences et les détails. Le silence est en effet autour de 70 dB.
Et d'ailleurs un très bon ampli ne restitue rarement plus que 100/110 db de snr sois en gros le SNR de 19 bits ...
Et le sur-echantillonnage permet justement à des CD classiques de monter à 50khz.
C'est ça que j'appelle la branlette. Comment tu veux tiré de l'information supplémentaire d'une source limité à 22khz !
"La première sécurité est la liberté"
[^] # Re: GLMF bizarre!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 4.
Les trucs genre mp3/ogg coupe a 16khz sans que cela fasse hurler.
L'exemple typique concerne les cables audio, le top du top est le cable OFC de 2.5mm2 a 3e le m. C'est deja chere mais tu entends la difference... or tu trouves des cables a 10 000e ! Evidement personne ne veut faire de teste en double aveugle avec...
Bref ton 1 et ton 2, c'est pour les personnes qui font le concours de la plus grosse. A quoi sert de monter a 50 khz si ta source s'arrete a 22Khz ? A rajouter du bruit ?
Quand a l'histoire de surechantillonage, je crois que tu dois te melanger. On parle de source numerique ! Du point de vue qualite, tu as la tenu de l'horloge (le jitter) et le fait de ne pas faire d'erreur de lecture (correction en tenant compte du codage reed solomon). Et rien d'autre.
Pour ton histoire de lissage, tu devrair relir le theoreme de shannon...
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Le même genre d'optim que fait gcc quand on inclue de l'asm : aucune.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
J'en sais trop rien. Sans doute une histoire de limitation des compilateurs C à l'époque ou l'on avait 512Ko de mémoire.
On est d'accord. Mais comment allez vous gérer l'intégration avec le langage C que vous proposez dans le langage ? Dès qu'un bout de code apparaît vous désactivez quelles optimisations ?
L'inclusion du C permet la réutilisation de lib, il ne faut pas chercher plus loin...
Tu crois que dans l'embarqué ils ne se soucient pas du tout de la modularité, de la lisibilité du code ?
C'est aussi l'intérêt d'un langage de haut niveau par rapport au C.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Au final, à part que la solution 2 est moche, je ne vois pas vraiment de différence.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
On ne doit pas bosser sur les mêmes projets...
"Ca ne répond en rien à la problématique que j'ai posée concernant lea divergeance d'intérêt entre les algos d'optimisation globale et le besoin de modularité..."
Quand tu es au niveau d'optimisation d'une lib, tu peux déjà faire beaucoup plus que le faire par fichier .c comme le C actuellement. C'est un boulot prévus cette année, il me semble, la modularité.
"avant de chercher à optimiser, il faut voir le gain global potentiel par rapport à l'effort mis en place, c'est pour ca que j'essai de replacer dans un contexte réel les gains potentiels d'optimisation que pourrait apporter Lisaac..."
Je ne vois pas de quoi tu parles. De l'effort sur un programme particulier ou sur le compilo ? C'est évidement vrai pour un programme particulier. C'est faux pour le compilo dont les efforts bénéficient à tous les programmes.
"1- La question doit être posée différement : quelle est la difficulté de constuire un programme "optimale" en Lissac par rapport à la difficulité d'optimiser un code en C ?
Autre question : 2 - pourquoi les mêmes optimisations ne peuvent-elles pas être appliquées à un autre langage ?
Mince tu viens d'avoir une crise d'intelligence ! C'est les 2 points essentiels qui ont amené la création de Lisaac.
Lisaac ayant une sémantique de plus haut niveau, le compilo peut faire plus de choses que dans d'autres langages. Le principe de l'algo d'étude du flot peut marcher sur tous les langages je pense. Il marche bien avec Lisaac, c'est un plus.
Niveau optimisation automatique, il y a plein de choses infaisables en C : notamment, tu ne peux pas toucher le layout mémoire des données, or pour la vectorisation automatique cela peut être nécessaire. L'utilisation de pointeur te fait pointer sur un trou noir et les alias peuvent être compliqué à détecté.
"T'as émis l'hypothèse que tu comprenais pas ce que je disais ou qu'on parlait pas de la même chose ?"
Tu parlais de l'embarqué d'une façon un peu "à coté de la plaque". Dans l'embarqué, tu veux un code qui marche, un développement rapide, une empreinte mémoire minimum.
"La première sécurité est la liberté"
[^] # Re: Dune le livre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 2.
C'est le designer d'Alien non ?
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Il n'y a aucun intérêt à personnalisé cela. Je ne comprends pas pourquoi tu te focalise la dessus. Le seul intérêt est d'avoir un compilo qui ne comprends que l'évaluation retardé de blocs, ainsi tout le reste est dans la lib. Le compilo est donc hyper simplifié et peut donc faire des choses puissante comme la preuve.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"mais tu as de grosses lacunes en informatique théorique.
et toi en informatique pratique."
Ontologia bosse pour un éditeur il me semble...
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens
Manque de bol pour toi, il a été prouvé que le nombre de ligne de code est directement proportionnel au temps passé à écrire/valider le truc.
Que cela soit en C, en Perl, en assembleur, c'est le nombre de ligne qui détermine le temps passé et quelques soit le langage.
Donc, c'est évidement un argument primordial en développement logiciel.
Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac
Mais qu'est-ce que l'on s'en fout ! Dans n'importe qu'elle langage tu peux écrire des horreurs, pourquoi cela serait différent en Lisaac ?
"Concernant la vitesse, je doute que vous obteniez des gains exceptionnel style de facteur 4 ou 5. Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"
toi peut-être pas...
"Parcqu'un OS c'est pas un simple encodeur."
Et là paf, tu passes pour une andouille. sisi. Isaac est un projet d'OS, à la base. Et il tourne déjà très bien...
"Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"...
"Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ?" ..."Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là"
On a compris que tu ne comprends rien à l'optimisation, c'est pas la peine de l'étaler autant. Dans certain cas, tu peux avoir des facteurs 10 entre un mauvais et un bon code. Le but de lisaac sera d'avoir le bon code. Donc, certe, entre un code C tuné à mort et lisaac, tu aura 1% de mieux en lisaac (et 30% de ligne de code en moins). Mais entre du C normal et du Lisaac, tu pourras avoir des facteurs 2 ou plus.
"Sans parler du fait que même dans le monde de l'embarqué des critères comme la portabilité et la sécurité peuvent être mis en avant..."
Pourquoi tu parles de trucs qui tu ne connais pas ? La portabilité pour un code qui ne bougera pas... Certe java commence à arriver, mais c'est tellement rien en comparaison de tous les trucs en C !
J'imagine que pour la sécurité, tu parles de la sureté de fonctionnement et non d'attaque logiciel... Cela n'aurait rien à voir et surtout on s'en fout beaucoup dans l'embarqué, c'est rare d'avoir un train ou une voiture branché sur internet...
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
C'est évident que les optimisations de haut niveau n'ont aucun intérêt. C'est bien connu... sic... (surtout pour un langage qui à la base crache du C, re-sic)
"La première sécurité est la liberté"
[^] # Re: Du RPM warez !!!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: Ha, ça tombe bien…
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Si tu parles sécurité, c'est d'un point de vue attaquant. Je préfaire parler de respect de la spec. C'est déjà énorme par rapport à ce qui existe actuellement.
Tous les discussions qu'il y a ici, c'est pour prendre la température et avoir des avis de personne diverse et varié. Et si on ne parle pas plus des features à venir, c'est parce qu'elle n'existe pas encore.
Ontologia balance ses réflexions pour avoir du retour. Le but n'est pas de faire de la pub pour Lisaac. Ce qui est horripilant de ta part, c'est de condamner le langage sans le moindre doute, en y connaissant si peu.
Si tu veux, l'auteur de Lisaac est à situer entre ceux de Java, des pures codeurs, et ceux de OCaml des pures universitaires. Benoit est dans la catégorie pur codeur universitaires... Il utilises ses outils tous les jours et connait les concepts avancé "universitaires". Cela fait la différence.
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Il avait le code source ? Ils ont bossé en boite blanche ? Combien de samples ?
(à part ça, 4 semaines, c'est hyper court...) 6 mois, c'est autre chose.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"La première sécurité est la liberté"