Java ist ne verrückte Sprache....

Java ist ne verrückte Sprache.... (47 Beiträge, 575 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ausgehend von der Idee, daß Java ja eine kompilierte Sprache ist, macht der Compiler in P-Code recht wenig...

Ich bin mal über http://www.microjava.com/articles/techtalk/optimization?PageNo=4 gestolpert - Optimierungstechniken für J2ME (bzw. Java generell).

Was ich wirklich krass finde:
1.) Loop unrolling... Muß der Coder selbst machen, der Compiler kriegt das net hin ???
2.) >> ist schneller als ne Division ? Warum um Himmels willen... Ich meine, klar auf Assemblerebene und von mir aus auf P-Code-Ebene... Nur jeder normale C-Compiler wandelt sowas um, warum net javac ?
3.) Das IMHO allerkrasseste:

  public static final int STATE_RUNNING = 1000;
  public static final int STATE_JUMPING = 2000;
  public static final int STATE_SHOOTING = 3000;
  switch ( n ) {
    case STATE_RUNNING:
      doRun();
    case STATE_JUMPING:
      doJump();
    case STATE_SHOOTING:
      doShoot();
  }

There's nothing wrong with this, and the int constants are nice and far apart, in case we might want to stick another constant in between RUNNING and JUMPING, like STATE_DUCKING = 2500. But apparently switch statements can be compiled into one of two byte codes, and the faster of the two is used if the ints used are close together, so this would be better:

  public static final int STATE_RUNNING = 1;
  public static final int STATE_JUMPING = 2;
  public static final int STATE_SHOOTING = 3;

Was ist denn das für eine schräge Sprache ? Ich mein,alles sind ints, und switch()-Statements sind unterschiedlich schnell, je nachdem ob die Werte näher sind ???

Man muß sich direkt mal Java-PCode-Assembler ansehen, der muß ja krank sein

Erzähl das ihm: http://forum.geizhals.at/userinfo.jsp?id=85411

Solltest aber auf Selbstgespräche stehen

Ich gebe zu, ich habe den Artikel aus Zeitgründen nicht gelesen.

Aber folgendes ist zu bedenken:

MicroJava (besser gesagt die Runtime) ist eher eine eingeschränkte Java Umgebung. Diese Beschränkungen gelten scheinbar auch für die Optimierungen. Gibt es JIT Compilation unter MicroJava?

Bei Java am Desktop ist eigentlich der JIT (Just in Time) Compiler mit dem alles steht und fällt. Dieser übersetzt den P-Code in native Code. Und dieser dürfte zwischenzeitlich nicht so schlecht sei, was die Code-Qualität betrifft.

Was ist denn das für eine schräge Sprache ? Ich mein,alles sind ints, und
switch()-Statements sind unterschiedlich schnell, je nachdem ob

Den Absatz verstehe ich so - wenn die int nahe zusammenliegen kann scheinbar eine kürzerer Opcode-Folge erzeugen werden, da vielleicht nur mehr ein byte für einen codierten case-Wert nötig ist. Bei größeren Werten sind 4 bytes von Nöten für einen case-Wert.

06.11.2006, 07:51 Uhr - Editiert von nergal, alte Version: hier

Nun ja...

Erstens ist AFAIK JIT kein Muß bei einer JavaVM... Sondern nur ein "should" oder so.
Also auf JIT verlassen sollte nicht sein.

Und gerade der JIT widerspricht deinem letzten Absatz/Argument:
Wenn man 2 ints vergleicht geht das auf einem 32bit-prozzi weit schneller als wenn man 2 Bytes vergleicht... Des weiteren wäre dann die Doku ungenau, denn dein Argument würde bedeuten, daß nicht der Abstand der Werte bedeutend sei, sondern ob wert&0xffffff00 dasselbe ergibt. Also ein switch mit 1 und 2 wäre gut, eines mit 255 und 256 schlecht... Davon sagt die Doku aber nix.

Abschließend:
wenn >> besser als /2 ist - dann soll IMHO ein Compiler selbständig den besseren Code erzeugen und net erst nachher der JIT das uU ausbügeln... Da paßt was echt net an javac

Und gerade der JIT widerspricht deinem letzten Absatz/Argument:

