News Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround

ZeroZerp schrieb:
Wie hoch ist denn der Nutzeranteil dieser Bibliothek in Blöcken AMD vs Intel?
Wieso sollte ich mit einem Intel System nicht auf eine optimierte Bibliothek zugreifen?
Stellst du die erste Frage ernsthaft mit dem Wissen über die nicht offensichtliche und künstliche Ausbremsung der Konkurrenz?
Würdest du über die zweite Frage nochmal nachdenken dann wüßtest du wie überflüssig sie ist da sich beides nicht ausschließt. Nochmal, der Wegfall einer künstliche Beschneidung ist keine Optimierung.
Ergänzung ()

@ZeroStrat

Dir ist schon klar das in erster Linie der Kunde das Opfer von der Nummer ist und daraus folgen dann die Konsequenzen für AMD, oder?
 
Wadenbeisser schrieb:
Stellst du die erste Frage ernsthaft mit dem Wissen über die nicht offensichtliche und künstliche Ausbremsung der Konkurrenz?
Ja- Weil ich es nicht als Ausbremsung sehe. Die Gründe habe ich in diesem Thread schon mehrfach genannt.
Das Ding prüft, obs ein Intel Prozessor ist- Wenn nein->maximale kompatibilität, altes Instruction Set.
Wenn ja- Was kann das Ding alles -> optimiertes Instruction Set.

Im alten Instruction set finden KEINERLEI künstliche Ausbremsungen statt, womit z.B. ein konsistentes Benchmarking unter einheitlichen Grundvoraussetzungen gegeben wäre.

Wenn jemand meine Gründe, dies so zu sehen, nicht als valide akzeptiert, kann er dies tun, muss mir dann allerdings selbst solche Fragen nicht stellen:
Würdest du über die zweite Frage nochmal nachdenken dann wüßtest du wie überflüssig sie ist da sich beides nicht ausschließt. Nochmal, der Wegfall einer künstliche Beschneidung ist keine Optimierung.
Zum hundertsten Male - Wie kann denn eine Software die prüft, ob die eigene, für die Funktion zertifizierte und optimierte Hardware dahinterliegt und dann aufgrund dieser Abfrage gewisse Optimierungen bringt oder nicht, als "Beschnitten" betrachtet werden? Sie erfüllt uneingeschränkt ihren zugedachten Zweck.

Was ist mit Support, was ist mit Funktionsgarantien auf anderen X86 Prozessoren und wieso sollte ich die Funktionalität mit irgendetwas außer dem Komplementärprodukt herstellen?
Ja- Im Falle AMD könnten sie das (vielleicht) tun. Müssen sie aber nicht, weil vielleicht der Zweck der zusätzlichen Softwarepakete, die man für seinen Intel Prozessor von Intel erhält ein Alleinstellungsmerkmal zu den Mitbewerbern darstellt.

Was passiert, wenn sie die Funktionen freigeben würden, aber Aufgrund von Laufzeitfehlern/Pufferüberläufen/Race- Condition- Fehlern aufgrund des auf die Cachegrößen von Intel optimiertem Verhalten hier ein Rechenfehler und sei er auch noch so klein auftreten würde?
DANN wär die Hölle los und Intel würde zum Leibhaftigen hochstilisiert, der AKTIV die Konkurrenz manipuliert!
Zu einer Softwareentwicklung gehört nämlich nicht nur das einfache- "Schalten wir das mal für alle frei und schauen mal, was passiert", sondern eben intensives Testing.
Wofür der Aufwand? Um der Konkurrenz auf die Sprünge zu helfen? ->Weltfremd!

Ist ja auch nich so, als ob die Entwickler und Integratoren dieser Bibliothek nach außen hin irgendein Geheimnis darum machen, was die MKL ist (nur lesen müsste man halt schon können):

https://software.intel.com/en-us/mkl
Intel® Math Kernel Library (Intel® MKL) optimizes code with minimal effort for future generations of Intel® processors.

https://www.mathworks.com/hardware-support/intel.html
MATLAB Coder™, Simulink Coder™, and Embedded Coder® generate ANSI/ISO C/C++ code that can be compiled and executed on Intel® processors.

