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 !
le wifi ne me sert a rien, bande passante trop basse pour faire du rend u reseau.
Il est question d'aller boire un verre en terrasse, pas de colorier des hulks.
A+ JF
Cumbalero
*.-pipolin-.* a écrit :
il n'y a que les réac dans ton genre pour ne pas savoir que le franç ais
Ne parle pas de ce que tu ne maitrises pas.
Il se trouve justement que les utilisateurs de cette prétendue nouvelle définition ne se rendent pas compte que c'est la personne qu'ils qualifient de bouffon qui se fout d'eux. Exactement comme le roi avec son bouffon.
Rien de nouveau, donc.
A+ JF
*.-pipolin-.* a écrit :
il n'y a que les réac dans ton genre pour ne pas savoir que le franç ais
Ne parle pas de ce que tu ne maitrises pas.
Il se trouve justement que les utilisateurs de cette prétendue nouvelle
définition ne se rendent pas compte que c'est la personne qu'ils
qualifient de bouffon qui se fout d'eux. Exactement comme le roi avec
son bouffon.
il n'y a que les réac dans ton genre pour ne pas savoir que le franç ais
Ne parle pas de ce que tu ne maitrises pas.
Il se trouve justement que les utilisateurs de cette prétendue nouvelle définition ne se rendent pas compte que c'est la personne qu'ils qualifient de bouffon qui se fout d'eux. Exactement comme le roi avec son bouffon.
Rien de nouveau, donc.
A+ JF
Professeur M
Le Tue, 15 Sep 2009 13:59:36 +0200, Cumbalero a écrit :
Répartir un traitement sur plusieurs machines, c'est précisément le contraire du multitâches.
qui plus est, si le travail se réparti bien, le trafic réseau entre machines n'est pas énorme et le coup de l'absence du wifi ne tiens pas la route.
Le Tue, 15 Sep 2009 13:59:36 +0200, Cumbalero a écrit :
Répartir un traitement sur plusieurs machines, c'est précisément le
contraire du multitâches.
qui plus est, si le travail se réparti bien, le trafic réseau entre
machines n'est pas énorme et le coup de l'absence du wifi ne tiens pas la
route.
Le Tue, 15 Sep 2009 13:59:36 +0200, Cumbalero a écrit :
Répartir un traitement sur plusieurs machines, c'est précisément le contraire du multitâches.
qui plus est, si le travail se réparti bien, le trafic réseau entre machines n'est pas énorme et le coup de l'absence du wifi ne tiens pas la route.
Toxico Nimbus
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.
-- Toxico Nimbus
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.
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.
-- Toxico Nimbus
Toxico Nimbus
Le Tue, 15 Sep 2009 13:58:08 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
14 coeurs pour une image. Voilà bien la qualité des softs utilisés, ou l'incapacité de l'utilisateur de s'en servir correctement!
Je vois pas le rapport entre le nombre de coeurs, la qualité des logiciels et la capacité de l'utilisateur.
-- Toxico Nimbus
Le Tue, 15 Sep 2009 13:58:08 +0200, Cumbalero a écrit :
*.-pipolin-.* a écrit :
14 coeurs pour une image. Voilà bien la qualité des softs utilisés, ou
l'incapacité de l'utilisateur de s'en servir correctement!
Je vois pas le rapport entre le nombre de coeurs, la qualité des
logiciels et la capacité de l'utilisateur.
Le Tue, 15 Sep 2009 13:59:36 +0200, Cumbalero a écrit :
je rend régulièrement des images en multi coeur, multimachine, sans aucun problèmes...
Mékilékon!
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.
-- Toxico Nimbus
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 :
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 !).
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 :
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 !).
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 :
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 !).
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
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.
-- 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 :
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.
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.
-- Toxico Nimbus
Bruno Ducrot
On 2009-09-15, Toxico Nimbus wrote:
Le Tue, 15 Sep 2009 13:59:36 +0200, Cumbalero a écrit :
je rend régulièrement des images en multi coeur, multimachine, sans aucun problèmes...
Mékilékon!
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. 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.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2009-09-15, Toxico Nimbus wrote:
Le Tue, 15 Sep 2009 13:59:36 +0200, Cumbalero a écrit :
je rend régulièrement des images en multi coeur, multimachine, sans
aucun problèmes...
Mékilékon!
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. 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.
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Le Tue, 15 Sep 2009 13:59:36 +0200, Cumbalero a écrit :
je rend régulièrement des images en multi coeur, multimachine, sans aucun problèmes...
Mékilékon!
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. 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.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
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 :
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.
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 :
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.
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 :
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.
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.
