Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Videotoolbox-Framework: Chrome…

Chrome ist das Symptom, nicht die Ursache

  1. Thema

Neues Thema Ansicht wechseln


  1. Chrome ist das Symptom, nicht die Ursache

    Autor: schap23 24.06.19 - 09:04

    Das Problem liegt doch offensichtlich in dem Framework, daß es erlaubt alle Ressourcen an sich zu reißen. Ein ordentliches Betriebssystem hat die Aufgabe, die Ressourcen den Prozessen so zuzuteilen, daß alle laufen können.

  2. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: deus-ex 24.06.19 - 09:24

    Ok. Du hast null Plan.

    Wenn Chrome im Hintergrund läuft „nichts“ macht und trotzdem Ressourcen anfordert ist das ein Problem der Anwendung.

    Ein OS kann nicht überprüfen ob von einer Anwendung angeforderte Ressourcen auch wirklich verwendet werden.

    Was anders wäre es wenn Chrome in den Fällen ja wirklich was machen würde (Video abspielen usw.) aber er tut ja (augenscheinlich) nichts.

    Ich kann dir eine Minianwendung schreiben die JEDES OS einfrieren lässt nur weil ich alle Verfügbaren Ressourcen anforderte. (multithreaded Endlosschleife)

    Entweder bist du eine Windows oder Linux Fanboy der mal kurz unqualifizierten gegen macOS stinkern wollte oder du hast keinen Plan.

    Vermutlich beides.

  3. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: wonoscho 24.06.19 - 09:40

    Tipp:
    Lese dir mal in der Wikipedia den Artikel zum Thema Multitasking durch.

    https://de.m.wikipedia.org/wiki/Multitasking

    Beachte insbesondere den Unterschied zwischen
    - Kooperativem Multitasking und
    - Preemtivem Multitasking.

    MacOS unterstützt Preemtives Multitasking
    Da sollten die im Artikel beschriebenen Probleme eigentlich nicht auftreten.

  4. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: wonoscho 24.06.19 - 09:43

    Sehe ich auch so.
    MacOS ist ein ausgewachsenes Unix-System, es unterstützt also preemtives Multitasking.
    Also sollten solche Probleme eigentlich nicht auftreten.
    Also muss das Problem in diesem Framework selbst zu suchen sein.



    1 mal bearbeitet, zuletzt am 24.06.19 09:45 durch wonoscho.

  5. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: deus-ex 24.06.19 - 10:02

    Sagt ja auch keine das Chrome das komplette System lahmlegt sondern Ressourcen anfordert die es gar nicht braucht und damit weniger anderen Programmen zu Verfügung stehen.

    Lest noch mal den Artikel genau durch. Chrome verhält sich wie eine im Vordergrund laufende Anwendung die gerade etwas tut.

    Ein jedes System kommt an seine Grenzen wenn mehrer Anwendung gleichzeitig die gleichen Ressourcen anfordern. Das ist wie als wenn ich gleichzeitig FCP Verwende und nebenbei ein 4k Film schaue.
    Nur Chrome macht ja in dem Fall gar nichts und zieht trotzdem Ressourcen.

  6. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: DeathMD 24.06.19 - 10:03

    Chrome ist ein ressourcenhungriger Haufen Schrott, wenig verwunderlich also, dass es zu solchen Problemen kommt.

    BRAWNDO: The Thirst Mutilator

    It's got Electrolytes

  7. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: bofhl 24.06.19 - 10:13

    wonoscho schrieb:
    --------------------------------------------------------------------------------
    > Tipp:
    > Lese dir mal in der Wikipedia den Artikel zum Thema Multitasking durch.
    >
    > de.m.wikipedia.org
    >
    > Beachte insbesondere den Unterschied zwischen
    > - Kooperativem Multitasking und
    > - Preemtivem Multitasking.
    >
    > MacOS unterstützt Preemtives Multitasking
    > Da sollten die im Artikel beschriebenen Probleme eigentlich nicht
    > auftreten.

    Nur wenn eine Software hergeht und nahezu jede Resource anfordert, egal ob sie sie nun braucht oder nicht? Da diese Resource nun nicht vom OS einfach mal "wieder weg genommen werden kann" -auch weil die Software sie so anfordert als bräuchte sie sie jetzt bis zum Ende des Programmlaufes- nutzt das alles nichts! Auch das hier scheinbar beliebte "Klug-Scheißen" (sorry, aber echt mal!) ist schlicht nicht wahr - wird eine Resource permanent genutzt, kann das OS machen was es will, es bekommt sie nicht mehr! Da kann es noch so gut preemtives Multitasking entsprechend den Regel entwickelt sein!

    PS: Nimmt das OS die Resource dem Chrome weg, dann fordert das Teil diese sofort wieder an! Dieses "Spiel" frisst noch dazu weitere Rechenleistung....

  8. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: Anonymer Nutzer 24.06.19 - 11:07

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > Das Problem liegt doch offensichtlich in dem Framework, daß es erlaubt alle
    > Ressourcen an sich zu reißen. Ein ordentliches Betriebssystem hat die
    > Aufgabe, die Ressourcen den Prozessen so zuzuteilen, daß alle laufen
    > können.

    Das Problem liegt daran, dass Du absolut keine Ahnung hast und trotzdem nicht nur mit Computern und computergetützten Systemen rumkstümpern darfst, sondern sogar noch Unsinn darüber zu verbreiten.

    Ich empfehle einfach mal eine Lesefibel. Fang ganz vorne an und arbeite Dich die nächsten Jahre nach oben. Bis dann. War schön.

  9. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: nate 24.06.19 - 11:59

    > Ein OS kann nicht überprüfen ob von einer Anwendung angeforderte Ressourcen
    > auch wirklich verwendet werden.

    Doch, selbstverständlich. Mit der Video-Hardware kann man doch umgehen wie mit Adressraum: Jeder darf sich soviel reservieren wie er möchte, und solange nicht alle gleichzeitig auch den Speicher nutzen, ist das völlig OK.

    > Ich kann dir eine Minianwendung schreiben die JEDES OS einfrieren lässt nur
    > weil ich alle Verfügbaren Ressourcen anforderte. (multithreaded
    > Endlosschleife)

    Das klingt aber so, als würdest du nicht nur anfordern, sondern auch nutzen wollen. In diesem Fall "darf" das OS zu Recht in die Knie gehen.

  10. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: incoherent 24.06.19 - 14:56

    Ach, und Du glaubst, beleidigend aber völlig Inhaltsleer zu Antworten, sei in irgendeiner Weise besser?

  11. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: deus-ex 24.06.19 - 15:21

    "Ursächlich für die Probleme ist einem Tweet des Nutzers Felipe Baez zufolge die Tatsache, dass Google Chrome das VideoToolBox-Framework von macOS blockieren kann. Dieses wird für das Encoding und Decoding von Videos genutzt und erlaubt entsprechender Software den Zugriff auf die Hardwareressourcen eines Mac. Zur Blockade durch Chrome kommt es beispielsweise, wenn im Browser ein Video abgespielt wird, etwa von YouTube. In den Log-Dateien hat Baez festgestellt, dass in solchen Fällen die CPU-Last auf bis zu 300 Prozent ansteigt und Final Cut Pro X dann den Dienst verweigert."


    So und jetzt sagst du mir WO das Problem beim Framework liegen soll. Hast auch kein Plan von Soft- und Hardwarearchitektur oder?

  12. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: nate 24.06.19 - 16:11

    > So und jetzt sagst du mir WO das Problem beim Framework liegen soll.

    Kann ich gerne tun.

    > Zur Blockade durch Chrome kommt es
    > beispielsweise, wenn im Browser ein Video abgespielt wird, etwa von
    > YouTube.

    So weit, so einfach. Chrome benutzt die Ressource (den Videodecoder) aktiv, er steht anderen Applikationen nicht zur Verfügung, klingt erstmal plausibel.

    An dieser Stelle muss man allerdings schon die Frage aufwerfen, warum das Framework *überhaupt* den Videodecoder exklusiv einem Prozess zuweisen kann, wo die zugrundeliegende Hardware doch keinerlei Probleme mit Multi-Stream-Decoding hat -- unter Linux und Windows funktioniert das ganz selbstverständlich.

    > In den Log-Dateien hat Baez festgestellt, dass in solchen Fällen
    > die CPU-Last auf bis zu 300 Prozent ansteigt

    Wenn zwei Prozesse gleichzeitig den Videodecoder benutzen wollen, kann also unter bestimmten Umständen immense CPU-Last erzeugt werden. Inwiefern sollte das denn *nicht* zumindest in Teilen ein Designproblem des zuständigen Frameworks sein?

  13. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: brainslayer 24.06.19 - 20:55

    bofhl schrieb:
    --------------------------------------------------------------------------------
    > wonoscho schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Tipp:
    > > Lese dir mal in der Wikipedia den Artikel zum Thema Multitasking durch.
    > >
    > > de.m.wikipedia.org
    > >
    > > Beachte insbesondere den Unterschied zwischen
    > > - Kooperativem Multitasking und
    > > - Preemtivem Multitasking.
    > >
    > > MacOS unterstützt Preemtives Multitasking
    > > Da sollten die im Artikel beschriebenen Probleme eigentlich nicht
    > > auftreten.
    >
    > Nur wenn eine Software hergeht und nahezu jede Resource anfordert, egal ob
    > sie sie nun braucht oder nicht? Da diese Resource nun nicht vom OS einfach
    > mal "wieder weg genommen werden kann" -auch weil die Software sie so
    > anfordert als bräuchte sie sie jetzt bis zum Ende des Programmlaufes- nutzt
    > das alles nichts! Auch das hier scheinbar beliebte "Klug-Scheißen" (sorry,
    > aber echt mal!) ist schlicht nicht wahr - wird eine Resource permanent
    > genutzt, kann das OS machen was es will, es bekommt sie nicht mehr! Da kann
    > es noch so gut preemtives Multitasking entsprechend den Regel entwickelt
    > sein!
    >
    > PS: Nimmt das OS die Resource dem Chrome weg, dann fordert das Teil diese
    > sofort wieder an! Dieses "Spiel" frisst noch dazu weitere
    > Rechenleistung....

    doch. wenn man das framework entsprechend gestaltet kann der kernel die resourcen temporär wieder wegnehmen. was glaubst du denn wie unter windows oder auch linux swapping funktioniert. da werden die resourcen die ein programm benötigt von einem still liegendem prozess weg genommen und ausgelagert

  14. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: brainslayer 24.06.19 - 20:56

    deus-ex schrieb:
    --------------------------------------------------------------------------------
    > Sagt ja auch keine das Chrome das komplette System lahmlegt sondern
    > Ressourcen anfordert die es gar nicht braucht und damit weniger anderen
    > Programmen zu Verfügung stehen.
    >
    > Lest noch mal den Artikel genau durch. Chrome verhält sich wie eine im
    > Vordergrund laufende Anwendung die gerade etwas tut.
    >
    > Ein jedes System kommt an seine Grenzen wenn mehrer Anwendung gleichzeitig
    > die gleichen Ressourcen anfordern. Das ist wie als wenn ich gleichzeitig
    > FCP Verwende und nebenbei ein 4k Film schaue.
    > Nur Chrome macht ja in dem Fall gar nichts und zieht trotzdem Ressourcen.

    das ist egal .bei einem ordentlichem multitasking fähigem framework würden die resourcen umverteilt werden und das still liegende programm ausgelagert bis es wieder aktiv wird.

  15. Re: Chrome ist das Symptom, nicht die Ursache

    Autor: brainslayer 24.06.19 - 21:01

    StefanFueger schrieb:
    --------------------------------------------------------------------------------
    > schap23 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das Problem liegt doch offensichtlich in dem Framework, daß es erlaubt
    > alle
    > > Ressourcen an sich zu reißen. Ein ordentliches Betriebssystem hat die
    > > Aufgabe, die Ressourcen den Prozessen so zuzuteilen, daß alle laufen
    > > können.
    >
    > Das Problem liegt daran, dass Du absolut keine Ahnung hast und trotzdem
    > nicht nur mit Computern und computergetützten Systemen rumkstümpern darfst,
    > sondern sogar noch Unsinn darüber zu verbreiten.
    >
    > Ich empfehle einfach mal eine Lesefibel. Fang ganz vorne an und arbeite
    > Dich die nächsten Jahre nach oben. Bis dann. War schön.

    wasn das fürn geschwafel. alles was du erzählst ist großer mist. es gibt genügend beispiele in sachen resourcenmanagement die zeiten wie man shared zwischen applikationen resourcen umverteilen kann. das klassische ram management ist ein gutes beispiel dafür. inaktive programme werden wenn notwendig ausgelagert (swapping) und aktive können die resourcen für sich aktiv beanspruchen. da geht mit grafikkarten genauso. und erzähl mir bloß nicht den selben käse in mein gesicht. ich bin jetzt seit 25 jahren software entwickler und weis sehr genau auf welchem wege man solche lösungen implementiert

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BWI GmbH, Berlin, Strausberg
  2. Spark Radiance GmbH, Inning am Ammersee
  3. Schwäbisch Hall Kreditservice GmbH, Schwäbisch Hall
  4. WITRON Gruppe, Parkstein (Raum Weiden / Oberpfalz)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 149,99€ mit Vorbesteller-Preisgarantie
  2. 169,90€ + Versand (Vergleichspreis 214,27€ + Versand)
  3. auf Geräte von Acer, BenQ, Epson und Optoma


