Ultimate config!
- 3 067 réponses
- 214 participants
- 109 983 vues
- 190 followers
yodan
Ca consisterait à établir presque au jour le jour une config informatique "idéal", "la" config audiofanzine ! Genre mise à jour tous les mois, suffirait de cliquer sur un lien pour obtenir la config du mois, testée et approuvée par les afiens... (je passe les possibilités de liens vers des mags info pour des prix défiants toute concurrence...)
Je précise... : hors cartes sons, et tout matos musical bien entendu! juste de la technologie informatique qui tourne... Et à un prix moyen évidement, il n'est pas question de matos genre pc à 4000€, j'espère que ca tourne à ce prix là...
Enfin je me comprends...
Je jette l'idée dans la nature...
J'aurais ptete du poster dans "fonctionnalité"...
Faut que je me calme avec les ""et les "..." ...
Voili!!!
Transblack
J'ai finalement choisi la G Skill extreme 6400 PK pour son CAS 4-4-4-12 en 2x1Go (on passera à 4 quand il faudra installer VISTA ... )
Merci pour les avis
nonconforme
Citation : Bah justement honnêtement je voie pas pourquoi. Aucun Soft actuel n'est réellement optimisé pour le quad core. Ils le sont déjà pas vraiment pour le dual core.
J'ai testé Tracktion et Reaper qui savent faire tourner le quadcore. pas testé Cubase 4 et depuis que j'ai Reaper je ne pense plus retourner sur Cubase...
et pour les PCs tout prêts pensez à regarder chez DELL. Je ne touche pas de com chez eux, mais je trouve qu'ils sont bien placés.
Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering
Anonyme
Citation : J'ai testé Tracktion et Reaper qui savent faire tourner le quadcore.
Entre créer 4 threads interdépendants et créer un système réellement optimisé pour le quad core il y a une marge et je me demande si réellement qui que ce soit pour l'instant l'a franchie.
nonconforme
Citation : un système réellement optimisé pour le quad core
Je suis curieux que tu expliques ce que tu entends par là, même si c'est un peu en HS. ;)
Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering
marssu
Anonyme
nonconf < je me rend compte que c'est pas si simple que ça de formuler clairement ce que je pense.
Est-ce qu'un système pleinement optimisé pour le multi-core ne serait pas tout simplement un logiciel dont les threads ne passe pas leur temps à dormir en attendant ques les autres fassent leur travail !?
Exemple : un instrument virtuel qui tourne dans un thread... Il faut qu'il recoive des notes à jouer pour pouvoir travailer. En attendant il dort.
Là il peut générer le son indépendement du reste du monde.
Puis ensuite il faut qu'il envoie le son qu'il a généré à son hôte.
Là encore ça bloque : l'hôte à plusieurs vst à traiter...
Ca pourrait même être pire : si plusieurs instruments virtuels faisaient du streaming. Les threads dormiraient un laps de temps à chaque fois qu'ils invoqueraient un accès disque, en attendant que la ressource soit disponible.
nonconforme
Et à priori l'OS sait gérer les threads qui dorment et ne demandent pas de ressources. Pour les accès disque, à moins d'avoir des accès parallèles, il n'y a qu'un système de file d'attente, d'où l'utilité d'avoir beaucoup de ram pour chaque coeur.
Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering
Anonyme
Citation : Et à priori l'OS sait gérer les threads qui dorment et ne demandent pas de ressources
Justement c'est bien ça le problème : un thread qui dort ne fait rien.
Je serais curieux de savoir ce qu'apporte en terme de gain de performance un processus multi-threadé par rapport a un processus qui fait exactement la même chose dans un thread unique.
nonconforme
Et si un thread dort il n'empêche pas l'exécution d'autres threads qui ont besoin de ressources. C'est justement ça qui est géré par l'OS.
Le problème des multicoeur arrive quand tu as des calculs peu parallélisables, du genre pour les jeux vidéos, où le gain de performance est proche de 0, à moins bien sûr d'encoder des DIVX pendant que tu joues...
Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering
marssu
j'ai pas dis windows ne savait pas gérer le multi pros ou le multi core ou les CPU 64bits...
Je dis unix est optimisé pour cela depuis très longtemps....c'est pas "supporte" que je dis, Je dis est conçu pour en tirer le maximum...
- < Liste des sujets
- Charte