Neue Macs mit M1 Prozessor

Status
Für weitere Antworten geschlossen.
Ja, das habe ich auch gelesen. Und wenn kein Windows mehr auf dem Mac läuft, dann wird es sehr düster für Apple. Es gibt nämlich sehr viele, die nur ein Windows auf dem Mac haben (iMac). Weil stylischer.
Oder Windows neben MacOs brauchen.

Naja, mal sehen. Die meisten Leute, die ich kenne, die Windows auch noch nutzen, machen das meist entweder für Büro/Verwaltungszeug oder eben zum Zocken. Für ersteres reicht ja prinzipiell auch irgendein günstiger Laptop, den man sich irgendwo hinstellt. Für die Zocker wird's aber natürlich eng - zumal ja, selbst wenn es ein echtes ARM-Windows geben sollte (es gab ja schon mal so ein halbes Mobil-Windows, welches auf ARM-CPUs lief), nicht klar ist, ob dann auch die Spielehersteller nachziehen.

Kann aber auch einen anderen Effekt haben, nämlich das Macs auch eben bspw. für Spielehersteller attraktiver werden, da eben ab jetzt schneller und zumindest verhältnismäßig günstiger.

Oder es gibt den Umkehreffekt und die halbe Softwarewelt hat keinen Bock, alles für dann doch sehr unterschiedliche Plattformen zu programmieren - wobei ich als absolut Ahnungsloser nicht weiß, wie groß die Unterschiede tatsächlich sind. Aber wenn da Hersteller - wie ja bei Plugins a la Massive, Modo Bass/Drums der Fall - recht intensiv auf sowas wie AVX setzen, ist das vielleicht keine so aus dem Handgelenk zu schüttelnde Angelegenheit.

Wie dem auch sei, für einen ersten Aufschlag finde ich das, was bisher auf den M1 Kisten geht, verdammt eindrucksvoll und denke, dass mein nächster Rechner dann eben doch wieder ein Mac sein wird. An sich hatte ich mit einem Hackintosh geliebäugelt und auch einen Wechsel zu Windows immer noch nicht ausgeschlossen, aber wenn ich ganz ehrlich bin, habe ich mittlerweile weder auf Basteleien noch auf das Erlernen eines anderen Sequenzers (bei gleichzeitigem Verlust aller bisherigen Projekte) sonderlich Bock. Vor 20 Jahren war das anders, aber mit Kids und so möchte ich meine Zeit lieber anderen Dingen widmen. Wie etwa der Tipperei in diesem werten Forum...
 
Dann muss ich mir halt einen PC in MacMini- Größe kaufen. Es stehen halt schon so viel Rechner bei mir rum! :mad:
 
wenn Singlecore-Dampf benötigt wird.
Bisher weiß man doch nicht wirklich ob es Singlecore Dampf gibt.

Im Grunde genommen ist es auch völlig egal, ob es sich Single oder Multi Core Performance handelt.

Je nachdem was für ein Prozess involviert ist, werden dessen threads dynamisch an die Cores weitergeleitet. Dabei ist es durchaus normal, dass ein Prozess auch mehr threads erzeugen kann als physische und virtuelle Cores im Rechner existieren.

Cores zu monitoren ist einfach, aber threads zu monitoren ist schwierig, da ein thread je nach Anforderung auch durch mehrere Cores gedrückt werden kann. Hinzu kommt, das threads flüchtig sind, also nach ihrer Berechnung verschwinden oder anders gesagt nur sichtbar sind, solange sie aktiv sind. Der Core aber ist nicht flüchtig und immer sichtbar. Deswegen wird der Core auch im Monitor dargestellt und nicht ein schnell wechselnder thread Zähler, dessen absolute Zahlen kaum ein Mensch in Relation zur Leistung interpretieren könnte.

Man könnte ja jetzt den Aktivitätsmonitor aufrufen und sich dort die threads angucken. Dann sieht zwar die Anzahl aller in diesem Moment aktiven threads. Deren Prozesszugehörigkeit sieht man aber leider auch nicht. Bringt einen also auch nicht weiter, weil threads einerseits nicht zugeordnet und andererseits zu flüchtig sind.