Haben wir etwas übersehen?

E-Mail an news@golem.de


SSD-Kompendium: AHCI, M.2, NVMe, PCIe, Sata, U.2 - ein Überblick
SSD-Kompendium
AHCI, M.2, NVMe, PCIe, Sata, U.2 - ein Überblick

Heutige SSDs gibt es in allerhand Formfaktoren mit diversen Anbindungen und Protokollen, selbst der verwendete Speicher ist längst nicht mehr zwingend NAND-Flash. Wir erläutern die Unterschiede und Gemeinsamkeiten der Solid State Drives.
Von Marc Sauter

  1. PM1733 Samsungs PCIe-Gen4-SSD macht die 8 GByte/s voll
  2. PS5018-E18 Phisons PCIe-Gen4-SSD-Controller liefert 7 GByte/s
  3. Ultrastar SN640 Western Digital bringt SSD mit 31 TByte im E1.L-Ruler-Format

Inside Bill's Brain rezensiert: Nicht nur in Bill Gates' Kopf herrscht Chaos
Inside Bill's Brain rezensiert
Nicht nur in Bill Gates' Kopf herrscht Chaos

Einer der erfolgreichsten Menschen der Welt ist eben auch nur ein Mensch: Die Netflix-Doku Inside Bill's Brain - Decoding Bill Gates zeichnet das teils emotionale Porträt eines introvertierten und schlauen Nerds, schweift aber leider zu oft in die gemeinnützige Arbeit des Microsoft-Gründers ab.
Eine Rezension von Oliver Nickel

  1. Microsoft Netflix bringt dreiteilige Dokumentation über Bill Gates