https://en.wikipedia.org/wiki/Math_Kernel_Library
Intel Math Kernel Library (Intel MKL) is a library of optimized math routines for science, engineering, and financial applications. Core math functions include BLAS, LAPACK, ScaLAPACK, sparse solvers, fast Fourier transforms, and vector math.[4] The routines in MKL are hand-optimized specifically for Intel processors.[5][6]

Also wieso die Überraschung und Aufregung bezüglich offensichtlichen Gegebenheiten?


Dir ist schon klar das in erster Linie der Kunde das Opfer von der Nummer ist und daraus folgen dann die Konsequenzen für AMD, oder?
Nix da- Da ist keiner "Opfer" von irgendwelchen "Machenschaften".
AMD soll gefälligst selbst ein Ökosystem um ihre Prozessoren schaffen, das einen Beitrag zur Kaufmotivation leistet.
So toll es hier einige auch finden, dass AMD viel den "offenen" Ansatz gehen und auf open source setzen, so sehr sollte man sich in der verblendeten Sicht nicht davon ablenken lassen, welche Vorteile so ein Vorgehen für AMD bietet.

Ihr könnt darauf warten, dass AMD bei anhaltenden Erfolg wieder größer wird. Und dann könnt Ihr drauf warten, dass AMD seine Softwareabteilung und Marketingabteilung vergrößert und versuchen wird den eigenen Einfluss zu erhöhen und sich Wettbewerbsvorteile zu verschaffen.

Normalste Sache der Welt und überlebenswichtig für ein Unternehmen und keinerlei Grund sich hier jetzt aufgrund dieser Tatsachen als armes, angeschossenes Reh darzustellen, welches vom grausamen und durchweg illegal und unsauber operierenden Alleinherrscher benachteiligt und unterdrückt wird.

Es ist an AMD und den Anbietern von Software hier ihren Hintern hochzubekommen.
Und Ihr werdet sehen wie das auf einmal wie von Geisterhand funktionieren wird, wenn der Marktanteil von AMD zunimmt.

LG
Zero
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ZeroStrat
ZeroZerp schrieb:
Ja- Weil ich es nicht als Ausbremsung sehe. Die Gründe habe ich in diesem Thread schon mehrfach genannt.
Das Ding prüft, obs ein Intel Prozessor ist- Wenn nein->maximale kompatibilität, altes Instruction Set.
Wenn ja- Was kann das Ding alles -> optimiertes Instruction Set.

Eine Vendor Abfrage hat nur einen Sinn und das ist die Minderung der Leistung von anderen Herstellern. Eine Vendor-Abfrage bringt nämlich auch der Bibiliothek bei Intel CPU's rein gar nichts. Denn eine Feature-Abfrage muss so oder so erfolgen.

Einen anderen Sinn erfüllt die Vendor-Abfrage nicht.
 
@ZeroZerp

Du siehst es nicht als ausbremsen an wenn der Konkurrenz Standards vorenthalten werden die sie unterstützt?
Interessant...

Da bedienen wir uns doch einfach mal der beliebten Auto vergleiche. Lass uns ein Rennen fahren, meine Kiste bekommt die typische Rennbereifung und bei deinem Hobel montieren wir sie ab und du darfst mit 4 Noträdern starten. Na wie wäre es? Wer da wohl gewinnen mag?

Und ja, etwas nicht zu nutzen bzw. abzuschalten was von der Hardware unterstützt wird ist ein künstliches ausbremsen denn dafür gibt es schließlich besagte Standards und das Workaround zeigt nur zu deutlich das es keine technischen Gründe dafür gibt. Sie läuft leistungstechnisch vielleicht nicht optimal weil die Software nicht darauf optimiert wurde aber sie läuft wenn sich Hard- und Software an den Standard halten.

Und doch, der Kunde ist das primäre Opfer der Nummer denn er bezahlt die Rechnung dafür.

Und ja, es sind Machenschaften wenn dieser Grund für für die Leistungsunterschiede für den Kunden nicht einwandfrei erkennbar ist. Und ist diese der Fall? Ich kann mich nicht erinner bei Intel gelesen zu haben das Konkurrenzproduken unterstützte Funktionen vorenthalten werden und es wäre für mich auch neu wenn die Software selbst einen entsprechenden Hinweis ausgibt.
 