Hinzu kommt, dass man meist garnicht genau weiß, ob ein Prozeß z.B. im Logic einen oder mehrere threads erzeugt und ob die dann per single oder multi core abgearbeitet werden. Man sieht zwar bei bestimmten Operationen eine höhere Aktivität in einem Core, aber ob die real nur in diesem core stattfindet, sieht und weiß man nicht.

Deshalb finde ich auch die benchmark tests wenig aussagekräftig, da sie nur ein Verarbeitungsschema von zu berechnenden Daten vergleichen, das weit entfernt von typischen User Anwendungen ist. Dadurch lässt sich zwar die Aussage treffen, dass Computer x in dieser Berechnung schneller ist als y. Mehr aber nicht und insofern ist ein Überlastungstest wie der mit 1000 plugins viel interessanter, da dem Logic User hier die mögliche Potenz des Rechners praktisch und nachvollziehbar aufgezeigt wird.

Das einzige, was bis jetzt deutlich wird, ist dass der M1 aufgrund einer völlig neuen Architektur und seiner optimierten Programmierung mit wesentlich weniger Energie mehr Rechenoperationen erzeugt und damit einen Geschwindigkeitsvorteil bietet. Ob dieser Speed je nach Programm im Apple Silicon aus dem Singe oder Multi Core erzeugt wird, ist dabei letztendlich doch völlig egal, da keiner weiß, ob die sogenannte Single Core Power auch noch im M1 im Single Core verarbeitet wird.
 
Hinzu kommt, dass man meist garnicht genau weiß, ob ein Prozeß z.B. im Logic einen oder mehrere threads erzeugt und ob die dann per single oder multi core abgearbeitet werden. Man sieht zwar bei bestimmten Operationen eine höhere Aktivität in einem Core, aber ob die real nur in diesem core stattfindet, sieht und weiß man nicht.

Naja, das sieht man schon recht eindeutig - und wenn der Signalfluss seriell ist, muss das ja auch seriell abgearbeitet werden. Und sollte es da in der Kette einen Sprung von einem Thread zum anderen geben, würde halt die Latenz in die Höhe gehen - was sie aber nicht tut.
 
und wenn der Signalfluss seriell ist, muss das ja auch seriell abgearbeitet werden.

CPUs bearbeiten Rechenopertaionen. Und wenn eine Effektinstanz mehrere Rechenoperationen benötigt, teilt die CPU diese auf mehrer Kerne auf. Das was du auf deinem Monitor siehst, hat quasi nichts mit dem zu tun, was in einer CPU passiert.
 
CPUs bearbeiten Rechenopertaionen. Und wenn eine Effektinstanz mehrere Rechenoperationen benötigt, teilt die CPU diese auf mehrer Kerne auf. Das was du auf deinem Monitor siehst, hat quasi nichts mit dem zu tun, was in einer CPU passiert.

Ein serieller Signalfluss muss trotzdem *zwingend* seriell abgearbeitet werden.
 
CPUs bearbeiten Rechenopertaionen. Und wenn eine Effektinstanz mehrere Rechenoperationen benötigt, teilt die CPU diese auf mehrer Kerne auf. Das was du auf deinem Monitor siehst, hat quasi nichts mit dem zu tun, was in einer CPU passiert.

Ein serieller Signalfluss muss trotzdem *zwingend* seriell abgearbeitet werden.

Richtig. Aber das hat nichts mit Single oder Multicoreperformance zu tun.
 
Richtig. Aber das hat nichts mit Single oder Multicoreperformance zu tun.

In keiner DAW wird ein serieller Signalfluss von einem Kern an einen weiteren weitergeleitet. Passiert einfach nicht.
Edit: Also zumindest nicht für "Echtzeit/Live" Prozesse. Wie es beim Abspielen aussieht, weiß ich nicht.
 
In keiner DAW wird ein serieller Signalfluss von einem Kern an einen weiteren weitergeleitet. Passiert einfach nicht.

