os et concept de langage

Le 01/04/2010 10:19, remy a écrit :

et un petit dernier qui alloue les zones mémoire
et pour faire plaisir à jdk on ne l'appellera pas garbage collector
(je plaisante )

C'est JKB que tu traites de JDK ? Je pense qu'il va adoré.

Le 01/04/2010 10:59, batyann811 a écrit :

C'est JKB que tu traites de JDK ? Je pense qu'il va adoré.

Euh 'adorer' plutôt...

Le 01-04-2010, ? propos de
os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

bonjour

'jour,

si je suppose que le c++ est encore en train de trainer dans les bars
à la recherche de son domaine d'application ,à mon avis il
est trop tard et il finira alcolo tout comme le caml ou ocaml
un truc qui a le mérite d'exister et c'est déjà pas mal
que java depuis le rachat de sun a un avenir incertain

Bof. Déjà, il faudrait voir en quoi java est essentiel à
l'informatique et je vois mal Oracle faire des conneries avec Java.
OpenJDK fonctionne pas mal et pourrait bien devenir la version de
référence de ce truc non normalisé. L'immense majorité des développeurs
ont déserté Sun depuis le rachat par Oracle.

la programmation obj a tout de même un domaine de prédilection
les interfaces graphiques ou programmations évènementielles

Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un simple
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est un
truc _très_ agréable à coder en C. Maintenant, on peut ne pas aimer
le design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui est
très bien.

et pourtant il y a un autre domaine où il pourrait être super utile
au hasard les os

Un OS en C++, p'taing, ce qu'il ne faut pas entendre. Il y a
tellement de couches d'abstractions dans du C++ que c'est
contre-productif, mais c'est à toi de voir. Il y a régulièrement des
batailles pour mettre du C++ dans les noyaux Unix et ça termine
toujours de la même manière.

par exemple un langage obj multi thread
comment faire en 3 coups de cuillère à pot un os minimaliste

Et carrément sous-optimal. Tu ne peux avoir en même temps
l'efficacité du C et l'abstraction du C++. Si tu veux un bon exemple :
regarde pgrouting et utilise cette bibliothèque avec une
cartographie à l'échelle de l'ensemble des rues d'un pays.
Maintenant, prends un compilo C et code ton propre A* pour obtenir
le même résultat. Tu verras une sacré différence de vitesse (20 fois
plus rapide pour la version C) et une occupation mémoire différente
(10 fois moindre pour la version C). Les types qui ont codé Boost ne sont
pas des imbéciles. Seulement les couches du C++ qui s'empilent sont
toutes génériques et jamais parfaitement adaptées à _ton_ problème
qui est la recherche du meilleur chemin avec un A*.
Le résultat est que tu perds des cycles à droite et à gauche et
qu'au final le résultat est _mauvais_.

4 fifo (4 niveaux de priorité)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo

Personnellement, je ne gèrerais pas vraiment ça avec des fifo mais
avec un seul anneau et des règles de saut, mais c'est à toi de voir.

un thread qui remplit le fifo

et un petit dernier qui alloue les zones mémoire
et pour faire plaisir à jdk on ne l'appellera pas garbage collector
(je plaisante )