ZeroZerp schrieb:
Ja- Weil ich es nicht als Ausbremsung sehe....
[Intel] prüft, ob die eigene, für die Funktion zertifizierte und optimierte Hardware dahinterliegt und dann aufgrund dieser Abfrage gewisse Optimierungen bringt oder nicht.
Gerade eben ist dir noch selber gekommen das dem wohl nicht so ist. Die Vendor String abfrage optimiert garnichts. Ihr Sinn ist eine Pessimierung. Lies doch nochmal dein selbstgeschriebenes aus #213
ZeroZerp schrieb:
Was ist mit Support, was ist mit Funktionsgarantien auf anderen X86 Prozessoren und wieso sollte ich die Funktionalität mit irgendetwas außer dem Komplementärprodukt herstellen?
Wenn es darum Ginge, dann würde ein simpler Hinweis darauf, dass die Funktionalität auf nicht Intel Hardware nicht garantiert wird reichen. Stattdessen verwenden sie eine völlig intransparente Strategie, die suggeriert das sie in einigen Fällen nicht auf das gleiche Level durchoptimiert läuft, aber generell auch auf nicht Intel CPUs gut läuft. Das garantieren sie schonmal, demnach müssen sie das übrigens auch getestet haben, oder nicht? Leider bist du ja bislang noch immer nicht darauf eingegangen was du davon halten würdest wenn Intel jetzt den Debug Mode entfernen würde.
ZeroZerp schrieb:
Müssen sie aber nicht, weil vielleicht der Zweck der zusätzlichen Softwarepakete, die man für seinen Intel Prozessor von Intel erhält ein Alleinstellungsmerkmal zu den Mitbewerbern darstellt.
Das sind sie ganz sicher, und das sollte man dann eben auch transparent ausgestallten und keinen undokumentierten Schlangenölmodus einbauen. Und er ist undokumentiert, denn nirgendwo steht, dass die MKL bei nicht Intel CPUs in einen "Kompatibilitätsmodus" zurückfällt, wie du das nennst.
ZeroZerp schrieb:
Was passiert, wenn sie die Funktionen freigeben würden, aber Aufgrund von Laufzeitfehlern/Pufferüberläufen/Race- Condition- Fehlern aufgrund des auf die Cachegrößen von Intel optimiertem Verhalten hier ein Rechenfehler und sei er auch noch so klein auftreten würde?
Das habt ihr letztes mal auch schon gebracht. Schon damals war klar das ein AVX2 Codepfad auch auf AMD laufen sollte und der einzige der hart angeschmiert wäre, sollte das nicht so sein wäre AMD. Mittlerweile ist das ja auch bestätigt. Aber umgekehrt gefragt, Intel testet ja offensichtlich den SSE2 Codepfad auf AMD und Via, sonst könnten sie ja dessen Funktion ja nicht garantieren.
ZeroZerp schrieb:
Also wieso die Überraschung und Aufregung bezüglich offensichtlichen Gegebenheiten?
Weil Du wieder sehr selektiv das raussuchst was für deine Argumentation vorteilhaft ist, aber die anderen Stellen vergessen hast. Das funktioniert aber halt auch nur bei Leuten die sich das nicht selbst angeschaut haben, also nicht bei mir. Warum versuchst du es dann? Das macht Dich i.m.A. nicht glaubwürdiger.
ZeroZerp schrieb:
könnt Ihr drauf warten, dass AMD seine Softwareabteilung und Marketingabteilung vergrößert und versuchen wird den eigenen Einfluss zu erhöhen und sich Wettbewerbsvorteile zu verschaffen.
Quod erat demonstrandum. Wieder ein gern gebrachtes Argument, dass bislang unbestätigt bleiben muss. Nicht alle Firmen sind gleich und nicht alle Firmen verhalten sich wie Monsanto oder Intel.
ZeroZerp schrieb:
keinerlei Grund sich hier jetzt aufgrund dieser Tatsachen als armes, angeschossenes Reh darzustellen
Die Methoden sind Anti Competitive. Daran herrscht kein Zweifel. Nichtmal von Deiner Seite. Aber ich habe noch nicht gelesenen das AMD sich als angeschossenes Reh in diesem Zusammenhang dargestellt hat. Never the less, wenn solche Methoden wirken wie beispielsweise die Bestechung der OEMs durch Intel, dann muss man das als Firma auch sagen dürfen ohne das ZeroZerp gleich meint sie stellen sich als Opfer dar.
ZeroZerp schrieb:
Es ist an AMD und den Anbietern von Software hier ihren Hintern hochzubekommen.
Ohne jeden Zweifel!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Iscaran
aldaric schrieb:
Einen anderen Sinn erfüllt die Vendor-Abfrage nicht.
Zum x-ten Male: Eine Vendor- oder Typenabfrage kann auch eine Vorselektion sein, nämlich um getestete und supportete Devices zu filtern/freizuschalten. Unabhängig davon, ob es auch auf anderen Systemen funktionieren würde.
Beschäftigt Euch mal ein wenig mit Software- Entwicklung.