Wir reden jetzt aber von byte Code und nicht von JIT! Der Artikel bezieht sich scheinbar auf byte Code. Und kürzere Opcode ist schneller als längerer Opcode - so interpretiere ich dies.

Das war eh klar...

Und es ist mir auch klar, daß ein javac nicht automatisch loop-unrolling machen dürfte... sondern daß das - so wie beim gcc - eine extra-Option sein müßte.

Also im Endeffekt würde ich mir von einem javac so Optionen wie beim gcc wünschen "-Os" (optimieren auf Platz), "-O" (standard-Optimierungen) "-O2" (*TRÖT* nach speed), "-O3" (Optimierungen, die den Programmablauf modifizieren könnten).

Aber wenn ein ">>" immer schneller als ein "/2" ist, dann sollte der Compiler in allen Fällen ">>" verwenden.
Und nachdem die Zielplattform in Wirklichkeit immer dieselbe ist (nämlich eine spezifische VM), könnte er auch - zumindest einige - agressive Optimierungen durchführen.

Und grade was >> und /2 betrifft bin ich mir jetzt nicht sicher ob das nicht ein J2ME Spezifikum ist.

Glaube ich nicht... Würde mich zumindest überraschen.

Sry, das ist Blödsinn. Ich kenn viele Projekte, die auf verschiedenen Plattformen laufen.

Aber meist auf denselben JavaVMs, oder ?
die JavaRuntime ist ja nicht nur eine Bibliothekensammlung - sondern stellt einen Virtuellen Prozzi mit virtuellem OS dar. Also müßte die Optimierung logischerweise zB "Optimize-for-1.4" lauten... und nicht "Optimize-for-RS/6000".

Echt ?
Ist mir nicht aufgefallen... Ich vermutete das Gegenteil

Begründung - rein aus der Intel-Welt:
Wenn du Assembler gecodet hast, dann gab es massiv Unterschiede zwischen den CPUs...
Hausnummer:
Bis zu einem 80286 war es schneller, den Akkumulator mit "XOR AX,AX" zu löschen, wärend es ab dann mit einem "MOV AX,0" schneller ging.
Besonders krass wurde es mit dem PentiumII, bei dem Zugriffe via GS-Register mit einem ordentlichen Straffaktor an Zeit (IMHO sogar so krass wie 50 oder so) geahndet wurden.

Dementsprechend werden ja CPU-Intensive binaries gerne auch pro CPU übersetzt... Nur bei SunJava eben nicht. Ich halte es zwar durchaus für möglich, daß in dem Binary Verzweigungen existieren a la "Wenn du ein 386er bist, mach es auf Weg a, wenn du ein Pentium bist auf Weg b, ..." - halte es aber für unwahrscheinlich.

Abschließend:
Besonders unwahrscheinlich halte ich es, wenn bei derselben VM verschiedene Wege auf verschiedenen Systemen bevorzugbar wären... Wenn man also zB sagen würde "Auf Sun-Rechnern ist es besser, mit Strings herumzuarbeiten als mit Stringbuffern"... Ist dem so ? Glaube ich eben nicht... Und drum könnte hier die "-O3"-Operation ins Spiel kommen - a la "ersetze Stringzugriffe durch Stringbuffer", genauso wie ein gcc-C-compiler auch mal bei Integer-Operationen gerne die FPU "mißbraucht", wenn es im Kontext schneller ist...

Optimierung setzt ja jetzt nicht nur rein auf Prozessorebene an, da gehts auch um Threadhandling, Garbage Collection, Fileaccess, Datentypen usw...

Sowas war eh klar...

Nur passieren da 2 Paar Schuhe - zumindest IMHO, aber ich arbeite mich ja erst ein in Java, drum die DAU-Fragen:
Einerseits die Optimierungen, die stattfinden um den ByteCode zu erzeugen
Andererseits die Optimierungen, die in der VM stattfinden (also JIT, ...).

Grundsätzlich gab es (mit einer Ausnahme) immer die Philosophie, daß der Compiler Zeit hat - und der alle Optimierungen für das Zielsystem machen soll. Am Zielsystem soll das Proggy dann so schnell wie möglich laufen. Da Optimierungen Zeit kosten -> Compiler soll sie machen. Das Zielsystem unterstützt nur mit Branch Prediction, L1-Caches, ... Natürlich umso besser, je mehr der Compiler darauf geachtet hat (zB loop-Code in eine Cacheline).