Das hat nichts mit der DAW zu tun. Nicht mal mit dem Betriebssystem. Die CPU zerlegt ihre Aufgabe in Teilprobleme und nutzt selbstständig alle Kerne die ihr dafür zur Verfügung stehen. Dann wird das Ergebnis an das Programm zurückgeliefert. Das Programm interessiert sich nicht dafür, wie die CPU ihre Arbeit macht.
 
Zuletzt bearbeitet:
Das hat nichts mit der DAW zu tun. Nicht mal mit dem Betriebssystem. Die CPU zerlegt ihre Aufgabe in Teilprobleme und nutzt selbstständig alle Kerne die ihr dafür zur Verfügung stehen. Dann wird das Ergebnis an das Programm zurückgeliefert. Das Programm interessiert sich nicht dafür, wie die CPU ihre Arbeit macht.

Laut sämtlichen CPU Monitoren läuft aber pro Realtime-Track immer ausschließlich einer.
 
Programme geben dem System Threads vor, also Instruktionsabläufe. Diese sind natürlich seriell, man kann halt pro Core nur eine Rechnung auf einmal machen. Hier ist ein Kanal auch in einem Thread, bei jeder DAW.


Auf welchem Core gerechnet wird entscheidet die CPU MEIST selbst.


So ergibt sich das SingleCore Leistung wichtig wird, da die Geschwindigkeit der Instruktionen eines Threads abhängig vom Takt sind.

Daraus resultiert: Je mehr hintereinander in einem Thread ist, desto länger dauert das zu rechnen.

Also: 3 plugins in einem Kanal brauchen länger als 1 Plugin. Unabhängig von der Anzahl Kerne.
Aber: Viele Kerne ergeben viele Threads/Kanäle zeitgleich.

Das alles so auf x86, wie sich das vom ARM unterscheidet ist das spannende.

Ist eine Software Multicore optimiert gibt sie, einfach gesagt, mehrere Threads aus.

Zum MEIST: um realtime möglichst stabil zu halten kann das System die Verschiebung von Threads auf andere Cores, also das Lastspringen negieren. Oder man nennt es priorisieren, alles das selbe.

Ich gehe nicht auf Hyperthreading ein, ändert nichts am Grundprinzip, macht einfach alles flotter.
 
Zuletzt bearbeitet von einem Moderator:
Mein Profil wird hoffentlich morgen gelöscht, also kann ich mir folgendes erlauben:

Sascha, du redest auch Quatsch.

Z.B. werden serielle Prozesse sehr wohl von einem Kern zum anderen verschoben. Allein schon wegen Temperaturen. Zwar mit den neuen CPUs weniger, aber es ist Fakt.

Das du hier so arrogant reinhaust ist eine Frechheit. Rein von der Art her.

Inhaltlich würde ich mich da gerne stellen, aber emotional macht das keine Laune mit jemandem zu reden der nicht zuhören kann.

Das nervt und Mitglieder wie du verderben das ganze Forumserlebnis.

Das selbe gilt für Zille. Und zwar alles. Der hat von PCs noch weniger Ahnung als du, das du dich da nicht ungerecht behandelt fühlst.

Das die Mods da nichts machen ist schade wie verständlich, ich hätte da auch keinen Nerv.

4 Wochen Bann wäre mal was, aber das wird wohl nicht verhängt.

Labert Unsinn soviel ihr wollt, hier wie auf Gearslutz, da machen wir uns auch nur noch lustig.
Und das mit Klarnamen, ich lach mich schlapp.
 
Weil mir das keine Ruhe lässt:

https://www.soundonsound.com/forum/viewtopic.php?f=16&t=69071&start=15

Für jeden den Single vs Multicore interessiert findet hier eine gute informative Diskussion die nicht persönlich motiviert ist.

Ich habe nichts passendes für ARM vs x86 gefunden.

Danke. Geht an sich deutlich über meinen Horizont hinaus, die wesentlichen Antworten sagen aber im Prinzip, wenn ich's nicht vollkommen falsch verstehe, auch nix anderes aus, als das quasi pro Prozess immer nur ein Kern benutzt wird (auch wenn es dann mal andere Kerne sein dürfen, um für Entlastung hinsichtlich hitzebedingter Probleme zu sorgen).