Telekom Smart Speaker im Test: Der smarte Lautsprecher, der mit zwei Zungen spricht
Telekom Smart Speaker im Test
Der smarte Lautsprecher, der mit zwei Zungen spricht

Die Deutsche Telekom bietet derzeit den einzigen smarten Lautsprecher an, mit dem sich parallel zwei digitale Assistenten nutzen lassen. Der Magenta-Assistent lässt einiges zu wünschen übrig, aber die Parallelnutzung von Alexa funktioniert schon fast zu gut.
Ein Test von Ingo Pakalski

  1. Smarte Lautsprecher Amazon liegt nicht nur in Deutschland vor Google
  2. Pure Discovr Schrumpfender Alexa-Lautsprecher mit Akku wird teurer
  3. Bose Portable Home Speaker Lautsprecher mit Akku, Airplay 2, Alexa und Google Assistant

  1. Funkstandards: Womit funkt das smarte Heim?
    Funkstandards
    Womit funkt das smarte Heim?

    Ob Wohnung oder Haus: Smart soll es bitte sein. Und wenn das nicht von Anfang an klappt, soll die Nachrüstung zum Smart Home so wenig aufwendig wie möglich sein. Dafür kommen vor allem Funklösungen infrage, wir stellen die gebräuchlichsten vor.

  2. Hongkong: Blizzard-Chef findet Meinungsäußerung nur halb so schlimm
    Hongkong
    Blizzard-Chef findet Meinungsäußerung nur halb so schlimm

    Ein halbes Jahr statt ein ganzes Jahr wird ein E-Sport-Profi gesperrt, der auf einem Turnier von Blizzard mit einem Ausruf für die Protestbewegung in Hongkong gekämpft hatte. Zwei dauerhaft entlassene Kommentatoren dürfen nach ebenfalls einem halben Jahr wieder arbeiten.

  3. China: Internetanschluss oder Telefonnummer nur gegen Gesichtsscan
    China
    Internetanschluss oder Telefonnummer nur gegen Gesichtsscan

    In China soll es ab Dezember Telefonnummern oder Internet-Anschlüsse nur noch mit Identitätsfeststellung per Gesichtserkennung geben. Eine entsprechende Regelung wurde kürzlich erlassen und soll auch für bereits registrierte Anschlüsse gelten.


  1. 09:00

  2. 08:21

  3. 15:37

  4. 15:15

  5. 12:56

  6. 15:15

  7. 13:51

  8. 12:41