et un petit dernier qui alloue les zones mémoire
et pour faire plaisir à jdk on ne l'appellera pas garbage collector
(je plaisante )
et un petit dernier qui alloue les zones mémoire
et pour faire plaisir à jdk on ne l'appellera pas garbage collector
(je plaisante )
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é.
C'est JKB que tu traites de JDK ? Je pense qu'il va adoré.
C'est JKB que tu traites de JDK ? Je pense qu'il va adoré.
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
4 fifo (4 niveaux de priorité)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo
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 )
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
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
en plus si les threads sont bien pensés l'on peut faire du scalaire ou
du vrai parallélisme
quand pensez vous ?
sans compter que pour les nostalgiques on peut le faire en c mais avec
des règles liées aux bibliothèques
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
4 fifo (4 niveaux de priorité)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo
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 )
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
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
en plus si les threads sont bien pensés l'on peut faire du scalaire ou
du vrai parallélisme
quand pensez vous ?
sans compter que pour les nostalgiques on peut le faire en c mais avec
des règles liées aux bibliothèques
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
4 fifo (4 niveaux de priorité)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo
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 )
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
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
en plus si les threads sont bien pensés l'on peut faire du scalaire ou
du vrai parallélisme
quand pensez vous ?
sans compter que pour les nostalgiques on peut le faire en c mais avec
des règles liées aux bibliothèques
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
OpenJDK fonctionne pas mal et pourrait bien devenir la version de
référence de ce truc non normalisé.
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.
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.
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.
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 ?
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.
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...
quand pensez vous ?
Que tes produits sont vachement efficaces.
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 .
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
OpenJDK fonctionne pas mal et pourrait bien devenir la version de
référence de ce truc non normalisé.
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.
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.
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.
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 ?
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.
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...
quand pensez vous ?
Que tes produits sont vachement efficaces.
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 .
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
OpenJDK fonctionne pas mal et pourrait bien devenir la version de
référence de ce truc non normalisé.
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.
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.
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.
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 ?
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.
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...
quand pensez vous ?
Que tes produits sont vachement efficaces.
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 .
quand pensez vous ?
quand pensez vous ?
quand pensez vous ?
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éveloppeursont 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
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
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
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é)
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
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
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 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
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é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
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
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
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é)
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
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
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 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
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éveloppeursont 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
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
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
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é)
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
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
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 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
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
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
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
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é"
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é"
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é"
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é)
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é)
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é)
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.
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éveloppeursont 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.
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.
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.
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.
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 ?
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.
quand pensez vous ?
Que tes produits sont vachement efficaces.
je suppose inefficace :-)
Non, ton dealer t'en a filé de la bonne.
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.
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.
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.
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.
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.
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 ?
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.
quand pensez vous ?
Que tes produits sont vachement efficaces.
je suppose inefficace :-)
Non, ton dealer t'en a filé de la bonne.
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.
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éveloppeursont 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.
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.
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.
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.
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 ?
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.
quand pensez vous ?
Que tes produits sont vachement efficaces.
je suppose inefficace :-)
Non, ton dealer t'en a filé de la bonne.