Siehe z.B. "Cuda Supported Cards"/OpenCL für die Mercury playback Engine in Adobe Premiere.
Das ist ein ganz normales Mittel um Sicherzustellen, dass getestete Hardware unterstützt/beschleunigt wird und der Rest eben nicht!

Es ist hier nur ein Aufreger, weil es sich beim "Täter" um Intel handelt.
Zumal der ganze Komplex schon seit X- Jahren bekannt ist und auch schon bis zum Erbrechen diskutiert wurde:
https://www.agner.org/optimize/blog/read.php?i=131
Wenn das alles schon seit x- Jahren bekannt ist, warum hat man sich nicht darum gekümmert?

Wieso sollte Intel keinen Vorteil davon haben, wenn andere Unternehmen zu faul oder unfähig sind, eigene Software/Compiler/libraries oder was weiss ich denn noch zu erstellen, die deren Produkten liegt.

LG
Zero
 
Das Motto sollte sein: weniger auf Intel schauen, mehr Verantwortung von AMD einfordern. Man muss da maximal streng sein mit AMD meiner Meinung nach. Das Ökosystem ist ein Witz. Sie müssen dringend in ihre Software investieren und aufhören, die Community auszunutzen und Fans "vorzuschicken".
 
  • Gefällt mir
Reaktionen: .Sentinel.
Wadenbeisser schrieb:
Da bedienen wir uns doch einfach mal der beliebten Auto vergleiche. Lass uns ein Rennen fahren, meine Kiste bekommt die typische Rennbereifung und bei deinem Hobel montieren wir sie ab und du darfst mit 4 Noträdern starten. Na wie wäre es? Wer da wohl gewinnen mag?
Gerne- Intel erfindet das Auto (Hardware) und übergibt AMD das Recht dazu, dieses auch herstellen zu dürfen.
Nun überlegt sich Intel aber, wie man das Auto optimal auf der Straße hält. Unter Anderem optimieren sie die Gummimischung in den Reifen, so dass das Auto geradezu auf der Straße klebt (Software).
Anschließend wird die Radaufhängung so modifiziert, dass die Reifen nicht auf das Konkurrenzmodell passen.

AMD zieht stattdessen die Notbereifung auf. Die Intel standardmäßig allen Firmen, die Autos bauen, überlässt.

Jetzt kommt AMD nach dem Rennen an und schreit:Unfair! Intel hätte uns solche Reifen auch an unser Auto anpassen müssen. Intel ist böse.
Das ist doch weitab jeglicher ökonomischer und wettberwerbstechnischer Realitäten!

LG
zero
 
Zuletzt bearbeitet:
Ach, lasst doch unsere Intel-Krieger in Ruhe. Bekehren müssen wir keinen, jeder kann so leben wie er will.
Die ganze Diskussion hier führt doch zu nichts und dreht sich ständig im Kreis.
 
  • Gefällt mir
Reaktionen: Ned Flanders
ZeroStrat schrieb:
Das Motto sollte sein: weniger auf Intel schauen, mehr Verantwortung von AMD einfordern. Man muss da maximal streng sein mit AMD meiner Meinung nach. Das Ökosystem ist ein Witz. Sie müssen dringend in ihre Software investieren und aufhören, die Community auszunutzen und Fans "vorzuschicken".

