Linux: Prozesse und Threads in einem Multi-core-CPU

Ist es wahr, dass threads im Vergleich zu Prozessen, sind weniger wahrscheinlich, profitieren von einer multi-core-Prozessor? In anderen Worten, würde der kernel die Entscheidung des threads auf einem single-core anstatt auf mehrere Kerne?

Ich Rede von threads desselben Prozesses.

InformationsquelleAutor someguy | 2010-08-03
  1. 9

    Ich weiß nicht, wie die (verschiedene) Linux-scheduler damit umgehen, aber inter-thread-Kommunikation wird teurer, wenn die threads laufen auf verschiedenen Kernen.

    So kann der Planer entscheiden, laufen die threads eines Prozesses auf der gleichen CPU wenn es andere Prozesse benötigen CPU-Zeit.

    ZB mit einem Dual-Core-CPU, wenn es zwei Prozesse mit zwei threads und alle sind mit allen CPU-Zeit, die Sie bekommen, ist es besser zu laufen, die zwei threads von dem ersten Prozess auf dem ersten Core und die zwei Fäden, die von dem anderen Prozess auf dem zweiten Kern.

    • Ich fand das wirklich hilfreich, danke.
    InformationsquelleAutor IanH
  2. 2

    Das ist mir neu. Linux im speziellen, macht wenig Unterschied zwischen threads und Prozessen. Sie sind wirklich nur Prozesse, die teilen Ihre-Adresse-Raum.

    • Es ist anscheinend irgendwo in der Dokumentation. Würde ich eher nehmen Ihr Wort für es ist als ein vages Gerücht, aber.
    • Blick auf die clone () - Systemcall.
    InformationsquelleAutor Marcelo Cantos
  3. 2

    Mehrere single-threaded Prozesse sind teurer, um das system als einziges multi-threaded lieben. Aber Sie profitieren von multicore-CPU mit gleicher Effizienz. Plus inter-thread-Kommunikation ist viel billiger als inter-Prozess-Kommunikation. Wenn diese threads wirklich form eine einzige Anwendung, die ich Stimme für multithreading.

    • "Aber Sie profitieren von multicore-CPU mit gleicher Effizienz." Durch "Sie", sprechen Sie über Prozesse oder threads? Das "aber" verwirrt mich, tut mir Leid.
    • das ist nicht wahr, zwei threads vom gleichen Prozess auf die verschiedenen Prozessorkerne benötigen viel Speicher/cache-Synchronisation, die ist nicht nötig für getrennte Prozesse
    • das ist nicht wahr, wenn Sie schreiben müssen, gleichzeitig auf den gemeinsam genutzten Speicher, Speicher-Kohärenz-Kosten gelten unabhängig von threads oder Prozessen. die OS Zeitpläne threads und Prozesse, die CPU-Kerne nur Explosion durch was auch immer-Programm-Zähler, die Sie übergeben. die meisten mainstream-Prozessoren haben mindestens eine gemeinsame cache-Stufe, und neugierigen Augen geschützt, schreibt, um die Erinnerung anzuzeigen kohärente, ohne Umweg über den Arbeitsspeicher. wo wird dies deutlich teurer ist als die gemeinsame Nutzung von Speicher zwischen mehreren CPUs, aber es ist gleich schlecht, unabhängig davon, wo der gemeinsame Zugriff stammt aus
    InformationsquelleAutor Andrey
  4. 2

    Shared-memory multithreading auferlegt, enorme Komplexität, Kosten, auf alles, was von Ihrem tool-Kette, zur Entwicklung, zum debugging, Argumentation, und testen Sie Ihren code. Verwenden Sie NIEMALS shared-memory multithreading, wo man davon ausgehen kann, verwenden Sie ein multi-Prozess-design.

    @Marcelo ist richtig, jeder anständige OS behandeln werde, threads und Prozesse sehr ähnlich, einige der cpu-Affinität für threads kann die Verringerung der multi-Prozessor Nutzung von multi-threaded-Prozess, aber Sie sollten sehen, dass mit zwei beliebigen Prozessen, die eine gemeinsame .text-segment als auch.

    Pick-threads vs. Prozesse basierend auf Komplexität und architektonischen design-Einschränkungen, die Geschwindigkeit wird fast nie kommen.

    • Ich bin damit einverstanden, dass design sollte zuerst kommen, aber Sie widersprechen sich selbst, wenn Sie sagen, "nie mit shared-memory multithreading". Ich verstehe, was du meinst mit threads wird immer komplexer, aber es ist eine übertreibung. Ich werde stick mit die Verwendung von threads, es sei denn, es macht Sinn, Prozesse nutzen (vielleicht für ein "multi-document" Anwendung).
    InformationsquelleAutor Recurse
  5. 1

    Es eigentlich hängt alles von dem scheduler, der Art des multiprocessing und aktuellen Umgebung.

    Davon ausgehen, nichts, testen, testen, testen!

    Wenn Sie nur multi-threaded-Prozess auf dem system, multi-threading ist im Allgemeinen eine gute Idee.

    Jedoch, aus der Perspektive der einfachen Entwicklung, manchmal möchte man getrennte Adress-Räume und gemeinsam genutzten Daten, insbesondere in NUMA-Systemen.

    Eine Sache ist sicher: Wenn es eine 'HyperThreaded' system-threads sind viel effizienter Kraft schließen-Speicher freigeben.

    Ob es eine regelmäßige multi-core-Verarbeitung.. es sollte ähnlich sein.

    Wenn es ein NUMA-system, sind Sie besser dran halten freigegebenen Daten und code zu trennen. Wieder, es ist alle Architektur abhängig, und es spielt keine Rolle, performance-Weise, es sei denn, Sie sind in der HPC-Geschäft.

    Wenn Sie sind in der HPC (supercomputing) business, TESTEN!. Es ist alles Maschine abhängig (und die Vorteile sind 10-25% im Durchschnitt, es wichtig ist, wenn du redest Tage Unterschied)

    InformationsquelleAutor qdot
  6. -2

    In der Erwägung, dass Windows verwendet, Fasern und Fäden manchmal denke ich Linux verwendet Prozesse und Bindfäden.
    Ich habe festgestellt, dass im schreiben von multi-threaded Prozesse haben Sie wirklich zu sein, streng, pedantisch, diszipliniert und stur bei der Gestaltung threaded-Prozessen, um für Sie, um die balance der Vorteil bei der Verwendung unabhängig von Anzahl der cores verfügbar sind, die auf die Maschine, mit der der Prozess laufen soll.

    Ist es wahr, auf Linux, dass threads im Vergleich zu Prozessen, sind weniger wahrscheinlich, profitieren von einer multi-core-Prozessor? Niemand weiß.

    InformationsquelleAutor Sam
Schreibe einen Kommentar