Ich könnt's mir anders auch nicht vorstellen - bzw. sieht man es halt einfach nicht anders, zumindest dann nicht, wenn wir über "realtime" Tracks in DAWs reden. Denn für solch einen Track steht ja eben einfach nicht die komplette CPU-Leistung zur Verfügung. Dafür gäbe es ja keinen Grund, wenn die Last einer einzelnen "Aufgabe" (also eben bspw. eines Synths mit seriell nachgeschalteten Effekten) die Leistung eines Kerns übersteigt und dann halt einfach an den nächsten Kern weitergereicht werden könnte. Sprich, da müsste ich im Prinzip eine gigantische serielle Signalverkettung realisieren können. Das ist aber eben einfach nicht der Fall, sondern es wird dicht gemacht, obwohl insgesamt noch sehr viel Leistung zur Verfügung steht.
Ob es in anderen Umgebungen auch anders funktioniert, vermag ich nicht zu sagen, aber in DAWs funktioniert es mMn ausschließlich so.

Für mich als absoluten Laien stellt es sich so dar: Was auf Live-Tracks passiert, läuft auf einem Kern ab. Die Zeit, die man diesem Kern dafür einräumt, wird über die vom User einstellbare Puffergröße bestimmt - und der Kern reserviert sich diese Zeit dann auch einfach. Würde die Last jetzt die Leistungsfähigkeit eines Kerns übersteigen und dieser die weitere Verarbeitung nicht bewältigen können und daraufhin den Rest der zu erledigenden Aufgabe an einen weiteren Kern weiterreichen, so würde der erneut die über die Puffergröße bestimmte Rechenzeit für sich beanspruchen und es würde quasi zu einer Verdopplung der Latenz kommen (also zumindest der internen, ergo ohne Konverterlatenz und anderen Dingen, die die Hsrdware für sich beansprucht).
Ist das soweit korrekt oder liege ich vollkommen daneben?
Es würde zumindest hinreichend den Umstand erklären, dass eben per Live-Track tatsächlich immer nur ein Kern benutzt zu werden scheint. Und wenn die Weiterreichung eines noch nicht beendeten Prozesses an einen weiteren Kern latenzseitig kein Problem darstellen würde, würde das bestimmt auch möglich sein - wäre ja auch speziell für Live-Spieler von großem Interesse, denn da liegen eben oft eher serielle Aufgaben an. Passiert aber eben nicht.

Wenn ich vollkommen im Trüben fische, bitte ich um Aufklärung.
 
Z.B. werden serielle Prozesse sehr wohl von einem Kern zum anderen verschoben. Allein schon wegen Temperaturen. Zwar mit den neuen CPUs weniger, aber es ist Fakt.

Ich habe nicht behauptet, dass die nicht verschoben werden. Aber es wird in DAWs offensichtlich kein serieller Prozess auf Live-Tracks zwischen Kernen aufgeteilt.
 
Was dich als Laien auszeichnet ist das es 15 Beiträge braucht bis du langsamer machst.
Lächerliche Luftpumpe.
Rette dich jetzt mit: das übersteigt mein Fachwissen, aber vorher n dicken Sack aufblasen....
 
Labert Unsinn soviel ihr wollt, hier wie auf Gearslutz, da machen wir uns auch nur noch lustig.
Und das mit Klarnamen, ich lach mich schlapp.

Und mal kurz dazu: Ich glaube nicht, dass du es nötig hast, dich über Umgangsformen aufzuregen. Deine sind nicht einen Deut besser.
 
In keiner DAW wird ein serieller Signalfluss von einem Kern an einen weiteren weitergeleitet. Passiert einfach nicht.
Edit: Also zumindest nicht für "Echtzeit/Live" Prozesse. Wie es beim Abspielen aussieht, weiß ich nicht.

Schau mal oben... :)
Keine Ahnung, mich angehen wegen meiner Schreibweise aber dich jetzt nicht festlegen wollen....
 
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

Neue Antworten


Oft gelesene Themen

Zurück
Oben