Un noyau de système n'a rien à faire de la gestion de la mémoire
dynamique au sens où tu l'entends. Dans un système Unix, c'est la
libc (ou l'une de ses composantes) qui s'amuse à ça. Le noyau gère
sa propre mémoire et n'a pas besoin d'un garbage collector. Pourquoi ?
Tout simplement parce que le noyau sait a priori ce qu'il fait et
utilise des systèmes de verrous différents de ceux du userland.
Regarde la différence entre kmalloc() et malloc(), tu auras quelques
surprises. Par ailleurs, un malloc() peut échouer. Il serait
franchement bizarre qu'un kmalloc() échoue et renvoit un superbe
NULL.

puisque dans un thread, on a tout ce qu'il nous faut pour suspendre
arrêter ou lancer un processus, avec en plus des mécanismes de
protection mémoire liés au concept obj, donc pourquoi s'en passer

Il y a juste un truc que tu oublies. Un OS, c'est un programme lié
statiquement avec rien qui dépasse. Tu n'as a priori rien pour gérer
ça si tu ne le fais pas à la mimine.

en gros l'idée consiste à gagner du temps processeur
en définissant en statique "définition du langage" tous les contrôles
qui sont actuellement faits en dynamique contrôle sur les signaux
protection mémoire etc

Exprime-toi correctement. C'est incompréhensible.

en plus si les threads sont bien pensés l'on peut faire du scalaire ou
du vrai parallélisme

Que le scalaire ou le vectoriel dépend plus de l'architecture que de
l'OS lui-même, mais on n'est plus à ça près...

quand pensez vous ?

Que tes produits sont vachement efficaces.

sans compter que pour les nostalgiques on peut le faire en c mais avec
des règles liées aux bibliothèques

Commence par lire un bon bouquin sur la façon d'écrire un OS.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Le 01-04-2010, ? propos de
os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

bonjour

'jour,

si je suppose que le c++ est encore en train de trainer dans les bars
à la recherche de son domaine d'application ,à mon avis il
est trop tard et il finira alcolo tout comme le caml ou ocaml
un truc qui a le mérite d'exister et c'est déjà pas mal
que java depuis le rachat de sun a un avenir incertain

Bof. Déjà, il faudrait voir en quoi java est essentiel à
l'informatique

comment ça c'est pas le premier, ok mais il apporte une vraie
portabilité du code "compilé"

et je vois mal Oracle faire des conneries avec Java.

OpenJDK fonctionne pas mal et pourrait bien devenir la version de
référence de ce truc non normalisé.

ok pour la normalisation, mais pas d'accord pour "le fonctionne pas mal"
essayes jmf


L'immense majorité des développeurs

ont déserté Sun depuis le rachat par Oracle.

la programmation obj a tout de même un domaine de prédilecti on
les interfaces graphiques ou programmations évènementielles

Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un simpl e
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est un
truc _très_ agréable à coder en C. Maintenant, on peut ne pas aimer
le design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui est
très bien.

je ne connait pas motif, mais une interface graphique qui n'est pas obj
si elle ne l'est pas j'en veux pas

et pourtant il y a un autre domaine où il pourrait être supe r utile
au hasard les os

Un OS en C++, p'taing, ce qu'il ne faut pas entendre. Il y a
tellement de couches d'abstractions dans du C++ que c'est
contre-productif, mais c'est à toi de voir. Il y a régulià ¨rement des
batailles pour mettre du C++ dans les noyaux Unix et ça termine
toujours de la même manière.

je serais assez partisan d'un peu d'obj dans les drivers
cela éviterait le changement d'interface à chaque nouvelle
bibliothèque

par exemple un langage obj multi thread
comment faire en 3 coups de cuillère à pot un os minimaliste

Et carrément sous-optimal. Tu ne peux avoir en même temps
l'efficacité du C et l'abstraction du C++. Si tu veux un bon exem ple :
regarde pgrouting et utilise cette bibliothèque avec une
cartographie à l'échelle de l'ensemble des rues d'un pays.
Maintenant, prends un compilo C et code ton propre A* pour obtenir
le même résultat. Tu verras une sacré différence d e vitesse (20 fois
plus rapide pour la version C) et une occupation mémoire diffé rente
(10 fois moindre pour la version C). Les types qui ont codé Boost ne sont
pas des imbéciles. Seulement les couches du C++ qui s'empilent so nt
toutes génériques et jamais parfaitement adaptées à _ton_ problème
qui est la recherche du meilleur chemin avec un A*.
Le résultat est que tu perds des cycles à droite et à g auche et
qu'au final le résultat est _mauvais_.

4 fifo (4 niveaux de priorité)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo

Personnellement, je ne gèrerais pas vraiment ça avec des fif o mais
avec un seul anneau et des règles de saut, mais c'est à toi de voir.

ce qui revient au même, mais je cherchais surtout à être
compréhensible, mais on est d'accord sur le fond

un thread qui remplit le fifo

et un petit dernier qui alloue les zones mémoire
et pour faire plaisir à jdk on ne l'appellera pas garbage coll ector
(je plaisante )

Un noyau de système n'a rien à faire de la gestion de la mà ©moire
dynamique au sens où tu l'entends. Dans un système Unix, c'e st la
libc (ou l'une de ses composantes) qui s'amuse à ça. Le noya u gère
sa propre mémoire et n'a pas besoin d'un garbage collector. Pourq uoi ?

pour éviter les problèmes de débordement de zones mé moire, c'est
l'utilité première d'un garbage collector (la sécurità ©)

puisque dans un thread, on a tout ce qu'il nous faut pour suspendre
arrêter ou lancer un processus, avec en plus des mécanismes de
protection mémoire liés au concept obj, donc pourquoi s'en p asser

Il y a juste un truc que tu oublies. Un OS, c'est un programme lié
statiquement avec rien qui dépasse. Tu n'as a priori rien pour gà ©rer
ça si tu ne le fais pas à la mimine.

pas bien compris

en gros l'idée consiste à gagner du temps processeur
en définissant en statique "définition du langage" tous les contrôles
qui sont actuellement faits en dynamique contrôle sur les signaux
protection mémoire etc

Exprime-toi correctement. C'est incompréhensible.

en plus si les threads sont bien pensés l'on peut faire du scalai re ou
du vrai parallélisme

Que le scalaire ou le vectoriel dépend plus de l'architecture que de
l'OS lui-même, mais on n'est plus à ça près...

pas d'accord ,bien sur que l'architecture rentre en ligne de compte
c'est évident, actuellement le parallélisme est très mal g éré, il se
résume à une augmentation de la charge mais pas à une augm entation de la
puissance de traitement

quand pensez vous ?

Que tes produits sont vachement efficaces.

je suppose inefficace :-)

sans compter que pour les nostalgiques on peut le faire en c mais ave c
des règles liées aux bibliothèques

Commence par lire un bon bouquin sur la façon d'écrire un OS .

facile et inutile


remy




--
http://remyaumeunier.chez-alice.fr/

On 1 avr, 10:19, remy <r...@fctpas.fr> wrote:

quand pensez vous ?

A tout moment pour moi, pour certains on se le demande.

Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 01-04-2010, ? propos de
os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

bonjour

'jour,

si je suppose que le c++ est encore en train de trainer dans les bars
à la recherche de son domaine d'application ,à mon avis il
est trop tard et il finira alcolo tout comme le caml ou ocaml
un truc qui a le mérite d'exister et c'est déjà pas mal
que java depuis le rachat de sun a un avenir incertain

Bof. Déjà, il faudrait voir en quoi java est essentiel à
l'informatique

comment ça c'est pas le premier, ok mais il apporte une vraie
portabilité du code "compilé"

Pas plus qu'un compilo C qui suit une norme précise et même moins.
Tant que tu restes sous Windows, Linux i386/amd64, Solaris et MacOS,
peut-être. Dès que tu attaques la vraie portabilité (PDA, NetBSD PPC
et j'en passe), c'est largement moins portable qu'un truc écrit en C parce
que les JVM n'ont pas été portées ou ne sont plus d'origine
Sun^WOracle. Essaye déjà de porter un soft Java spécifié JVM 1.5 sur
une J9/PPC et on en reparle. Java n'est _pas_ normalisé et rien que
ça, ça limite la portabilité sur tout ce qui n'est pas couvert par
les JVM Sun^WOracle.

et je vois mal Oracle faire des conneries avec Java.

OpenJDK fonctionne pas mal et pourrait bien devenir la version de
référence de ce truc non normalisé.

ok pour la normalisation, mais pas d'accord pour "le fonctionne pas mal"
essayes jmf

Je ne fais du Java que contraint et forcé. Pour ce que j'en fait,
OpenJDK suffit largement.

L'immense majorité des développeurs

ont déserté Sun depuis le rachat par Oracle.

la programmation obj a tout de même un domaine de prédilection
les interfaces graphiques ou programmations évènementielles

Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un simple
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est un
truc _très_ agréable à coder en C. Maintenant, on peut ne pas aimer
le design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui est
très bien.

je ne connait pas motif, mais une interface graphique qui n'est pas obj
si elle ne l'est pas j'en veux pas

Tu peux faire _sans_ objet au sens programmation objet. Et pour
avoir fait du Qt (objet) et du Motif (non objet), la programmation
de Motif est bien plus efficace et facile.

et pourtant il y a un autre domaine où il pourrait être super utile
au hasard les os

Un OS en C++, p'taing, ce qu'il ne faut pas entendre. Il y a
tellement de couches d'abstractions dans du C++ que c'est
contre-productif, mais c'est à toi de voir. Il y a régulièrement des
batailles pour mettre du C++ dans les noyaux Unix et ça termine
toujours de la même manière.

je serais assez partisan d'un peu d'obj dans les drivers
cela éviterait le changement d'interface à chaque nouvelle
bibliothèque

Foutaises. Ça simplifie les interfaces au dépens du reste (et de
l'efficacité). On n'utilise pas la programmation objet pour obvier à
un problème de design (et de macros) mal fichu. C'est vraiment le
pire argument qui puisse être.

par exemple un langage obj multi thread
comment faire en 3 coups de cuillère à pot un os minimaliste

Et carrément sous-optimal. Tu ne peux avoir en même temps
l'efficacité du C et l'abstraction du C++. Si tu veux un bon exemple :
regarde pgrouting et utilise cette bibliothèque avec une
cartographie à l'échelle de l'ensemble des rues d'un pays.
Maintenant, prends un compilo C et code ton propre A* pour obtenir
le même résultat. Tu verras une sacré différence de vitesse (20 fois
plus rapide pour la version C) et une occupation mémoire différente
(10 fois moindre pour la version C). Les types qui ont codé Boost ne sont
pas des imbéciles. Seulement les couches du C++ qui s'empilent sont
toutes génériques et jamais parfaitement adaptées à _ton_ problème
qui est la recherche du meilleur chemin avec un A*.
Le résultat est que tu perds des cycles à droite et à gauche et
qu'au final le résultat est _mauvais_.

4 fifo (4 niveaux de priorité)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo

Personnellement, je ne gèrerais pas vraiment ça avec des fifo mais
avec un seul anneau et des règles de saut, mais c'est à toi de voir.

ce qui revient au même, mais je cherchais surtout à être
compréhensible, mais on est d'accord sur le fond

Pas vraiment, mais si tu le dis.

un thread qui remplit le fifo

et un petit dernier qui alloue les zones mémoire
et pour faire plaisir à jdk on ne l'appellera pas garbage collector
(je plaisante )

Un noyau de système n'a rien à faire de la gestion de la mémoire
dynamique au sens où tu l'entends. Dans un système Unix, c'est la
libc (ou l'une de ses composantes) qui s'amuse à ça. Le noyau gère
sa propre mémoire et n'a pas besoin d'un garbage collector. Pourquoi ?

pour éviter les problèmes de débordement de zones mémoire, c'est
l'utilité première d'un garbage collector (la sécurité)

Bon, je vais enfoncer un clou. Sais-tu pourquoi un OS comme VMS est
largement plus sécurisé qu'un truc comme Unix ? Tout simplement
parce que les chaînes de caractères sont traitées par des
descripteurs, ce qui évite de fait les débordements de tampon. La
connerie intrinsèque des systèmes Unix, c'est la chaîne de
caractères terminée par un caractère nul. C'est de là que vient
l'immense majorité des failles. Pour résoudre ce problème, il ne
faut pas un garbage collector, mais un truc capable de traiter une
chaîne de caractère (ou un buffer) _avec_ sa longueur et capable de
te foutre un coup de pied au cul à chaque tentative de débordement.

puisque dans un thread, on a tout ce qu'il nous faut pour suspendre
arrêter ou lancer un processus, avec en plus des mécanismes de
protection mémoire liés au concept obj, donc pourquoi s'en passer

Il y a juste un truc que tu oublies. Un OS, c'est un programme lié
statiquement avec rien qui dépasse. Tu n'as a priori rien pour gérer
ça si tu ne le fais pas à la mimine.

pas bien compris

Tu ne peux pas faire des appels à la libc depuis un noyau Unix parce
que la libc s'appuie sur le noyau. C'est le coup de la poule ou de
l'oeuf. Ça va mieux ?

en gros l'idée consiste à gagner du temps processeur
en définissant en statique "définition du langage" tous les contrôles
qui sont actuellement faits en dynamique contrôle sur les signaux
protection mémoire etc

Exprime-toi correctement. C'est incompréhensible.

en plus si les threads sont bien pensés l'on peut faire du scalaire ou
du vrai parallélisme

Que le scalaire ou le vectoriel dépend plus de l'architecture que de
l'OS lui-même, mais on n'est plus à ça près...

pas d'accord ,bien sur que l'architecture rentre en ligne de compte
c'est évident, actuellement le parallélisme est très mal géré, il se
résume à une augmentation de la charge mais pas à une augmentation de la
puissance de traitement

Je crois surtout que tu confonds allègrement scalaire, vectoriel et
parallèle. Parallèle ou non, c'est un concept qui vient de l'OS (on
dira même multitâche ou multithread). Scalaire ou vectoriel, ça vient
de l'architecture matérielle. Parallèle, ce n'est pas le contraire de
scalaire.

quand pensez vous ?

Que tes produits sont vachement efficaces.

je suppose inefficace :-)

Non, ton dealer t'en a filé de la bonne.

sans compter que pour les nostalgiques on peut le faire en c mais avec
des règles liées aux bibliothèques

Commence par lire un bon bouquin sur la façon d'écrire un OS.

facile et inutile

Pas tant que ça. Ça t'évitera de te faire des noeuds au cerveau sur
des choses inutiles et fausses.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Bonjour,

On 2010-04-01, remy wrote:

bonjour

si je suppose que le c++ est encore en train de trainer dans les bars
à la recherche de son domaine d'application ,à mon avis il
est trop tard et il finira alcolo tout comme le caml ou ocaml
un truc qui a le mérite d'exister et c'est déjà pas mal
que java depuis le rachat de sun a un avenir incertain

la programmation obj a tout de même un domaine de prédilection
les interfaces graphiques ou programmations évènementielles


et pourtant il y a un autre domaine où il pourrait être super utile
au hasard les os


par exemple un langage obj multi thread
comment faire en 3 coups de cuillère à pot un os minimaliste

J'ai compris. Tu veux nous faire un poisson d'avril. C'est bien ca ?

A plus,

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.

remy wrote:

Bof. Déjà, il faudrait voir en quoi java est essentiel à
l'informatique

comment ça c'est pas le premier, ok mais il apporte une vraie
portabilité du code "compilé"

Trop gros, passera pas.

















































Date: Thu, 01 Apr 2010 12:00:49 +0200

ah, oké...

remy wrote:

pour éviter les problèmes de débordement de zones mémoire, c'est
l'utilité première d'un garbage collector (la sécurité)

il y a des gens vraiment crédules dans le coin...












































































ah, oké, poisson, april, toussa...

JKB a écrit :

Le 01-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 01-04-2010, ? propos de
os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

bonjour

'jour,

si je suppose que le c++ est encore en train de trainer dans les ba rs
à la recherche de son domaine d'application ,à mon avis il
est trop tard et il finira alcolo tout comme le caml ou ocaml
un truc qui a le mérite d'exister et c'est déjà pas m al
que java depuis le rachat de sun a un avenir incertain

Bof. Déjà, il faudrait voir en quoi java est essentiel à  
l'informatique

comment ça c'est pas le premier, ok mais il apporte une vraie
portabilité du code "compilé"

Pas plus qu'un compilo C qui suit une norme précise et même moins.
Tant que tu restes sous Windows, Linux i386/amd64, Solaris et MacOS,
peut-être. Dès que tu attaques la vraie portabilité (PD A, NetBSD PPC
et j'en passe), c'est largement moins portable qu'un truc écrit e n C parce
que les JVM n'ont pas été portées ou ne sont plus d'ori gine
Sun^WOracle. Essaye déjà de porter un soft Java spécifi é JVM 1.5 sur
une J9/PPC et on en reparle. Java n'est _pas_ normalisé et rien q ue
ça, ça limite la portabilité sur tout ce qui n'est pas couvert par
les JVM Sun^WOracle.

c'est un faux problème, le langage n'est pas normalisé au sens strict du
terme mais la machine virtuelle, elle, pour prétendre exécute r du java
se doit de passer une batterie de tests qui garantissent son bon
fonctionnement et donc "la norme"

et pour ta comparaison, ben cela ne le fait pas
ben oui le seul problème c'est que l'on ne compile pas les programme s
mais que l'on installe des exécutables, ne me dit pas que tu ne t'es
jamais retrouvé avec un binaire qui tourne sous une distribution et pas
sur une autre à cause d'une sordide histoire de linker

et je vois mal Oracle faire des conneries avec Java.

OpenJDK fonctionne pas mal et pourrait bien devenir la version de
référence de ce truc non normalisé.

ok pour la normalisation, mais pas d'accord pour "le fonctionne pas ma l"
essayes jmf

Je ne fais du Java que contraint et forcé. Pour ce que j'en fait,
OpenJDK suffit largement.

L'immense majorité des développeurs

ont déserté Sun depuis le rachat par Oracle.

la programmation obj a tout de même un domaine de prédilec tion
les interfaces graphiques ou programmations évènementielle s

Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un sim ple
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est un
truc _très_ agréable à coder en C. Maintenant, on peu t ne pas aimer
le design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui e st
très bien.

je ne connait pas motif, mais une interface graphique qui n'est pas ob j
si elle ne l'est pas j'en veux pas

Tu peux faire _sans_ objet au sens programmation objet. Et pour
avoir fait du Qt (objet) et du Motif (non objet), la programmation
de Motif est bien plus efficace et facile.

pour un petit truc, probablement, mais dès que tu passes au gros mac hin
ou tu clik à tout va l'usine à gaz devient ingérable avec aucune
méthodologie

l'obj facilite la lecture et la compréhension du code
cela évite tous les petits arrangements que chaque programmeur s'oct roie
pour avoir à l'arrivée quelque chose d' imbitable et non main tenable

et pourtant il y a un autre domaine où il pourrait être su per utile
au hasard les os

Un OS en C++, p'taing, ce qu'il ne faut pas entendre. Il y a
tellement de couches d'abstractions dans du C++ que c'est
contre-productif, mais c'est à toi de voir. Il y a régulià ¨rement des
batailles pour mettre du C++ dans les noyaux Unix et ça termine
toujours de la même manière.

je serais assez partisan d'un peu d'obj dans les drivers
cela éviterait le changement d'interface à chaque nouvelle
bibliothèque

Foutaises. Ça simplifie les interfaces au dépens du reste (e t de
l'efficacité). On n'utilise pas la programmation objet pour obvie r à
un problème de design (et de macros) mal fichu. C'est vraiment le
pire argument qui puisse être.

absolument pas, en quoi le fait d'avoir une approche obj grefferait les
performances

la programmation obj dans le cas par exemple du c++ est aussi performant
que le c, la preuve n'est plus à faire

la différence entre le c et le c++ réside dans la méthodol ogie
l'un est permissif l'autre t'envoie chier sans aucun remord
mais après compilation c'est du kif kif au pouillem près

par exemple un langage obj multi thread
comment faire en 3 coups de cuillère à pot un os minimalis te

Et carrément sous-optimal. Tu ne peux avoir en même temps
l'efficacité du C et l'abstraction du C++. Si tu veux un bon ex emple :
regarde pgrouting et utilise cette bibliothèque avec une
cartographie à l'échelle de l'ensemble des rues d'un pays.
Maintenant, prends un compilo C et code ton propre A* pour obtenir
le même résultat. Tu verras une sacré différence de vitesse (20 fois
plus rapide pour la version C) et une occupation mémoire diffà ©rente
(10 fois moindre pour la version C). Les types qui ont codé Boo st ne sont
pas des imbéciles. Seulement les couches du C++ qui s'empilent sont
toutes génériques et jamais parfaitement adaptées à   _ton_ problème
qui est la recherche du meilleur chemin avec un A*.
Le résultat est que tu perds des cycles à droite et à gauche et
qu'au final le résultat est _mauvais_.

4 fifo (4 niveaux de priorité)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo

Personnellement, je ne gèrerais pas vraiment ça avec des f ifo mais
avec un seul anneau et des règles de saut, mais c'est à to i de voir.

ce qui revient au même, mais je cherchais surtout à êt re
compréhensible, mais on est d'accord sur le fond

Pas vraiment, mais si tu le dis.

et ton saut ou règle de saut dans ton anneau il correspond à qu oi ?

un thread qui remplit le fifo

et un petit dernier qui alloue les zones mémoire
et pour faire plaisir à jdk on ne l'appellera pas garbage co llector
(je plaisante )

Un noyau de système n'a rien à faire de la gestion de la m émoire
dynamique au sens où tu l'entends. Dans un système Unix, c 'est la
libc (ou l'une de ses composantes) qui s'amuse à ça. Le no yau gère
sa propre mémoire et n'a pas besoin d'un garbage collector. Pou rquoi ?

pour éviter les problèmes de débordement de zones mà ©moire, c'est
l'utilité première d'un garbage collector (la sécurit é)

Bon, je vais enfoncer un clou. Sais-tu pourquoi un OS comme VMS est
largement plus sécurisé qu'un truc comme Unix ? Tout simplem ent
parce que les chaînes de caractères sont traitées par d es
descripteurs, ce qui évite de fait les débordements de tampo n. La
connerie intrinsèque des systèmes Unix, c'est la chaîne de
caractères terminée par un caractère nul. C'est de là   que vient
l'immense majorité des failles. Pour résoudre ce problè me, il ne
faut pas un garbage collector, mais un truc capable de traiter une
chaîne de caractère (ou un buffer) _avec_ sa longueur et cap able de
te foutre un coup de pied au cul à chaque tentative de débor dement.

c'est peut être une des causes mais à une rustine, je préf ère une
approche globale qui me garantit le bon fonctionnement du processus
plutot qu' une rustine sur une rustine puis une autre rustine en
attendant la prochaine approche qui nécessitera encore une énià ¨me
rustine

puisque dans un thread, on a tout ce qu'il nous faut pour suspendre
arrêter ou lancer un processus, avec en plus des mécanisme s de
protection mémoire liés au concept obj, donc pourquoi s'en passer

Il y a juste un truc que tu oublies. Un OS, c'est un programme lià ©
statiquement avec rien qui dépasse. Tu n'as a priori rien pour gérer
ça si tu ne le fais pas à la mimine.

pas bien compris

Tu ne peux pas faire des appels à la libc depuis un noyau Unix pa rce
que la libc s'appuie sur le noyau. C'est le coup de la poule ou de
l'oeuf. Ça va mieux ?

c'est exactement là que je place l'hypothétique gain
l'idée consiste à imposer certaines contraintes par la déf inition du
langage ou de la librairie de manière à éviter tous les co ntrôles
dynamiques qui existent dans un os

un exemple histoire d'être plus clair un driver

public MyDriver :: Driver
{

}
ben cette simple notation me donne accès aux espaces d'adressages qu i
correspondent au hard et m'imposent un canal de communication pour les
applis qui ont besoin du hard ( l'imprimante par exemple)
pas besoin de savoir si je suis dans le noyau aux caraïbes ou à péta
ouchnouke je protège de manière structurelle mon hard et je ne fais pas
de test inutile

en gros l'idée consiste à gagner du temps processeur
en définissant en statique "définition du langage" tous le s contrôles
qui sont actuellement faits en dynamique contrôle sur les signa ux
protection mémoire etc

Exprime-toi correctement. C'est incompréhensible.

en plus si les threads sont bien pensés l'on peut faire du scal aire ou
du vrai parallélisme

Que le scalaire ou le vectoriel dépend plus de l'architecture q ue de
l'OS lui-même, mais on n'est plus à ça près...

pas d'accord ,bien sur que l'architecture rentre en ligne de compte
c'est évident, actuellement le parallélisme est très ma l géré, il se
résume à une augmentation de la charge mais pas à une a ugmentation de la
puissance de traitement

Je crois surtout que tu confonds allègrement scalaire, vectoriel et
parallèle. Parallèle ou non, c'est un concept qui vient de l 'OS (on
dira même multitâche ou multithread). Scalaire ou vectoriel, ça vient
de l'architecture matérielle. Parallèle, ce n'est pas le con traire de
scalaire.

je ne veux pas dire mais c'est ce que je dis
en gros je me répète

si les threads sont bien pensés l'on pourra utiliser tous les coeurs
d'une machine avec un seul thread maintenant on est d'accord ce n'est
pas du scalaire dans sa définition exacte du terme si cela peut te f aire
plaisir

quand pensez vous ?

Que tes produits sont vachement efficaces.

je suppose inefficace :-)

Non, ton dealer t'en a filé de la bonne.

pas vraiment, mais je pense que ce qui ne passe pas avec l'obj
c'est que l'obj impose une réflexion avant de coder contrairement au c
où l'on peut très souvent s'arranger disons que le degré d e liberté est
moindre et encore j'ai un doute, j'ai déjà codé à l'a rraché comme un
goret
tiens exemple mon algo de compression franchement je plains
l'inconscient qui veut lire le code :-)


remy

--
http://remyaumeunier.chez-alice.fr/