Klar sollte AMD mehr ins Ökosystem investieren. Das hab ich auch schon geschrieben.
Deswegen darf ich aber trotzdem Dinge ansprechen die aus meiner Sicht einfach krumm sind. Und die sind ja auch Eurer Meinung nach krumm, nur findet ihr das halt normal und verteidigt das daher, was ich nicht nachvollziehen kann. Letzter Halbsatz ist übrigens daneben und das weisst du.
 
Denniss schrieb:
Ach, lasst doch unsere Intel-Krieger in Ruhe. Bekehren müssen wir keinen, jeder kann so leben wie er will.
Die ganze Diskussion hier führt doch zu nichts und dreht sich ständig im Kreis.
Was hat denn das mit Intel- Krieger zu tun, wenn sachen maximal Eindimensional betrachtet werden?
Ist der Konterpart dann ein AMD- Krieger?

LG
Zero
 
Denniss schrieb:
gibt solche und solche
Ich bin wirklich bemüht, sachlich zu bleiben und es nicht wieder aus dem Ruder laufen zu lassen. Vielleicht bemühst du dich auch ein wenig.

Ned Flanders schrieb:
Deswegen darf ich aber trotzdem Dinge ansprechen die aus meiner Sicht einfach krumm sind. Und die sind ja auch Eurer Meinung nach krumm, nur findet ihr das halt normal und verteidigt das daher, was ich nicht nachvollziehen kann. Letzter Halbsatz ist übrigens daneben und das weisst du.

Natürlich darfst du das. Du weißt ja auch, dass ich dich als User hier sehr schätze. Die Frage ist aber, was ist denn hier krumm? Das was Intel mit der MKL macht, erscheint mir keineswegs krum zu sein.

Inwiefern ist mein Halbsatz anstößig für dich? Ich denke schon, dass AMD das Fan-Verhalten bewusst mit einkalkuliert. Das erspart ihnen sicherlich, hier und da Verantwortung zu übernehmen.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: .Sentinel.
Ned Flanders schrieb:
Deswegen darf ich aber trotzdem Dinge ansprechen die aus meiner Sicht einfach krumm sind. Und die sind ja auch Eurer Meinung nach krumm, nur findet ihr das halt normal und verteidigt das daher, was ich nicht nachvollziehen kann.
Es ist halt einfach scheinheilig, wenn man nach x- Jahren, in welchen die Umstände bekannt sind (siehe mein Link oben), immernoch mit dem Finger auf andere zeigt.

Vor 15 Jahren wäre das von AMD oder den Usern vielleicht alles noch eine verständliche Argumentation gewesen (damals gabs das gleiche Thema mit SSE).
Aber sorry- Da hat AMD bzw. der Softwareentwickler, der das an den Mann bringen will, einfach nur MAXIMAL geschlafen und die "Ausrede", dass man ja so benachteiligt werde, zieht einfach nicht mehr.

Wenn man da trotz besseren Wissens und mit sehendem Auge gegen Mauern rennt, hält sich mein Mitleider leider einfach in Grenzen.
https://techreport.com/news/8547/does-intels-compiler-cripple-amd-performance/
To Intel: there is a standard mechanism out there (invented by you!) for questioning a CPU as to its capabilities. You should be using that, not checking for the presence of your trademark. I don’t expect Intel to support AMD-specific extensions, and I also don’t expect Intel to have to test its compiler on AMD CPUs. However, if a CPU states that it can do SSE3 or whatever then I expect the code produced by the Intel compiler to use SSE3 instructions rather than to check first if the chip was made by Intel.

Seitdem ist AMD inkl. Softwareentwickler wohl im Tiefschlaf...

That’s a misunderstanding and/or misrepresentation of the facts.

Intel’s compilers are Intel’s own work, and never were ‘generic code compilers’, they were always aimed strictly at Intel’s own products.

Intel didn’t ‘modify’ anything, nor did they ‘cripple’ anything.

Optimizing for anything other than Intel’s own CPUs was just never part of the goals of the Intel compiler suite.

You can’t ‘modify’ or ‘cripple’ something that has never been different anyway.