Die Einzige Ausnahme, mit der ich mich vorher mal befaßte, war EPIC... Da konnte der Compiler einiges nicht sinnvoll optimieren beim setzen seiner Tags.

Bei Java bin ich nun davon ausgegangen, daß zumindest immer derselbe Weg der schneller sein wird.
Beispiel:
In dem Link wurde gebracht, daß ein

for (f = 0 ; f < 10 ; f++) { machWas(); }

langsamer sei als

machWas();machWas();machWas();machWas();machWas();machWas();machWas();machWas();machWas();machWas();

Abgesehen davon, daß ich das echt pervers finde (trickse ich mit sowas den eventuell vorhandenen JIT aus ???? Oder auch ohne JIT: Wieso ist 10x interpretieren schneller als die Loop?) - so rennen doch J2MEs auf unterschiedlichen Prozessoren, handy-Ossen, ... Scheinbar ist aber manuelles Loop-Unrolling immer schneller... So behauptet zumindest der Link. Nun denn, dann soll es aber der Compiler machen

Scheinbar ist aber manuelles Loop-Unrolling immer schneller

Ist doch klar...bei einer Schleife hast du ja noch ein paar Arbeitsschritte mehr (also alles was im for steht...).

Das gilt bei Maschinensprache... Sicher.

Aber bei Interpretierten... kann ich Dir nur langsam folgen...

Gehen wir von folgendem aus:

for ( f = 1 ; f < 1000 ; f++) {
mach_was();
}

Dann müßte - so mach_was teuer ist - automatisch der JIT anspringen, oder ??
Wenn ich das unrolle, sieht der JIT statt einem Statement, das 1000x durchlaufen wird (also Kandidat ist) stattdessen 1000 Statements, die alle nur 1x durchlaufen werden... Und er muß dann 1000x übersetzen.

Grundsätzlich verstehe ich aber deinen - ausschließlich No-JIT-Punkt... Danke mal.
Dann bleibt aber weiterhin die Frage, warum javac keine -funroll-loops - Option kennt

nochmal: ich hab keine Ahnung von Bytecode optimierung, null, Nüsse.

Das macht nichts

Du hast bei weitem mehr Ahnung als ich, und wenn ich das Forum mißbrauchen kann um mir das Thema zu erarbeiten - gerne

Neue Ideen lieferst jedenfalls... Und in der Folge bin ich eh schon reduzierter mit den Anforderungen hin zu "ok, dann müssen nur nicht-agressive Optimierungen drin sein"

Wenn jedenfalls für Menschen eine Regel aufstellbar ist a la "Unrolle deinen Code" - dann sollte der Compiler das automatisch machen können, wenn du zB "-O" für "Optimiere nach Speed" angibst.... Dasselbe gilt natürlich für alle Regeln wie auch "Verwende >>1 statt /2 bei integer".

Oder von mir aus sollte das ganze ein Präprozessor erledigen - quasi genauso wie wenn du deinen Obfuscator in die Chain hängst, solltest du sowas reinhängen können - oder gibt's da eh was von Sun ??

