Archiv verlassen und diese Seite im Standarddesign anzeigen : Nvidias komische Berechnungen
Ok jetzt will ich doch mal was zu schreiben. In einem Paper gibt NV folgendes von sich:
Radeon HD 2900 vs. GeForce 8800 Architectural Comparison
Radeon HD 2900 has 320 shaders but GeForce 8800 GTX has only 128 shaders. What’s the deal?
AMD counts their standard ALU and special-function ALUs to reach 320. GeForce 8800 GTX has 128 standard ALUs and 128 special function units. By this method of counting, GeForce 8800 GTX has 256. So Radeon HD 2900 has 25% more shader ALUs, but GeForce 8800 GTX ALUs are clocked 82% faster and 8800 GTS ALUs are clocked 62% faster. The GeForce 8800 GTX is faster overall. The 8800 GTS and Radeon HD 2900 are comparable.
Die beiden letzten Sätze stimmen im Großen und Ganzen, jedoch nur in Real-World-Tests, nicht wenn es um reine arithmetische Power geht. Der Rest ist sehr ... verbogen.
Es stimmt dass AMD die SFU (Special-Function-Unit) mitzählt. Aber: Diese beherrscht nebenbei auch MAD, ist also auch eine normale Shader-Unit. Das unterschlägt NV. NV zählt beim G80 128 SFUs, das ist zwar korrekt, diese können aber kein MAD ausführen. Außerdem können sie nicht wie AMDs SFU pro Takt eine SFU berechnen, sondern nur alle vier Takte eine. "Effektiv" sind es also nur 32 SFUs für den G80.
The GeForce 8800 uses a scalar architecture. The Radeon HD 2900 uses a superscalar architecture with VLIW instructions. Which shader architecture is better?
Die lange Antwort habe ich nicht mitzitiert, denn sie geht am Punkt vorbei. Es ist relativ egal, ob es eine "skalare" oder VLIW-Architektur ist. Andere Umstände beeinflussen die Endleistung viel stärker. Dass NV schreibt, das VLIW-Prinzip wieder aufgegeben zu haben, impliziert dass AMD auf veraltete Technologie setzt. Dabei ist VLIW (Very Large Instruction Word) ein ganz normaler, "legitimer" Ansatz, der per se weder modern noch veraltet ist. Die G80-ALU-Architektur ist zwar schon effizienter, dafür ist die arithmetische Maximalleistung beim R600 ein gutes Stück höher. Bei G70 vs. R580 war es noch andersrum.
Beim AA-Vergleich unterschlägt NV die CFAA-Möglichkeit zur Edge Detection, welches die im Paper gezeigten Nachteile eliminiert. Bei CSAA wird von vollem 16x gesprochen ohne zu erwähnen, dass dies nicht für Schnittkanten gilt.
Nvidia hat das gute Recht, die Vorteile des G80 zu diskutieren. Doch wer sich auf Nvidias Darstellung verlässt, sitzt simpel gesagt gründlicher Desinformation auf. Es wäre viel seriöser, wenn NV vernünftig argumentieren würde. Seltsamerweise werden handfeste R600-Kritikpunkte, wie die Bezeichnung der AA-Modi nicht angesprochen.
Auch ATI/AMD betreibt seit längerem das Spielchen. Ich sage nur 14x AA (omg), oder jetzt 16x AA (lol), oder 4:1-Komprimierung bei Normalmaps (roflmao.) Jeder IHV sieht sich im Recht und will uns Journalisten doch nur aufklären, wie es wirklich ist. Dazu taugen aber die Paper nichts. Überhaupt funktioniert die Desinformation nur bei Journalisten, die von der Materie keine Ahnung haben. Das mag zwar die Mehrzahl sein aber was bringt es, wenn desinformierte Presse die keine Ahnung hat dem Leser was erklärt, was er nicht versteht?
Und setzt man nicht seine Reputation aufs Spiel, wenn man mit höchst fragwürdigen Rechenwegen "beweist", wie überlegen die eigene Hardware sei?
Nakai
2007-06-04, 16:06:06
Wie kommen die auf 128 SFUs? In jedem Cluster sind doch nur 4 SFUs, was bei 8 Stück 32 SFUs macht. Oder bin ich falsch informiert?
mfg Nakai
AnarchX
2007-06-04, 16:12:20
Da hast du sicherlich es mit den "effektiven" SFUs verwechselt, schau dir einfach nochmal bei B3D den Overview zum G80 an, da werden 16 pro Cluster gezeigt:
http://www.beyond3d.com/content/reviews/1/5
Wie kommen die auf 128 SFUs? In jedem Cluster sind doch nur 4 SFUs, was bei 8 Stück 32 SFUs macht. Oder bin ich falsch informiert?
mfg NakaiEs sind 128 SFUs, die aber 4 Takte für eine SFU brauchen. Sie können allerdings auch pro Takt einen Interpolator liefern.
Nakai
2007-06-04, 16:13:33
Okay, das kommt davon, wenn man dem Englischem nicht so mächtig ist und außerdem wenn man nicht so aufmerksam liest.
Es sind 128 SFUs, die aber 4 Takte für eine SFU brauchen. Sie können allerdings auch pro Takt einen Interpolator liefern.
Ja, das weiß ich.
mfg Nakai
Nakai
2007-06-04, 16:41:44
Es stimmt dass AMD die SFU (Special-Function-Unit) mitzählt. Aber: Diese beherrscht nebenbei auch MAD, ist also auch eine normale Shader-Unit. Das unterschlägt NV. NV zählt beim G80 128 SFUs, das ist zwar korrekt, diese können aber kein MAD ausführen. Außerdem können sie nicht wie AMDs SFU pro Takt eine SFU berechnen, sondern nur alle vier Takte eine. "Effektiv" sind es also nur 32 SFUs für den G80.
Wenn das der Fall, dass jede SFU des R600 ein MAD durchführen kann, wird sie dann auch für Skalare Operationen verwendet, wenn keine SFUs anfallen? Dann würde auch die Geschichte mit dem 4+1 Splitt stimmen...
mfg Nakai
reunion
2007-06-04, 17:03:12
Seltsam finde ich vorallem, dass man behauptet, dass die R600-TMUs keine 16 FP16-Samples pro Takt schaffen, was ja nachweislich falsch ist.
ist doch eigentlich nichts neues dass jeder versucht sein eigenes produkt so gut wie möglich dastehen zu lassen, trotzdem schön dass solche "ungereimtheiten" aufgedeckt werden.
insgesamt zählt aber sowieso was "hinten" rauskommt, und nicht wer die "bessere" bzw. "modernere" architektur hat.
Wenn das der Fall, dass jede SFU des R600 ein MAD durchführen kann, wird sie dann auch für Skalare Operationen verwendet, wenn keine SFUs anfallen?Klar.
Nakai
2007-06-04, 18:59:57
Klar.
Wie oft fallen eigentlich SFs an. Und wie oft wird die SFU für normale Berechnungen benutzt?
mfg Nakai
Wie oft fallen eigentlich SFs an. Und wie oft wird die SFU für normale Berechnungen benutzt?Das hängt vom Shader ab. In der Regel zählt man nur MAD-Leistung, weil fast alle Befehle MAD-Operationen sind. SFUs sind bei aktueller Balancierung im Shader in der Regel nicht der Flaschenhals.
Nakai
2007-06-04, 19:12:15
Wieso hat man dann im R300 und den Nachfolger die Shader mit ADDs erweitert, wenn MAD als Hauptfaktor gesehen wird?
Achja noch viele Dank für die Erklärung.
mfg Nakai
Wieso hat man dann im R300 und den Nachfolger die Shader mit ADDs erweitert, wenn MAD als Hauptfaktor gesehen wird?Weil man für die Mini-ALU-Operationen eh ein ADD braucht. Eigentlich nur ein ADD mit bestimmten Konstanten, aber dann kann man es auch gleich zum vollen ADD mit zwei wählbaren Inputs umbauen. So kann man entweder die Bias-Operation oder ein freies ADD nutzen. NV-GPUs haben (soweit ich weiß) immer zusätzlich Mini-ALUs, die nicht weiter aufgebohrt wurden.
Das zusätzliche MUL beim NV40 wird mit zur Perspektivkorrektur beim Interpolator genutzt, ist also auch eine Art ausgelagerte Einheit. Bei Radeon-Karten gehört dieses MUL zum normalen Interpolator (und wird deshalb auch nicht bei den FLOPs, wenn man ADD und MUL zählt, mitgerechnet.)
Armaq
2007-06-04, 19:47:56
aths, diese Papiere verfasst auch sicher kein Ing., wahrscheinlich sieht die Dev.-Abteilung sie nichtmal, weil sie sonst schamesrot würde.
Die Frage ist wie man ehrlich seine Vorteile diskutiert. Bringt Ehrlichkeit denn überhaupt etwas bei der Produktvermarktung?
Frei nach dem Motto, also für 10KG unseres Siliziums sterben nur 1,4 Kinder, bei AMD sind es 1,8.
PhoenixFG
2007-06-04, 23:26:11
Verkäufer sind im Grunde immer Lügner, weil sie zumindest Teile der Wahrheit verschweigen.
Wie nah die Argumentationskette sich an der Realität orientieren muss, hängt ganz von der zu überzeugenden Person ab. Hat die Person keine Ahnung, so kann man relativ dick auftragen. Hat man jemanden vom Fach vor sich, muss man näher bei der Wahrheit bleiben. Erst wenn das eigene Produkt dem der Konkurrenz in ALLEN Belangen überlegen ist, kann ich auf das Lügen verzichten.
Silverbuster
2007-06-05, 01:29:28
Ok... ich bin einer derjenigen der nicht 100%ig in der Materie steckt und gerne mit den Zahlen auf den jeweiligen Papieren argumentiert.
Um mir aus diesem mißstand herauszuhelfen, würde ich es mit Begeisterung aufnehmen wen mir mal jemand eine Seite Posten könnte, wo man quasi einen Crashkurs in Sachen GPU Architektur bekommt. Möglichst auf Deutsch (Schulenglisch ist lange her). Es muss nicht bis ins kleinste Detail gehen, nur soweit das ich eurer Diskussion halbwegs folgen kann.
Das geht nicht so einfach. Im Forum wird immer wieder mal einer Art Crashkurs gefragt. Zwar könnte ich anfangen zu erklären was eine ALU ist und welche ALU-Operationen man für die arithmetische Gesamtleistung zählt. Aber die praktische Endleistung hängt noch von vielen anderen Sachen ab, zum Beispiel vom Readport-Limit, von der Größe des Registerfiles, von der Art der TMU-Ansteuerung und so weiter. Um das alles zu verstehen ist es notwendig, die mathematischen Prinzipien der Erzeugung von Rastergrafik zu kennen. Dafür ist dann aber höhere Mathematik notwendig.
Ich will nicht sagen "fang gar nicht erst an", sondern "fang bei den Grundlagen an".
Silverbuster
2007-06-05, 05:45:21
Ok.. dann kein Crashkurs. Anders.... wo gibts den dazu eine ausführliche Erklärung auf Deutsch, die aber auch für Einsteiger verständlich ist? Ich bin ja nicht völlig unwissend und Mathe sollte auch nicht das Thema sein :biggrin: Nur weiss ich nciht so recht wo ich Anfangen soll mich zu informieren. Alles was ich immer finde sind mehr oder minder spezialisierte Auszüge. Da wird einem erklärt was Alus sind, hier was eine Shaderunit genau macht, aber mal so eine Gesamtübersicht mit einer Erklärung, die finde ich nicht wirklich. Sowas suche ich.
Nakai
2007-06-05, 12:42:46
Ich könnte meinen eigenen Infothread vorsetzen, aber da sind einige falschen Infos drin.
Unaktualisierter Thread mit vielen Falschinfos.^^ (http://www.spieleforum.de/forum/f53/grafikkarten-infothread-v-2-00-a-t292576/)
Bitte nicht lästern, ich weiß, der Thread ist teilweise etwas arm.^^
mfg Nakai
Silverbuster
2007-06-05, 13:49:18
Ich lästere nie und bin für jede Info dankbar. :wink:
Werd mir das mal in Ruhe durchlesen. Aber fals noch jemand Seitenvorschläge hat, nur her damit.
Ich lästere nie und bin für jede Info dankbar. :wink:
Werd mir das mal in Ruhe durchlesen. Aber fals noch jemand Seitenvorschläge hat, nur her damit.Dieses verlinkte Posting hat zwar erkennbar Mühe gemacht, würde ich allerdings nicht unbedingt empfehlen. Denn teilweise geht es bereits ins Detail, andererseits werden massiv Grundlagen einfach ausgelassen.
Ok.. dann kein Crashkurs. Anders.... wo gibts den dazu eine ausführliche Erklärung auf Deutsch, die aber auch für Einsteiger verständlich ist? Ich bin ja nicht völlig unwissend und Mathe sollte auch nicht das Thema sein :biggrin: Nur weiss ich nciht so recht wo ich Anfangen soll mich zu informieren. Alles was ich immer finde sind mehr oder minder spezialisierte Auszüge. Da wird einem erklärt was Alus sind, hier was eine Shaderunit genau macht, aber mal so eine Gesamtübersicht mit einer Erklärung, die finde ich nicht wirklich. Sowas suche ich.Auch bei vielen Leuten der Fachpresse erlebe ich, dass sie sich in Begriffen verlieren, die sie gar nicht verstehen können. Was eine Shaderunit genau macht, kann man sich zum Beispiel selbst herleiten, wenn man weiß, was ihre genaue Aufgabe ist.
Was wichtig ist, um eine GPU zu verstehen, sind die absoluten Grundlagen,
- wie Geometrie transformiert wird
- wie sie auf den Bildschirm projiziert und anschließend gerastert (in Pixel zerlegt) wird
- was Normalen sind und wozu man sie bei der Beleuchtung braucht
Der Rest, wie Pixelshading oder Vertexshading, lässt sich dann relativ einfach erklären.
Silverbuster
2007-06-05, 15:47:39
Dieses verlinkte Posting hat zwar erkennbar Mühe gemacht, würde ich allerdings nicht unbedingt empfehlen. Denn teilweise geht es bereits ins Detail, andererseits werden massiv Grundlagen einfach ausgelassen.
Naja... hast du was besseres?
Die von dir geforderte Mathematik sollte jeder Ingenieursstudiengang im Vordiplom abgehandelt haben.
Naja... hast du was besseres?Den Tipp, sich es nicht vorkauen zu lassen. Wie in allen Fachgebieten ist es nicht damit getan, sich einfach ein paar leicht verständliche Artikel durchzulesen um anschließend den Durchblick zu haben.
Die von dir geforderte Mathematik sollte jeder Ingenieursstudiengang im Vordiplom abgehandelt haben.Leider studieren nicht alle Interessierten Ingenieurswissenschaften.
Nakai
2007-06-05, 16:30:37
Dieses verlinkte Posting hat zwar erkennbar Mühe gemacht, würde ich allerdings nicht unbedingt empfehlen. Denn teilweise geht es bereits ins Detail, andererseits werden massiv Grundlagen einfach ausgelassen.
Dieser Thread hätte eh schon vor Wochen aktualisiert werden sollen.
Aber da mir ebenfalls einige Grundlagen fehlen, habe ich selbst gesagt, dass dieser Thread nicht empfehlenswert ist.^^;)
Leider gibt es soviel zu erwähnen und da müsste ich mehr als nur ein kleines Update durchführen.
Wie in allen Fachgebieten ist es nicht damit getan, sich einfach ein paar leicht verständliche Artikel durchzulesen um anschließend den Durchblick zu haben.
3DC hat ein paar gute Artikel, jedoch gehen diese sehr ins Detail. Schau mal auf CB, die haben ein paar gute Erklärungen zu den GPUs. Damit ist es aber noch nicht getan, da dort einiges ausgelassen oder falsch dargestellt wird.
mfg Nakai
deekey777
2007-06-05, 16:32:54
Coda hat mal ein sehr gelungenes PDF gepostet, wo eine Rendering-Pipeline erklärt wird.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3842884#post3842884
Hoffe der Link funzt:
http://stud3.tuwien.ac.at/~e0325258/files/linalg.pdf
Kleine Einführung in die Achsentransformation.
Eigenwerte:
http://de.wikipedia.org/wiki/Eigenwert
Hoffe der Link funzt:
http://stud3.tuwien.ac.at/~e0325258/files/linalg.pdf
Kleine Einführung in die Achsentransformation.
Eigenwerte:
http://de.wikipedia.org/wiki/Eigenwert
Was soll das mit dem Thema zu tun haben?
Achsentransformation braucht man immer und über Matrizen eine Geometrie zu verbiegen sollte dann nicht mehr der große Sprung sein, oder? Soll nur ne Einführung in die Matrizenrechnung sein.
Dann gleich mit Eigenwerten zu kommen ist bisschen heftig. Bevor man Einführungen in die Matrizenrechnung verlinkt wäre es sinnvoll, erst mal Vektoren zu behandeln und die abbildende Eigenschaft von Matrizen zu besprechen.
Nakai
2007-06-05, 22:58:24
Kann man dazu nicht einen Erklärthread machen?^^
Ich finde es ehrlich gesagt auch hilfreich, da es sehr viele gibt, die Nachhilfe auch dort brauchen oder wollen?
mfg Nakai
Noch mal: Es funktioniert nicht, es sich erklären zu lassen. Man muss es sich letztlich selbst beibringen. Man kann sich dann einzelne Details erklären lassen.
Es sich letztendlich selbst beibringen ist auch in einer Uni notwendig. Denn hören ist noch nicht verstehen. Aber es würde wohl nichts dagegensprechen, z.B. Links zur kompletten Vektorrechnung aufzulisten. Die xxx Seiten muss man sich dann schon selbst durchlesen (und hoffentlich verstehen). Mit dem Gerüst könnte man dann den Rest aufbauen. Es ist wohl nicht notwendig, alles hierzu selbst zu schreiben.
Für ganz neugierige: an einer Fernuni die richtigen Kurse wählen oder wenn man schon an einer technischen Universität oder TH ist, dann einfach mal in die richtigen Vorlesungen tapern. Keine Angst, die beißen nicht ;).
Man muss nicht gleich ein richtiges Studium absolvieren. Warum man bei 3D-Grafik in einem homogenen Koordinatensystem rechnet (4D statt 3D) ist für den Einsteig auch erst mal nicht so wichtig. Wie man eine Transformationsmatrix berechnet, kann auch erst mal in den Skat gedrückt werden – wichtiger wäre erst mal, zu wissen was eine Transformation ist und für das Verständnis der GPU-Architektur, welche mathematischen Operationen dafür erforderlich sind (nämlich ADD und MUL.)
Silverbuster
2007-06-06, 05:36:59
Was soll das mit dem Thema zu tun haben?
Das frag ich mich auch :rolleyes:
@aths
Ich glaube du verstehst nicht ganz worauf ich hinaus will. Vielleicht hab ich es auch falsch rüber gebracht. Mir geht nicht darum das ich bis ins kleinste Detail weis wie alles funktioniert, das traue ich im übrigen niemanden hier im Forum zu. Aber ich würde schon gerne mal wissen was die Shader eigentlich genau machen, was MUD ist u.s.w.! Und ich bezweifel das man hierzu Jahrelang Infos schaufeln muss. In der Regel kann ich extrem schnell verstehen, wen ich mal irgendwoher etwas vernünftiges zu lesen bekomme. Nur wo fange ich da an?
Und ich häte gerne mal eine schematische Aufstellung der Pipes, wo ich sehe in welcher Reihenfolge was genau kommt. Leider finde ich dazu meist nur sehr oberflächliche Schemas die nicht wirklich genau sind.
Nakai
2007-06-06, 10:02:51
Man kann sich dann einzelne Details erklären lassen.
Und da wär ich schon bei der Transformation. Kannst du nicht einen Link posten in dem das etwas erklärt bzw. dargestellt wird?
Und ich häte gerne mal eine schematische Aufstellung der Pipes, wo ich sehe in welcher Reihenfolge was genau kommt. Leider finde ich dazu meist nur sehr oberflächliche Schemas die nicht wirklich genau sind.
Die PDF von Coda stellt das schön dar.
Schaus dir nochmal an.
mfg Nakai
@aths
Ich glaube du verstehst nicht ganz worauf ich hinaus will. Vielleicht hab ich es auch falsch rüber gebracht. Mir geht nicht darum das ich bis ins kleinste Detail weis wie alles funktioniert, das traue ich im übrigen niemanden hier im Forum zu. Aber ich würde schon gerne mal wissen was die Shader eigentlich genau machen, was MUD ist u.s.w.! MUD ist ein Multi-User-Dungeon, und Vorläufer von MMORPGs. Meinst du MAD?
Um zu wissen was die Shader eigentlich genau machen, braucht man sehr viel Detail-Wissen drumherum. Wenn ich zum Beispiel erzähle, dass der Shader als Input auch einen Interpolator auswählen kann, müsstest du erst mal wissen, was ein Interpolator im Kontext der Shader-Pipeline ist.
Und ich bezweifel das man hierzu Jahrelang Infos schaufeln muss. In der Regel kann ich extrem schnell verstehen, wen ich mal irgendwoher etwas vernünftiges zu lesen bekomme. Nur wo fange ich da an?Das Thema ist komplex genug, dass man da nicht ein paar leicht lesbare Artikelseiten schreiben kann um den anderen auf einen "vernünftigen" Wissensstand zu bringen. Wie gesagt meine ich nicht "dann lasst es gleich sein", sondern "fangt bei den Grundlagen an." Was eine Shader-Pipe genau macht, kann man sich dann mit dem nötigen Wissen um die 3D-Berechnung praktisch von alleine herleiten.
Wenn ich das noch kurz sagen darf: "@aths" ist falsch. @ steht für at, gemeint ist eher to. Am besten lässt man das @ ganz weg, das liest sich dann auch bequemer.
Und ich häte gerne mal eine schematische Aufstellung der Pipes, wo ich sehe in welcher Reihenfolge was genau kommt. Leider finde ich dazu meist nur sehr oberflächliche Schemas die nicht wirklich genau sind.Mit genaueren Diagrammen könntest du nichts anfangen solange dir die dahinterstehende Mathematik nicht klar ist.
Und da wär ich schon bei der Transformation. Kannst du nicht einen Link posten in dem das etwas erklärt bzw. dargestellt wird?Transformation war einige Wochen lang Thema bei der Mathe-Vorlesung. Da kann man nicht einen Link posten, wo man sich 3-4 Seiten durchliest und das dann alles weiß. Aber du kannst einfach nach "Transformationsmatrix" googeln und diverse Artikel anlesen um einen auf deinem Niveau zu finden und dich so Stück für Stück reinlesen. Bei Detailfragen sind dir im Forum sicher eine Menge Leute gerne behilflich.
Mit Matrizen und Matrizenmultiplikation kann man (nach Bildung der Inversen der Matrix) zum Beispiel Gleichungssysteme lösen. Was ist das Inverse einer Matrix, was ist die Determinante der Matrix – das ist zwar nicht so wichtig für die 3D-Grafik, aber nützliches Nebenwissen. Bevor es zur Matrix geht sollte klar sein, was ein Vektor ist. Die Geometrie wird der Grafikkarte immerhin als Folge von Vektoren (inkl. Verbindungsinformationen) übergeben. Da gibt es Dreiecke, Vierecke, Fächer und Streifen – letztlich wird alles in Dreiecke aufgelöst. Warum eigentlich? Welche mathematischen Eigenschaften hat das Dreieck, dass letztlich ausschließlich Dreiecke gerendert werden? Das sind Fragen die man klären sollte bevor man liest, wie zum Beispiel Texturfilterung oder Bumpmapping funktioniert.
Nakai
2007-06-06, 18:29:59
Vielen Dank, die Tipps werd ich befolgen.
mfg Nakai
Wenn ich das noch kurz sagen darf: "@aths" ist falsch. @ steht für at, gemeint ist eher to. Am besten lässt man das @ ganz weg, das liest sich dann auch bequemer.
Das stimmt so nicht, "at" steht ja auch für "an".
Das @<Name> soll ja sowas bedeuten wie "diese Zeilen sind an <Name> gerichtet". Und das ist dann "aimed at", "targeted at", "directed at"
Natürlich würde auch ein "to<Name>" im Sinne vom "Ich spreche jetzt ZU <Name>" passen, aber falsch ist das @ dennoch nicht.
Das stimmt so nicht, "at" steht ja auch für "an".Aber nicht für das "an", was beim Adressaten verwendet würde.
Natürlich würde auch ein "to<Name>" im Sinne vom "Ich spreche jetzt ZU <Name>" passen, aber falsch ist das @ dennoch nicht.Doch. Außerdem sieht es doof aus. "2aths" etc. wäre richtiger, sieht aber auch nicht gut aus.
Es gab mal ein Paper von Dolby Laboratories, welches DTS miesmachen wollte. Das konnte durch ein Gegenpaper leicht auseinandergenommen werden. Ich würde versuchen, mir Blamagen solcher Art zu ersparen.
aths, diese Papiere verfasst auch sicher kein Ing., wahrscheinlich sieht die Dev.-Abteilung sie nichtmal, weil sie sonst schamesrot würde.Das sollte sie aber. Wenn man Informationen an die Presse rausgibt und sie trainiert, solchen Infos total zu misstrauen, hat keiner was davon.
Verkäufer sind im Grunde immer Lügner, weil sie zumindest Teile der Wahrheit verschweigen.
Wie nah die Argumentationskette sich an der Realität orientieren muss, hängt ganz von der zu überzeugenden Person ab. Hat die Person keine Ahnung, so kann man relativ dick auftragen. Hat man jemanden vom Fach vor sich, muss man näher bei der Wahrheit bleiben. Erst wenn das eigene Produkt dem der Konkurrenz in ALLEN Belangen überlegen ist, kann ich auf das Lügen verzichten.Wenn man gewisse Stärken der Konkurrenz anerkennt, gewinnt man an Glaubwürdigkeit. Wenn die zu überzeugende Person keine Ahnung hat, kann man sich auch Rechnungen wie in diesem Paper ersparen, weil der Rezipient eh aussteigt. Kann der Empfänger rechnen und hat ein wenig Ahnung was den G80 angeht, sieht er schnell, dass die aufgemachten Rechnungen falsch sind.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.