ZeroStrat schrieb:
Natürlich darfst du das. Du weißt ja auch, dass ich dich als User hier sehr schätze. Die Frage ist aber, was ist denn hier krumm? Das was Intel mit der MKL macht, erscheint mir keineswegs krum zu sein.
Genau das ist des Pudels Kern. Da gibt es eben eine unterschiedliche Bewertung der Sachlage.
Einige gehen davon aus, dass man dazu verpflichtet sei, die Software so zu gestalten, dass sie auch optimal auf einem Konkurrenzprodukt läuft.

Ansonsten ist man ein Schuft.

LG
Zero
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ZeroStrat
ZeroZerp schrieb:
Ansonsten ist man ein Schuft.

Ist scheinbar so. Da müssen wir halt durch. Ich muss als Entwickler von Benchmark-Software übrigens maximal neutral sein. Umgekehrt würde man das auch von mir erwarten, die Sachlage neutral zu betrachten, wenn nämlich unberechtigterweise gegen AMD geschossen wird. Das habe ich u.a. bei der "Idle-Boost" Geschichte damals oder bei der Sache mit PassMark ja auch getan.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: .Sentinel.
ZeroStrat schrieb:
Umgekehrt würde man das auch von mir erwarten, die Sachlage neutral zu betrachten
Genau darum gehts. Die Sachlage neutral betrachten.

AMD und die Softwareentwickler, die entsprechende Bibliotheken nutzen, hatten 15 Jahre Zeit ihre eigenen Bibliotheken und Compiler bzw. Anpassungen für AMD Prozessoren zu entwickeln.
Sie hätten Intels Compiler sogar als Ausgangsbasis dafür nehmen dürfen.

Aber sich jetzt noch hinzustellen und rumzuheulen, dass Intel ja dies und jenes mit IHRER Software tun, wirft halt langsam den Schatten eher in die andere Richtungund geht eher nach hinten los.

LG
Zero
 
ZeroStrat schrieb:
Ich denke schon, dass AMD das Fan-Verhalten bewusst mit einkalkuliert.
Du meinst so wie Intel das Fan-Verhalten bewusst mit einkalkuliert, dass sie verteidigt werden egal was sie tun?
ZeroZerp schrieb:
Einige gehen davon aus, dass man dazu verpflichtet sei, die Software so zu gestalten, dass sie auch optimal auf einem Konkurrenzprodukt läuft.
Wie oft willst du den eigentlich noch bringen? Ich und afaik alle anderen regen sich nicht über mangelhafte Optimierung sondern über eine undokumentierte Pessimierung auf. Aber entweder bist du auf dem Ohr taub oder du meinst wenn du das nur oft genug wiederholst glauben alle irgendwann drann.
 
Ned Flanders schrieb:
Wie oft willst du den eigentlich noch bringen? Ich und afaik alle anderen regen sich nicht über mangelhafte Optimierung sondern über eine undokumentierte Pessimierung auf. Aber entweder bist du auf dem Ohr taub oder du meinst wenn du das nur oft genug wiederholst glauben alle irgendwann drann.
Nein- Wie ich bereits weiter oben schrieb ist genau das der unüberwindbare Kern der Diskussion.
In dem Punkt kommen wir nicht überein.

LG
Zero
 
  • Gefällt mir
Reaktionen: Ned Flanders
Sehr schön, dann schaffen wir es ja endlich hier darüber überein zu kommen, dass wir darüber nicht übereinkommen.

Ich sehe übrigens gerade, dass Intel im Dev Guide der MKL 2020 gegenüber 2019 und vorangegangenen eine Änderung vorgenommen hat

1585994616485.png


Immerhin steigt das Level an Transparenz. Auch wenn da eigentlich stehen sollte, das sie in einem Fallback Modus oder einen Kompatibilitätsmodus wie Du es genannt hast läuft. Dank der Presse die das ganze hatte, dürfte das ja mittlererweile eh jeder mitbekommen haben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Argoth, Iscaran, Denniss und 2 andere
Und diese Transparenz passiert auch nur, weil sie sonst rechtlich angreifbar bleiben. Wer jetzt noch glaubt das Intels Verhalten legal und fair ist, hat den Schuss immer noch nicht gehört.
 
  • Gefällt mir
Reaktionen: Ned Flanders
Zurück
Oben