Anyways, daß man bei einer Interpretierten Sprache manuell unrollen muß wie bei Asse - finde ich oarg (wobei ich bei letzterem wenigstens Macros dafür aufstellen kann

Das könnte allerdings sein...

Von Leuten, die Ahnung haben, wird ja behauptet, daß der JIT weit besser beim detecten von HotSpots ist als es .NET als Quasi-Vm designmäßig werden kann.

Dann wäre halt - gerade mit Rücksicht auf 1000e Jamba-Coder

- eine "Assume-no-JIT"-Option beim javac sinnvoll... beim Java-start kann man ja auch JIT abschalten (-Xint)... Wann macht man das eigentlich ???

Das erinnert mich daran das mich mir Java irgendwann mal wieder vornehmen muss.
.. irgendwann ..

@LinuxSuckz
die unterschiede wird man selber wohl kaum mitbekommen. ausser evtl man macht millionen von loops etc. im endeffekt wird es eine programm nur sehr unwesentlich und nicht wirklich merkbar verlangsamen.
gibt's eigentlich echtzeitanwendungen/-implementationen in/für java?

zum 3. kann ich nur sagen das es eigentlich logisch ist, da der compiler bei größeren zahlen für das vergleichen etc mehr speicher braucht. kommentar zur geschwindigkeit siehe oben.

Nun ja...

Ich habe ja von J2ME gesprochen, also der Microedition auf Handies, ... Und dort ist die Performance-Gschicht echt entscheidend.... Denn die CPUs sind langsam, ne KVM ist auch nicht sehr flott... Und wenn du ein JavaGame schreiben willst, brauchst - so es ein "Echtzeitgame" wird - mindestens 10fps, also maximal 100ms für die Gameloop - das ist echt knapp.

Ad 3: Sehe ich nicht so:
Ein int ist IMHO fix 4 Byte bei Java - also muß er so oder so 4 Bytes vergleichen. Die Größe der Werte (also ob zB 1 oder 1000 drin ist - muß dann normalerweise wurscht sein.

naja evtl optimiert java (gerade bei mobiles) die (integer) werte noch einmal, so das nicht immer fest 4 bytes reserviert werden sondern halt nur das, was auch nur als minimum gebraucht wird.

aber k.a. ... mein erstes und einziges java programm ist schon ein paar jährchen her (schätzungsweise mind 4 oder 5 jahre)

Mfg.

Also wenn das Java machen würde, daß integer variabel groß wären - wäre es eine saudumme unanwendbare Sprache... Denn woher wollte java wissen, ob man das Compilat nicht doch mal von einem anderen Jar aus aufruft... wo dann doch größere Werte herkommen ???

@1: warum (zum teufel) soll das schon der compiler machen (des geht beim JIT oder interpretieren) doch genauso/besser... (hab den bericht nicht gelesen, ob der JIT bzw. interpreter das macht?? )

@2: siehe @1

@3: es geht wohl nicht um "nahe" beieinander, sonder um DIREKT hintereinader, in diesem fall wird wohl optimiert (was du bei 1 und 2 vermisst, ist bei 3 plötzlich "schlecht" ???)

interessant ist diese "optimierung" wohl wirklich nur bei java/handy games ?? usw.

@1: Weil ich nicht von einem KIT ausgehen kann, weil
- er ja bewußt abgeschalten sein könnte (-Xint gibt's ja net sinnlos)
- weil es ihn für die Plattform nicht geben muß (zB J2ME gibt's afaik keine)
- weil auch ein JIT-Compile Zeit kostet.

@2: Warum soll ich da einen JIT bemühen müssen ? Wenn immer a schneller als b ist - dann soll der Compiler a erzeugen... Dazu leistet man sich eben optimierende Compiler, und C-Compiler bekommen das seit den 70ern hin...

@3:Das verstehe ich eben nicht... Typischerweise sieht's in Assembler wohl so aus:

LDAX #Wert
CMP #0x12345678
JMPZ, SPRINGE_ZU_1
CMP #0x123
JMPZ, SPRINGE_ZU_2
...
_DEFAULT_CODE_

Ich kenne echt keine andere Methode, wie man SWITCH-Statements umsetzt...
und mir fällt echt keine Situation ein, wo _nahe_ beieinander liegende Werte leichter/schneller checkbar wären..

@1 und 2: damit beim decompilieren wieder schöner code raus kommt

@3: du könntest AX jeweils mit 0 vergleichen und dann um eins decrementieren ... (so ungefähr..)

@1+2: Määäächtig wichtig

>@1: Weil ich nicht von einem KIT ausgehen kann, weil
>- er ja bewußt abgeschalten sein könnte (-Xint gibt's ja net sinnlos)
>- weil es ihn für die Plattform nicht geben muß (zB J2ME gibt's afaik keine)
>- weil auch ein JIT-Compile Zeit kostet.

nachtrag: du akzepierst also solche "unabwegbarkeiten" welche zu geschwindingkeits unterschieden von sicher mehreren 100% führen ...

aber der compiler muss alles optimieren um in bestimmten (seltenen) extremfällen ein paar prozent rauszuholen ....

also ich weis nicht..

Yup... der Compiler soll optimieren, wann immer es garantiert Sinn macht... Spricht ja nix dagegen, kostet net viel - und kann einiges.

Es soll einfach immer der Grundgedanke gelten "Beim kompilieren hast Zeit, zur Laufzeit net"...
Und wenn es schon so seltsame Phänomene gibt wie "naheliegende Werte sind schneller verglichen" (deine Interpretation mit "Ersetze CMP durch einige DEC (die das Zeroflag beeinflussen(machen net alle Prozzies so - zB der Z80 nur wenn du ein 8bit-Register dekrementierst, nicht aber bei 16bit-Registerpaaren) - könnte bei dem virtuellen Prozzi echt so sein) - dann wird's ja doppelt Schräg.

Denn das bedeutet nichts anderes, als daß er switch() gut optimiert - wärend er es bei "/2" nicht macht... Und Divisionen durch 2 sind ja nicht mal soooo selten - das kann schon mal vorkommen.

@nachtrag:
Die "unabwägbarkeiten" sind nicht so selten... Denn IMHO sind java-Spiele sicher nicht soooo selten bzw. werden nicht in geringer Stückzahl entwickelt/verkauft... Und genau diese Spielchen tragen sicher auch zur Popularität der Sprache bei - beginnend mit Applets (da gibt's wohl ein Verhältnis von mehr als 1000:1 bei Spielkram:"sinnvolle Anwendung").

>wann immer es garantiert Sinn macht...

Loop unrolling...

da wird ja schonmal das classfile größer ...
was u.U. schon wieder negativ sein könnt...

> (deine Interpretation mit "Ersetze CMP durch einige DEC (die das Zeroflag beeinflussen
> (machen net alle Prozzies so - zB der Z80 nur wenn du ein 8bit-Register dekrementierst,
>nicht aber bei 16bit-Registerpaaren) - könnte bei dem virtuellen Prozzi echt so sein) - >dann wird's ja doppelt Schräg.

genaus wegen solchen sachen bin ich ja der meinung, dass der JIT bzw. interpreter optimieren soll.. (weil der compiler ja keine ahnung hat auf welche CPU optimiert werden soll...)

13.11.2006, 10:01 Uhr - Editiert von adhoc, alte Version: hier

Doch... Denn die CPU ist ja klar - eine (virtuelle) JavaCPU.

Und loop-Unrolling... Hätte ich gerne als -O2 -Switch wie beim gcc...
Denn manuelles Loop-Unrolling im Source ist sicher falsch - denn dann wird's ja ziemlich unwartbar.

Sachen wie "/2" finde ich aber sträflich nachlässig... Anyways, mit deinem DEC statt CMP hast zumindest eine Erklärung gebracht, die man nachvollziehen kann,... Danke!

>Sachen wie "/2" finde ich aber sträflich nachlässig...

und wenn es (theoretisch) eine CPU gibt, bei der DIV 2 schneller ist als SHR...
??

Wenn dem so wäre, dürften sie das nicht als generellen Optimierungstipp verkaufen...

Warum ist es immer mit euch Leuten aus der C/C++ Welt, dass ihr manche Gegebenheiten nicht einfach als gegeben hinnehmen könnt und krampfhaft immer versuchen müsst, das, was ihr halt von eurer "alten" Umgebung kennt, auf Biegen und Brechen auch sonst überall unterzubringen?

Nun ja... Liebgewonnenes wie Compilerswitches möchte man natürlich woanders nicht missen... Insbesondere wenn es - wahrscheinlich - nicht schwer zu implementieren wäre.

... der großteil der Laufzeit in deinem eigenen schnell hingeschluderten Sch.eißcode verbraten wird

Das ist nun mal kein Java-Phänomen sondern gilt wohl generell...
Wobei Dich Designpatterns und "bekannte Algorithmen" darin unterstützen, sauberen Code zu schreiben... Insbesondere unter Java finde zB die Collections eine gute Idee, einem Coder ohne Aufwand verschiedene mächtige Storagegschichterln (Hashmap, Hashset, ..) zur Verfügung zu stellen, die sich -leider- einige C-Coder nicht antaten.

Warum fühlen sich eigentlich Javianer angegriffen, wenn man manche Konzepte von Java für nicht super findet ? Es gibt wohl keine perfekte Sprache, die alle denkbaren Vorteile in sich vereinigt (Algol, Haskell und Perl mal ausgenommen

).
Definitiv ist es eine Frage der Aufgabenstellung, definitiv ist Java eine eigene Welt, bei der sehr vieles anders gelöst wird als in der "guten Standard-EDV", wogegen mal per se nichts einzuwenden ist. Tatsächlich modifiziert sich aber Java - gottseidank - und ist nicht bei 1.0 stehengeblieben... Und das eben genau weil viele (wohl größtenteils Java-Entwickler, da sie sonst kein Gehör gefunden hätten) Gegebenheiten nicht einfach als gegeben hinnehmen konnten

.

Jedenfalls war mein Initialposting kein Angriff auf die Sprache - sondern ein (eventuell provokant gebrachtes) Auseinandersetzen von mir mit für mich unüblichen Vorgehensweisen in der JavaWelt. Tatsächlich half zB adhoc ja auch beim lösen des switch()-Statements... Seine Erklärung dürfte es wohl sein.

Dein Argument "Der Algo entscheidet" gilt natürlich grundsätzlich - aber auch wenn du einen sauberen, performanten Algo gefunden hast, gilt es - öfters - den Lowlevel zu optimieren.... Einerseits wegen KVM, andererseits schlicht wegen der Useranzahl bei Enterprise-Apps... Wenn eine Optimierung nur 1ms Geschwindigkeit pro Zugriff erspart - und 1000 User parallel zugreifen - fällt das ganz schnell wieder ins Gewicht ...

gleichzeitig bist du aber auch einer der ewigen gestrigen (nicht falsch verstehen) der nicht akzeptieren kann, dass nicht alles, was früher gut und unabdingbar war auch heute noch 1:1 gelten muss

Touche - Da triffst einen wunden Punkt... Früher dachte ich ähnlich über Saurier

Gleichzeitig war es aber so, daß mein Code/meine Projekte früher sicherlich schlechter waren als heute, sei es in Bezug auf Wartbarkeit, Erweiterbarkeit, ... Ich bin also echt überzeugt, daß meine Qualifikation durch die Jahre gestiegen ist (Garantie gibt's keine), merke aber auch selbst, daß ich mich auf den Saurierstatus hinentwickel

Tatsächlich - so meine Vermutung/Rechtfertigung vor mir selber - bleiben /in einigen Fällen/ genau dieselben Probleme bestehen... Beispiel:

Meine Fixe Überzeugung war früher, daß du keine Chance hast, guten Code zu schreiben, wenn du dich nicht durch Knuth's "Art of Computer Programming" durchgeackert hast... Insbesondere Teil 2 und 3 fand ich entscheidend und blätterte oft nach (ja, mein Hirn ist ein Sieb ,-) ).

Ich gebe gerne zu, daß das heute nicht mehr zwingend notwendig ist, daß das Verständnis seiner - obwohl uralten - Algorithmen heute noch eine sehr starke Unterstützung darstellt...

Wo ich hinwill:
Wirklich vieles wird obsolet - klar.
Keinesfalls wird aber alles obsolet.

Und... Es gibt ja sicherlich gute Gründe, warum man auf einiges verzichtet hat... Man muß die Meinung deswegen ja nicht teilen, aber es hilft i.d.R. immer fundamental, wenn man die Gedankengänge einiger Überlegungen nachvollziehen kann... Und genau darum geht's mir: echt.

Ist genauso wie im Job: Wenn du eine Shice-Hackn bekommst, deren Sinn du nicht verstehst (weil er Dir zB nicht mitgeteilt wird und es so mal krass idiotisch klingt), dann gehst ganz anders an die Sache ran, als wenn du dieselbe Hackn bekommst und Dir erklärt wird, warum das jetzt leider genau so gelöst werden muß.

Abschließend:
Natürlich hast du recht, daß Lowlevel-Optimieren immer der allerallerletzte Optimierungsschritt sein muß, und vorher wirklich massiv anderes passieren muß... Trotz allem gibt's manchmal den Bedarf, auch wirklich in die letzte Ebene runterzugehen... Und da wird man halt gerne unterstützt. Bei mir halt persönlich wegen Handy-Gschichtln...

13.11.2006, 16:54 Uhr - Editiert von Linux_Sucks, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung