Programmiersprachen/Umgebungen

[carli]

Ganz so euphorisch würde ich da nicht sein, denn JavaScript und vor allem jQuery ist von seinem Sprachdesign so aufgebaut, dass es fast alle Informationen, die man zur Optimierung gebrauchen könnte, wegschmeißt. Da muss man extrem viele und gute Optimierungspattern haben, die z.B. den jQuery-Code inlinen und das Parsing schon mal constant folden.

[m.fuchs]

In der Zwischenzeit wird man die Web-Technologien so weit optimieren, dass kaum noch ein Unterschied in der Performance besteht und niemand mehr zurück will, weil man sich die Rechenzeit einfach leisten kann.

Das ist es eben ja auch, da wird nicht die Webtechnologie optimiert sondern die Hardware schneller gemacht. Und ja man kann sich die Rechenzeit leisten, aber muss man es immer? Kann man nicht auch einfach effizientere Software schreiben? Damit möchte ich jetzt nicht die Abkehr von der Objektorientierung und stattdessen Assembler propagieren, der Overhead ist durch sauberer Programmiermöglichkeiten gerechtfertigt. Aber es wird an viel Stellen einfach nicht nachgedacht und alle Probleme mit Hardware erschlagen.

Schönes Beispiel: Vor einigen Wochen hab ich eine Beratung bei einem PHP-Projekt gemacht. Die Seitenladezeiten von fünf Sekunden waren eindeutig zu lang. Vorschlag der Erbauer war: wir bauen einen Cluster auf und verteilen die Last irgendwie, dann wird es bestimmt schneller. Code optimieren? Dafür haben wir keine Zeit, sowas dauert doch Wochen.

Ich hab mir einen Profiler geschnappt und zwei Stellen gefunden, die man leicht optimieren konnte (einmal ein Caching aktivieren und einmal dafür sorgen, dass eine Funktion nicht 500mal hintereinander aufgerufen wurde). Plötzlich waren die Ladezeiten bei einer Sekunde. Arbeitsaufwand: unter einer Stunde.

Aber auf die Idee kommen immer weniger Menschen. Und schwupps haben wir überall hochgezüchtete, ernergiefressende Hardware die oftmals gar nicht nötig wäre.

Micha

[mschnell]

Tja, an menschliche Intelligenz glaubt keiner mehr . Ist ja auch kein Wunder, wenn man sieht was bei der Facebook und Twitter-Gemeinde los ist .

-Michael

[carli]

Das ist es eben ja auch, da wird nicht die Webtechnologie optimiert sondern die Hardware schneller gemacht. Und ja man kann sich die Rechenzeit leisten, aber muss man es immer? Kann man nicht auch einfach effizientere Software schreiben?

Ich finde die Entwicklung so wie sie jetzt ist ok. Schau mal, für einige Anwendungen gibt es die Rechenzeit _wirklich_ nicht, zum Beispiel Simulationen. Aber niemand würde sich für die paar Supercomputer nen Arsch aufreißen und die Computer verbessern. Wenn jedoch Millionen User nach schnellerer Hardware schreien, ist das was komplett anderes.

Analogie: Damals haben die Computerspiele die schnellere Leistung eingefordert und die HPC-Leute konnten sich dann auch nur den "Abfall" kaufen. (im Sinne von "was davon abfällt")

[knight]

Was nützt die schnellste Hardware, wenn die Software nicht mitspielt. Hier mal ein schöner Vergleich zwischen C++ und Java: http://winfuture.de/news,63737.html" onclick="window.open(this.href);return false;

knight

[Christian]

Das Argument die Hardware wird schneller ist schwachfug. Schon der Apple II konnte 80% von dem was einen heutigen Desktoprechner ausmacht mit nem tausenstel der heutigen Rechnleistung. Ich hab mir eigentlich extra n schnelles Notebook geholt weil ich mir dachte das ich mit der 20 fachen Leistung von meinem Netbook eigentlich problemlos Virtual Mashines benutzen können sollte um tests und Co auf verschiedenen Betriebsystemen abzudecken. Pustekuchen ein Compilevorgang dauert trots SSD und schneller Hardware 5 min auf nem Linux auf der blanken Hardware insts in 5 sek erledigt.
Und schnellere Hardware braucht immer im selben Maße Strom. Und den haben wir dank Fukushima nicht mehr im Überfluss.

Also sollten wir verdammt nochmal losziehn und der Welt zeigen was man mit nativem Code aus den Kisten herausholen kann was Java, .net und co in 100 Jahren nicht leisten werden.

[mschnell]

Und schnellere Hardware braucht immer im selben Maße Strom.

Das stimmt so nicht. Durch kleinere Strukturbreiten wird der Stromverbrauch gesenkt. Und die Rechen-Leistung eines Chips ist stark vom Energie-Umsatz abhängig, weil die Wärme ja auch abgeführt werden muss. Eigentlich steigt die Rechenleistung eines CPUs Chips deshalb analog dem Mooreschen Gesetzes ( http://de.wikipedia.org/wiki/Mooresches_Gesetz" onclick="window.open(this.href);return false; ) bei gleichbleibendem Stromverbrauch.

Ansonsten stimme ich Dir natürlich zu 100 % zu.
-Michael

[carli]

Um noch mal einen Kommentar loszuwerden:
Rechenzeiteffizienz ist nicht in allen Anwendungen das wichtigste, da im Business-Bereich z.B. der Flaschenhals eher in der Netzwerkbandbreite liegt. Außerdem kommt dazu, dass unsere Rechner nicht schneller, sondern einfach mehr werden. Java hat sich da prima etabliert, weil man einfach als Geschäftsmann sich schnellere und (und vor allem) mehr Rechner kauft, die per J2EE zusammensteckt und schon schafft der das Rechenvolumen wieder. Es geht nicht mehr darum, ob, sondern wie überhaupt die Aufgabe (z.B. Transaktionen) zu berechnen sind.
Heutzutage im Großeinsatz bringt dir keine noch so hoch optimierte Software was, wenn sie nur einen einzigen Kern auslastet.

[Christian]

Kannst du das bitte konkrerisieren ? Im Business Bereich gibt es nach meinen Erfahrungen gar keinen Flaschenhals da die meissten Berechnunge dort lächerlich sind. Und bei vernünftig geschriebenen SQL Abfragen oder SPś gibts dort auch Netzwerktechnisch wenig fläschenhälse. Allerdings ist Business Bereich etwas sehr unspezifisch, deswegen findet man da natürlich trotsdem Beispiele für alle möglichen flaschenhälse.

Ich hab auch nie etwas davon gesagt das man Mit nativen Sprachen nur einen Kern auslasten könnte, bei einer Web Anwendung (was für mich noch das grösste Beispiel für den Einsatz von Java ist) skaliert nativer Code genausogut wie jede Scriptsprache und verbraucht trotsdem wesentlich weniger rechenleitung / Strom. (Und ja mschnell durch verkleinerung der Strukturbreite wird strom gespart diese verkleinerungen gibts aber nur alle 10 Jahre und auch nicht bis ins unendliche dagegen verdoppelt sich die rechenleistung / stromverbrauch alle 2 Jahre...)

[carli]

Kannst du das bitte konkrerisieren ? Im Business Bereich gibt es nach meinen Erfahrungen gar keinen Flaschenhals da die meissten Berechnunge dort lächerlich sind.

Korrekt. Aber wenn's auf Masse kommt, ists trotzdem viel. (darauf wollt ich hinaus)

[Christian]

Ja aber da ist interpretierter Code trotsdem nicht resoucenschonender. Uch kenn mich mit Java aber nur ein wenig aus mag sein das das um längen besser paralellisierbar ist, ohne das man was dazutun muss (kann ich mir aber schwer vorstelln).

[carli]

Java ist auch nicht ressourcenschonender, aber dadurch, dass man den Aufbau aller Klassen zur Laufzeit kennt, kann man Remove Calls machen, also ein Funktionsaufruf einer Methode eines Objekts, wobei das Objekt im RAM einer anderen Maschine steckt. Ist ein irrer Overhead, aber wenn die Aufgabe sich gut parallelisieren lässt, braucht man nur wenige Remote Calls und dadurch verteilt sich das Programm auf mehrere Rechner, was bei großen Transaktionssystemen von Vorteil ist. Und wir bekommen keine schnelleren Rechner mehr, sondern nur mehr Rechner. Und dadurch theoretisch unbegrenzte Performande, wenn man's ordentlich parallelisiert.

[Christian]

1. RPC ist nichts Java spezifisches.
2. Sie erzeugen so viel Overhead das sie nur etwas bringen wenn die Grundaufgabe sehr viel Rechenleistung erfordert.
Aber ich weiss zumindest wo du hinwillst.

[Teekeks]

Kannst du das bitte konkrerisieren ? Im Business Bereich gibt es nach meinen Erfahrungen gar keinen Flaschenhals da die meissten Berechnunge dort lächerlich sind. Und bei vernünftig geschriebenen SQL Abfragen oder SPś gibts dort auch Netzwerktechnisch wenig fläschenhälse.

Ich habe ein Beispiel für dich:
Es soll für eine Ernährungsberatungs-Software eine Übersicht mit allen (Koch-)Rezepten und den entsprechenden Texten angezeigt werden.
Ein Rezept hat etwa eine Seite text.
Alle Daten sind auf einer Firebird-Datenbank auf einem Server gespeichert.
Bei nur 100 Rezepten wird die Zeit die die SQL-Abfrage benötigt um alle Daten durch das Netz zu schicken schon sehr ekelig.
Jetzt wird bei diesem Beispiel es anders gelöst, aber das ist nur notwendig weil das Netzwerk(=LAN) nicht genug Leistung bringt.

Aber allgemein wirst du recht haben.

[m.fuchs]

Alle Daten sind auf einer Firebird-Datenbank auf einem Server gespeichert.
Bei nur 100 Rezepten wird die Zeit die die SQL-Abfrage benötigt um alle Daten durch das Netz zu schicken schon sehr ekelig.

Dann ist doch eher designmäßig was falsch. Werden da einmal alle Rezepte gezogen und dann dann angezeigt? Warum nicht nur alle Titel ziehen und bei Bedarf (Auswahl durch den Benutzer) das komplette Rezept? Dann aber nur dieses eine.

Das scheint mir eher ein Beispiel für nicht-vernünftige SQL-Abfrage, die Christian ja explizit ausgeschlossen hat aus der Betrachtung.

mf