Pour 69 Euros, vous aurez une zolie boîte Limux mandriva "Powerpack"
(parce que c'est pas pour les xxjssus) 2009 Spring
Et vous bénéficierez d'un support gratuit de 3 mois pour installer ce
bazarre, en espérant que vous y arriverez
Voici ce qui est écrit sur la boîte
(Les commentaires entre paranthèse sont de moi; en imaginant
l'utilisateur lambda qui va se lancer dans l'aventure)
- Libérer votre ordinateur
(LOL, de quoi ? Du capitalisme ? De la grippe porcine ? Des Américains
?)
- Un environnement qui vous ressemble
(En général, le marketing devrait avoir pour objectif de vous faire
réver, mais là c'est fichu ;>)
- Quand sécurité rime avec simplicité
(Hohohoh, on sent que ca va être la teuf durant quelques mois à la
maison, et que chérie va pas être trop servie...)
- 2 DVD - 1 manuel - 1 guide de démarrage
(Bon, il va falloir suivre le guide de démarrage pour démarrer, puis
ensuite lire le manuel....à moins que ce soit l'inverse...Zut, il y'a
des choses à lire...)
Et dans le descriptif du produit...
- une gamme de logiciels complémentaires, afin d'améliorer votre
expérience
(A parce que l'eXPérience de Linux ne suffit pas, il faut encore mettre
des logiciels complémentaires....???)
- des logiciels en version d'essai afin de découvrir de nouveaux outils
(Ohohoho, zut alors, je croyais que Linux était gratos, déjà que la
bôite m'a pompé 60 Euros...)
Mais que contient EXACTEMENT tous ces DVD ? J'ai voulu en savoir un peu
plus, et voici ce qui me vient à l'esprit en lisant tout cela
Extrait:
Système
•Kernel Linux 2.6.29.1 (Ah super, c'est koi ?)
•X.org 1.6.1 (Cool, c'est VRAIMENT utile ?)
•Drivers Wifi (Ben voyons, manquerait plus que cela ...)
•Drivers ATI, Intel, nVidia (Idem...)
•ISO hybride (C'est komme ISO 90000 ? J'suis pas dans les assurances)
Interfaces graphiques
•KDE 4.2.2 (Trop bien !)
•GNOME 2.26.1 (Toi même !)
•LXDE (heinnnnnnn ?)
Dans le dépôt en ligne contrib :
•XFCE 4.6 (??????)
•Sugar (Attention les dents...)
Applications majeures
•Mozilla Firefox 3.0.8 (Y'a pas le 3.5 ?)
•OpenOffice.org 3.0.1 (Y'a pas le 3.1 ?)
•VirtualBox 2.2.0 (Hein....?)
•Elisa 0.5.35 (Hein quoi ....?)
•FileZilla 3.2.3 (???)
•Skype 2.0.0.72 (Heu c'est vieux ca...)
•Opera 9.64 (Je préfère le RAP)
•Flash Player 10.0.22.87 (Nah, Flash Gordon, abrupti)
•Google Earth 5.0 (Wouahou)
•Google Picasa 2.7 (Bôf)
•GCompris 8.4.9 (Ben pas moi)
•Acrobat Reader 8.1.4 (Pfff, on est au 9.1)
•VMWare 2.5.2 (Héhéhé, sur Emule j'ai crack la 6.5, le gourou c'est moi
;>)
Outils Mandriva
•Contrôle parental (Maman rentre pas dans ma chambre)
•Configuration réseau (Js'ai faire ca tout seul)
•Draksnapshot (Ca se prononce côment ?)
•Firewall interactif (?)
•Migration depuis Windows (Yo, je vais faire la mise à jour ce soir)
•Gestion des disques durs (Gérer koi ?)
•Configuration du serveur X (Héhéhé, faut pas que maman voie ca ;>)
•Installeur graphique (Graphique comment ? le truc du cube ?)
Jeux natifs (Ouai c'est top cool, mais je peux mettre les jeux PC ?)
•Armagetron
•Cannon Smash
•Extreme Tux Racer
•Freeciv
•Frozen Bubble
•OpenArena
•SuperTux
•Tux Paint
•Wesnoth
•Wormux
•XMoto
Développement (Dévlopper quoi ?)
•gcc 4.3.2
•Qt 4.5
•Tcl/Tk 8.6
•Qt Creator
•Serveurs web Apache, lighttpd
•Perl, PHP, Python, Ruby (Rails)
•MySQL, PostgreSQL, SQLite
•et bien plus...
Plus de 70 langues (Wahou, mais je parle que le francais)
•allemand
•anglais
•espagnol
•danois
•finlandais
•français
•grec
•italien
•norvégien
•portugais, brésilien
•russe
•suédois
•et bien plus...
Quelques années plus tard, sur les forums de discussions si méconnus,
nous ne trouvions plus que 2 intervenants sur USENET, les autres ayant
depuis lontemps migrés sur TéléPath, enfin, seulement ceux qui
utilisaient Windows ;>)
--
De Yo GIGI - IP 1fff:0000:0a88:85a3:0000:0000:ac1f:8001
--
Yô !
J'essaye de configurer ma carte WIFI
(E5UUT9833KKlllE-CDDFI899-EUREJJSHE-489438489438438438943-EMSJSJJJjjeJJjwjw-JSJSJSJSSIOS)
avec le firmware 0.984383833,4555:998) mais j'arrive pas à capter mon
DHCP, alors que j'ai bien installé préalablement les librairies
trouvées sur USENET
La version du kernel est 6.045393902932Z:RC93 et pourtant j'arrive pas
à recomplier ce &*4""6% de noyau, qui me fait le message
>> kdb/modules/kdbm_pg.c:349: error: implicit declaration
>> of function 'PageChecked'
>> kdb/modules/kdbm_pg.c: In function 'kdbm_inode':
>> kdb/modules/kdbm_pg.c:507: error: 'struct inode' has no
>> member named 'u'
Je fait ifconfig -a, et ma carte est pas eth1, mais eth4, comment la
renommer à eth1 ? (Pasque eth0, ca peut pas marcher avec le zéro)
J'essaye depuis KDE 9.9453, mais c'est pas ok, alors qu'il me semble
que le ping marchait avec KDE9.9452
Avez-vous essayé avec Gnome 12.4933 Release C ?
Je connais toutes mes adresses IP par coeur à force de les rentrer à la
main...
Piss and Love, Hate Windows !
---
Réponse d'un gourou (avec une trèèèès loongue barbe blanche, style
"Seigneur des anneaux")
--
De Professeur Méfistoi - IP 1f67:0440:0a88:85a3:0020:0060:ac1f:8001
--
C'est bien, mais je pense plutôt que tu devrais essayer ceci
vi /etc/network/interfaces
Remplacer eth4 par eth0 et enregistrer avec wq
Tu sais, on a tous passé par là, mais tu vois, si tu passes à Windows
8, tu ne comprendras jamais comment fonctionne VRAIMENT ton ordinateur,
et tu seras pour toujours un neuneu Krtotiens indigne de la
reconnaissance des autres, tu feras partie pour toujours de la France
du bas, alors que là, t'est dans l'Elite !
Jérémie Bottone vous souhaite une bonne fin de semaine, et souhaite que
vous puissiez rapidement passer la précommande Windows 7 !
Répartir un traitement sur plusieurs machines, c'est précisément le contraire du multitâches.
Non. Le multitâche, c'est quand un SE fait plusieurs choses en simultané. Quelque soit le nombre de processeurs/coeurs/machines.
Non. Ce que decrit Pipolin, c'est du multi-threading, et non du multitache.
Et selon toi, le multi-threading ne serait pas une forme de multitâche ?
Pour un non-informaticien, on ne ferra pas la remarque, mais pour Pipolin, il faut croire qu'on lui ferra quand-meme. C'est un peu comme pour les notions de sauvegarde et d'archivage. Un non-informaticien (comme Pipolin) confond souvent les deux, mais un informaticien poli ne ferra pas normalement la remarque, sachant que de toute facon ce n'est pas vraiment important dans le cadre d'une informatique dosmetique.
C'est surtout l'envie de cartonner Pipolin, quoi qu'il dise.
-- Toxico Nimbus
Bruno Ducrot a écrit :
Répartir un traitement sur plusieurs machines, c'est précisément le
contraire du multitâches.
Non. Le multitâche, c'est quand un SE fait plusieurs choses en
simultané. Quelque soit le nombre de processeurs/coeurs/machines.
Non. Ce que decrit Pipolin, c'est du multi-threading, et non du
multitache.
Et selon toi, le multi-threading ne serait pas une forme de multitâche ?
Pour un non-informaticien, on ne ferra pas la remarque,
mais pour Pipolin, il faut croire qu'on lui ferra quand-meme. C'est un
peu comme pour les notions de sauvegarde et d'archivage. Un
non-informaticien (comme Pipolin) confond souvent les deux, mais un
informaticien poli ne ferra pas normalement la remarque, sachant que de
toute facon ce n'est pas vraiment important dans le cadre d'une
informatique dosmetique.
C'est surtout l'envie de cartonner Pipolin, quoi qu'il dise.
Répartir un traitement sur plusieurs machines, c'est précisément le contraire du multitâches.
Non. Le multitâche, c'est quand un SE fait plusieurs choses en simultané. Quelque soit le nombre de processeurs/coeurs/machines.
Non. Ce que decrit Pipolin, c'est du multi-threading, et non du multitache.
Et selon toi, le multi-threading ne serait pas une forme de multitâche ?
Pour un non-informaticien, on ne ferra pas la remarque, mais pour Pipolin, il faut croire qu'on lui ferra quand-meme. C'est un peu comme pour les notions de sauvegarde et d'archivage. Un non-informaticien (comme Pipolin) confond souvent les deux, mais un informaticien poli ne ferra pas normalement la remarque, sachant que de toute facon ce n'est pas vraiment important dans le cadre d'une informatique dosmetique.
C'est surtout l'envie de cartonner Pipolin, quoi qu'il dise.
-- Toxico Nimbus
Bruno Ducrot
On 2009-09-15, JKB wrote:
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je double le nombre de coeur sur le rendu d'une image, ça réduit presque de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure de la scène -, chaque coeur écrit à un emplacement différent en mémoire, les temps de calculs sont trop grands pour provoquer un goulot d'étrangelement au niveau du /writeback/. Toutes les conditions me semblent réunies pour que le temps de calcul soit effectivement divisé par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone _simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit récursif), tu accèdes aux données et tu réécris sur les mêmes données. Théoriquement, tu peux donc diviser ton temps de calcul par le nombre d'unités de calcul différentes. Pratiquement, les OS ne fournissent pas la granularité nécessaire pour attendre cette limite. Donc dans le cas général, c'est faux.
Pipolin parlait d'un rendu, et non d'un traitement d'image. On peut donc imaginer que chaque coeur ecrit dans sa propre zone memoire correspondant a la portion d'image qui doit etre rendu.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2009-09-15, JKB wrote:
Le 15-09-2009, ? propos de
Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long),
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de
Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et
demain - long),
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je
double le nombre de coeur sur le rendu d'une image, ça réduit presque
de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure de
la scène -, chaque coeur écrit à un emplacement différent en mémoire,
les temps de calculs sont trop grands pour provoquer un goulot
d'étrangelement au niveau du /writeback/. Toutes les conditions me
semblent réunies pour que le temps de calcul soit effectivement divisé
par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de
verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les
sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone
_simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le
nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les
verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du
logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce
cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit
récursif), tu accèdes aux données et tu réécris sur les mêmes
données. Théoriquement, tu peux donc diviser ton temps de calcul par
le nombre d'unités de calcul différentes. Pratiquement, les OS ne
fournissent pas la granularité nécessaire pour attendre cette
limite. Donc dans le cas général, c'est faux.
Pipolin parlait d'un rendu, et non d'un traitement d'image. On peut
donc imaginer que chaque coeur ecrit dans sa propre zone memoire
correspondant a la portion d'image qui doit etre rendu.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je double le nombre de coeur sur le rendu d'une image, ça réduit presque de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure de la scène -, chaque coeur écrit à un emplacement différent en mémoire, les temps de calculs sont trop grands pour provoquer un goulot d'étrangelement au niveau du /writeback/. Toutes les conditions me semblent réunies pour que le temps de calcul soit effectivement divisé par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone _simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit récursif), tu accèdes aux données et tu réécris sur les mêmes données. Théoriquement, tu peux donc diviser ton temps de calcul par le nombre d'unités de calcul différentes. Pratiquement, les OS ne fournissent pas la granularité nécessaire pour attendre cette limite. Donc dans le cas général, c'est faux.
Pipolin parlait d'un rendu, et non d'un traitement d'image. On peut donc imaginer que chaque coeur ecrit dans sa propre zone memoire correspondant a la portion d'image qui doit etre rendu.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Toxico Nimbus
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je double le nombre de coeur sur le rendu d'une image, ça réduit presque de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure de la scène -, chaque coeur écrit à un emplacement différent en mémoire, les temps de calculs sont trop grands pour provoquer un goulot d'étrangelement au niveau du /writeback/. Toutes les conditions me semblent réunies pour que le temps de calcul soit effectivement divisé par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone _simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit récursif), tu accèdes aux données et tu réécris sur les mêmes
données.
Théoriquement, tu peux donc diviser ton temps de calcul par le
nombre
d'unités de calcul différentes. Pratiquement, les OS ne
fournissent pas
la granularité nécessaire pour attendre cette limite. Donc dans
le cas
général, c'est faux.
Pourquoi serait-ce récursif ? Si je fais du ray-tracing, je traite pixel par pixel, sur une même image, sans la moindre récursivité. S'il y a post- traitement, ce sera fait globalement sur l'image dans la passe suivante.
Si j'ai plusieurs processeurs, soit je calcule plusieurs images en même temps, soit je délimite des zones différentes de mon image. Dans tous les cas les unités de calcul accèdent à des parties différentes de la mémoire (en écriture du moins). Si la granularité de l'OS me gène (SMP par exemple), je m'en débarrasse en verrouillant chaque thread sur un processeur particulier avec une priorité temps-réel (je pars du principe que je suis sous Windows puisqu'on parle des machines de Pipolin dès le début).
-- Toxico Nimbus
JKB a écrit :
Le 15-09-2009, ? propos de
Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et
demain - long),
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de
Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et
demain - long),
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je
double le nombre de coeur sur le rendu d'une image, ça réduit
presque de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure
de la scène -, chaque coeur écrit à un emplacement différent en
mémoire, les temps de calculs sont trop grands pour provoquer un
goulot d'étrangelement au niveau du /writeback/. Toutes les
conditions me semblent réunies pour que le temps de calcul soit
effectivement divisé par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de
verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les
sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone
_simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le
nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les
verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du
logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce
cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit
récursif), tu accèdes aux données et tu réécris sur les mêmes
données.
Théoriquement, tu peux donc diviser ton temps de calcul par le
nombre
d'unités de calcul différentes. Pratiquement, les OS ne
fournissent pas
la granularité nécessaire pour attendre cette limite. Donc dans
le cas
général, c'est faux.
Pourquoi serait-ce récursif ? Si je fais du ray-tracing, je traite pixel
par pixel, sur une même image, sans la moindre récursivité. S'il y a post-
traitement, ce sera fait globalement sur l'image dans la passe suivante.
Si j'ai plusieurs processeurs, soit je calcule plusieurs images en même
temps, soit je délimite des zones différentes de mon image. Dans tous les
cas les unités de calcul accèdent à des parties différentes de la mémoire
(en écriture du moins). Si la granularité de l'OS me gène (SMP par
exemple), je m'en débarrasse en verrouillant chaque thread sur un
processeur particulier avec une priorité temps-réel (je pars du principe
que je suis sous Windows puisqu'on parle des machines de Pipolin dès le
début).
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je double le nombre de coeur sur le rendu d'une image, ça réduit presque de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure de la scène -, chaque coeur écrit à un emplacement différent en mémoire, les temps de calculs sont trop grands pour provoquer un goulot d'étrangelement au niveau du /writeback/. Toutes les conditions me semblent réunies pour que le temps de calcul soit effectivement divisé par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone _simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit récursif), tu accèdes aux données et tu réécris sur les mêmes
données.
Théoriquement, tu peux donc diviser ton temps de calcul par le
nombre
d'unités de calcul différentes. Pratiquement, les OS ne
fournissent pas
la granularité nécessaire pour attendre cette limite. Donc dans
le cas
général, c'est faux.
Pourquoi serait-ce récursif ? Si je fais du ray-tracing, je traite pixel par pixel, sur une même image, sans la moindre récursivité. S'il y a post- traitement, ce sera fait globalement sur l'image dans la passe suivante.
Si j'ai plusieurs processeurs, soit je calcule plusieurs images en même temps, soit je délimite des zones différentes de mon image. Dans tous les cas les unités de calcul accèdent à des parties différentes de la mémoire (en écriture du moins). Si la granularité de l'OS me gène (SMP par exemple), je m'en débarrasse en verrouillant chaque thread sur un processeur particulier avec une priorité temps-réel (je pars du principe que je suis sous Windows puisqu'on parle des machines de Pipolin dès le début).
-- Toxico Nimbus
Bruno Ducrot
On 2009-09-15, Toxico Nimbus wrote:
Bruno Ducrot a écrit :
Répartir un traitement sur plusieurs machines, c'est précisément le contraire du multitâches.
Non. Le multitâche, c'est quand un SE fait plusieurs choses en simultané. Quelque soit le nombre de processeurs/coeurs/machines.
Non. Ce que decrit Pipolin, c'est du multi-threading, et non du multitache.
Et selon toi, le multi-threading ne serait pas une forme de multitâche ?
Je sais ce qu'est une tache multi-threadee, mais je vois mal comment est fabrique un thread mutitache.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2009-09-15, Toxico Nimbus wrote:
Bruno Ducrot a écrit :
Répartir un traitement sur plusieurs machines, c'est précisément le
contraire du multitâches.
Non. Le multitâche, c'est quand un SE fait plusieurs choses en
simultané. Quelque soit le nombre de processeurs/coeurs/machines.
Non. Ce que decrit Pipolin, c'est du multi-threading, et non du
multitache.
Et selon toi, le multi-threading ne serait pas une forme de multitâche ?
Je sais ce qu'est une tache multi-threadee, mais je vois mal comment
est fabrique un thread mutitache.
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Le Tue, 15 Sep 2009 13:56:10 +0000, Toxico Nimbus a écrit :
C'est surtout l'envie de cartonner Pipolin, quoi qu'il dise.
pull !
JKB
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je double le nombre de coeur sur le rendu d'une image, ça réduit presque de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure de la scène -, chaque coeur écrit à un emplacement différent en mémoire, les temps de calculs sont trop grands pour provoquer un goulot d'étrangelement au niveau du /writeback/. Toutes les conditions me semblent réunies pour que le temps de calcul soit effectivement divisé par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone _simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit récursif), tu accèdes aux données et tu réécris sur les mêmes
données.
Théoriquement, tu peux donc diviser ton temps de calcul par le
nombre
d'unités de calcul différentes. Pratiquement, les OS ne
fournissent pas
la granularité nécessaire pour attendre cette limite. Donc dans
le cas
général, c'est faux.
Pourquoi serait-ce récursif ? Si je fais du ray-tracing, je traite pixel par pixel, sur une même image, sans la moindre récursivité. S'il y a post- traitement, ce sera fait globalement sur l'image dans la passe suivante.
Si j'ai plusieurs processeurs, soit je calcule plusieurs images en même temps, soit je délimite des zones différentes de mon image. Dans tous les cas les unités de calcul accèdent à des parties différentes de la mémoire (en écriture du moins). Si la granularité de l'OS me gène (SMP par exemple), je m'en débarrasse en verrouillant chaque thread sur un processeur particulier avec une priorité temps-réel (je pars du principe que je suis sous Windows puisqu'on parle des machines de Pipolin dès le début).
Je parle en _général_. Le seul traitement que je fais, c'est du traitement du signal (et dans ce cas, c'est faux) et je ne lis plus pipotruc qui est dans ma boitakon depuis très longtemps.
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.
Le 15-09-2009, ? propos de
Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long),
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de
Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et
demain - long),
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de
Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et
demain - long),
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je
double le nombre de coeur sur le rendu d'une image, ça réduit
presque de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure
de la scène -, chaque coeur écrit à un emplacement différent en
mémoire, les temps de calculs sont trop grands pour provoquer un
goulot d'étrangelement au niveau du /writeback/. Toutes les
conditions me semblent réunies pour que le temps de calcul soit
effectivement divisé par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de
verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les
sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone
_simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le
nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les
verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du
logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce
cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit
récursif), tu accèdes aux données et tu réécris sur les mêmes
données.
Théoriquement, tu peux donc diviser ton temps de calcul par le
nombre
d'unités de calcul différentes. Pratiquement, les OS ne
fournissent pas
la granularité nécessaire pour attendre cette limite. Donc dans
le cas
général, c'est faux.
Pourquoi serait-ce récursif ? Si je fais du ray-tracing, je traite pixel
par pixel, sur une même image, sans la moindre récursivité. S'il y a post-
traitement, ce sera fait globalement sur l'image dans la passe suivante.
Si j'ai plusieurs processeurs, soit je calcule plusieurs images en même
temps, soit je délimite des zones différentes de mon image. Dans tous les
cas les unités de calcul accèdent à des parties différentes de la mémoire
(en écriture du moins). Si la granularité de l'OS me gène (SMP par
exemple), je m'en débarrasse en verrouillant chaque thread sur un
processeur particulier avec une priorité temps-réel (je pars du principe
que je suis sous Windows puisqu'on parle des machines de Pipolin dès le
début).
Je parle en _général_. Le seul traitement que je fais, c'est du
traitement du signal (et dans ce cas, c'est faux) et je ne lis plus
pipotruc qui est dans ma boitakon depuis très longtemps.
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.
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 15-09-2009, ? propos de Re: N'acheter pas Windows à 50 Euros ! (Histoire d'aujourd'hui et demain - long), Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :
Le Tue, 15 Sep 2009 13:56:18 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
ha oué, c'est vrai, je suis trop con pour pouvoir dire que quand je double le nombre de coeur sur le rendu d'une image, ça réduit presque de moitié le temps de rendus ...
Mouahahahaha!
Mékilékon.
Tous les coeurs accèdent aux même données en lecture - la structure de la scène -, chaque coeur écrit à un emplacement différent en mémoire, les temps de calculs sont trop grands pour provoquer un goulot d'étrangelement au niveau du /writeback/. Toutes les conditions me semblent réunies pour que le temps de calcul soit effectivement divisé par le nombre de coeurs.
Pour justement faire dans le traitement du signal parallélisable,
c'est
un peu plus compliqué que ça, même si on accède aux données en
lecture
et qu'on écrit à des emplacements différents car les mécanismes de verrouillage ne peuvent être gérés dans la plupart des cas au
niveau de
la donnée élémentaire. mprotect() n'est d'aucune utilité (il
verrouille
des pages _complètes) et les mécanismes comme les mutexes ou les sémaphores ne savent pas si on accède en lecture ou en écriture
(et que
l'écriture n'étant pas forcément atomique, la lecture de la zone _simultanément_ peut donner des choses assez cocasses !).
Bref, on peut s'attendre à une division du temps de calcul par le nombre de coeurs, mais lorsqu'on tape dans les mêmes données en
lecture
et en écriture, il faut se battre pour observer une division
_dans le
cas général_ de plus de la moitié des coeurs (d'autant que les verrouillages peuvent assez rapidement bouffer jusqu'à 20% du
temps CPU
!).
Je parlais du point de vue strictement matériel. Pour ce qui est du logiciel, je ne vois pas l'utilité de protéger quoi que ce soit dans ce cas là puisqu'on est sur d'écrire dans des zones différentes.
Quand tu fais un traitement sur une image (pour peu que ce soit récursif), tu accèdes aux données et tu réécris sur les mêmes
données.
Théoriquement, tu peux donc diviser ton temps de calcul par le
nombre
d'unités de calcul différentes. Pratiquement, les OS ne
fournissent pas
la granularité nécessaire pour attendre cette limite. Donc dans
le cas
général, c'est faux.
Pourquoi serait-ce récursif ? Si je fais du ray-tracing, je traite pixel par pixel, sur une même image, sans la moindre récursivité. S'il y a post- traitement, ce sera fait globalement sur l'image dans la passe suivante.
Si j'ai plusieurs processeurs, soit je calcule plusieurs images en même temps, soit je délimite des zones différentes de mon image. Dans tous les cas les unités de calcul accèdent à des parties différentes de la mémoire (en écriture du moins). Si la granularité de l'OS me gène (SMP par exemple), je m'en débarrasse en verrouillant chaque thread sur un processeur particulier avec une priorité temps-réel (je pars du principe que je suis sous Windows puisqu'on parle des machines de Pipolin dès le début).
Je parle en _général_. Le seul traitement que je fais, c'est du traitement du signal (et dans ce cas, c'est faux) et je ne lis plus pipotruc qui est dans ma boitakon depuis très longtemps.
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.
Toxico Nimbus
Bruno Ducrot a écrit :
Et selon toi, le multi-threading ne serait pas une forme de multitâche ?
Je sais ce qu'est une tache multi-threadee, mais je vois mal comment est fabrique un thread mutitache.
Une tache n'est pas forcément un processus. Sur un système multithreads, une tache, c'est un thread, sinon c'est un processus.
-- Toxico Nimbus
Bruno Ducrot a écrit :
Et selon toi, le multi-threading ne serait pas une forme de multitâche
?
Je sais ce qu'est une tache multi-threadee, mais je vois mal comment est
fabrique un thread mutitache.
Une tache n'est pas forcément un processus.
Sur un système multithreads, une tache, c'est un thread, sinon c'est un
processus.
