was muss ein Progammierer können?

Mr. N

@Gregor: MSVC hat sich aufs sinnlose Schliefen wegoptimieren spezialisiert *g*. Das erschwert allerdings das Benchmarking :D.

Gregor

BTW : Mit g++ ist die zweite Variante ohne Optimierung vom Compiler übrigens schneller, als mit Optimierung vom Compiler!

Blue-Tiger

Original erstellt von Mr. N:
Schau dir die Schleife genau an. Und dann überleg dir beim java-code wie im Prozessor der L1-Cache aussieht und beim C++-Code, wie hier Register genutzt werden können.

mal 'ne Frage:
was macht "memset(a, 0, sizeof(a));" (zu meiner Entschudligung: ich bin noch dabei, C++ zu lernen ).

BTW: mit dem BCC55 erhalt ich folgende Zahlen/Zeiten:
Zahl: 20000
Zeit: 29906
Zahl: 20000
Zeit: 8532

Mr. N

@Blue-Tiger: die Zahlen sind gut. Du hast gefragt, was das memset macht? Naja, is ja auch eher ne C Funktion... memset(a, 0, sizeof(a)); füllt sizeof(a) bytes ab a mit dem wert 0. sehr praktisch.

Marc++us

Mit Eurem Benchmark zeigt Ihr ein meiner Meinung nach typisches Technikerverhalten, das sehr schön die Defizite vieler Programmierer aufzeigt - Ihr vergleicht gerade Laufzeiten für die Programme, um herauszufinden was schneller ist. Sehr schön.

Hier aber mal eine nette Geschichte zum nachdenken - und ich erzähle diese nun aus meiner Sicht als Softwareanwender:

Ich habe einen Scanner Epson Perfection 1200 USB mit Einzelblatteinzug.

Ein Topgerät, sehr gute optische Qualität, sehr sehr stabile Twaintreiber, noch nie einen Absturz gesehen. Aber ein Manko: wenn ich einen Stapel Papier einlege, so wird für jede Seite beim Scannen ein Fortschrittsbalken in einem Fenster angezeigt - ALS TOPMOST WINDOW! D.h. ca. alle 30 Sekunden klappt ein Fenster in den Vordergrund und zeigt mir den Scanfortschritt. Damit - so ein Scanvorgang kann ja bei 50 Blättern einige Minuten dauern - kann man den Computer während des Scannens für keine andere Aufgabe nutzen, obwohl es von der Performance her überhaupt kein Problem wäre.

Ergo: die Software ist aus Anwendersicht trotz qualitativ hochwertiger Ausführung SCHEISSE. Weil der Entwickler nicht nachgedacht hat - weil er sich nicht in die Rolle des Anwenders gedacht hat.

Kommen wir auf die Grundfrage zurück "was muss ein Progammierer können?" - so sollte hier eine Antwort lauten:

"Ein Programmierer sollte verstehen, was die Anwender mit dem Produkt tun wollen"

Stabilität von Software ist sicherlich eine Grundvoraussetzung, damit man mit ihr brauchbar arbeiten kann, ohne Frage. Also muß ein Programmierer seine Werkzeuge (aka seine Sprache) sauber beherrschen.

Es reicht aber nicht aus, sich auf eine Beherrschung der Sprache und Performancekniffe zu beschränken - weil dann gibt's zwar technisch hochwertige Software, die aber leider trotzdem unbrauchbar ist.

Prof84

Hi!

Original erstellt von Marc++us:
**[...]
Kommen wir auf die Grundfrage zurück "was muss ein Progammierer können?" - so sollte hier eine Antwort lauten:

"Ein Programmierer sollte verstehen, was die Anwender mit dem Produkt tun wollen"

Stabilität von Software ist sicherlich eine Grundvoraussetzung, damit man mit ihr brauchbar arbeiten kann, ohne Frage. Also muß ein Programmierer seine Werkzeuge (aka seine Sprache) sauber beherrschen.

Es reicht aber nicht aus, sich auf eine Beherrschung der Sprache und Performancekniffe zu beschränken - weil dann gibt's zwar technisch hochwertige Software, die aber leider trotzdem unbrauchbar ist.

;)**

Hmm, ...
Kann ich nicht unbedingt unterschreiben.

Unternehmen, die groß genug sind, haben ein hinreichend ausgeprägtes Anforderungsmanagement, so dass nicht jeder Programmierer über den vollständigen System-, Nutzungs- und Funktionsumfang informiert werden muss, was ja auch Kosten verursacht.
'XP' ist nicht immer der Nabel der Weisheit

cu

P84

Gregor

Original erstellt von Prof84:
**
'XP' ist nicht immer der Nabel der Weisheit
**

Ich sehe den Zusammenhang zu XP hier garnicht! ...bitte erklär ihn mal!

Prof84

@Gregor: Insider-Joke!!

MagiC Creator

So wie bei **Voraus (V_o_r_r_a_u_s), was?

cya :)**

Marc++us

Original erstellt von Prof84:
Unternehmen, die groß genug sind, haben ein hinreichend ausgeprägtes Anforderungsmanagement, so dass nicht jeder Programmierer über den vollständigen System-, Nutzungs- und Funktionsumfang informiert werden muss, was ja auch Kosten verursacht.

Naja, mit der Taktik der vollständigen Information wurden aber schon Schlachten gewonnen.

Blue-Tiger

humm..... nächste Frage zu dem Code... was bitte macht: x &= a[i]++; d.h. speziell der &= Operator? Bitweises Und, oder?

BTW: wieso ist die 2. Variante jetzt eigentlich schnelller? *dummVorkomm*

ein programmierer muss auch gut *****kriechen können

Mr. N

@Blue-Tiger: Was x &= ++a[i]; macht? Das ist das gleiche wie x = x & ++a[i]; da x aber von vorneherein 0 ist, optimiert der das nicht weg und ich kriege bei Variante 2 nicht 0 ms. Den Unterschied zwischen den zwei Varianten zeig ich mal an Pseudo-Assembler:

Variante 1:

SET B, 0
SET D, 20000
L1:
SET C, 1500000
L2:
SET A, a[C]
INCREMENT A
AND B, A
SET a[C], A
DECREMENT C
IF C IS NOT 0 JUMP TO L2
DECREMENT D
IF D IS NOT 0 JUMP TO L1

Variante 2:

SET B, 0
SET D, 150000
L1:
SET C, 20000
SET A, a[D]
L2:
INCREMENT A
AND B, A
DECREMENT C
IF C IS NOT 0 JUMP TO L2
SET a[D], A
DECREMENT D
IF D IS NOT 0 JUMP TO L1

sehr teuer ist.

Gregor

Original erstellt von Blue-Tiger:
**
BTW: wieso ist die 2. Variante jetzt eigentlich schnelller? *dummVorkomm***

Hmmm... ich habe jetzt mal die drei Applets von Seite 2 ausprobiert.
Ergebnis :

kleinstes Array : Variante 2 braucht 96% der Zeit von Variante 1.
mittleres Array : Variante 2 braucht 85% der Zeit von Variante 1.
größtes Array : Variante 2 braucht 78% der Zeit von Variante 1.

...scheint ja irgendwie größenabhängig zu sein, oder?! ...und jetzt verrate ich dir noch, dass der Unterschied beim kleinsten Array garnicht an der Größe liegt, sondern durch irgendwas, was von Java verursacht wird. Nehmen wir einfach mal an, dass beim kleinsten Array beide Varianten die gleiche Zeit brauchen.

...jetzt gucken wir uns mal die Größen der Arrays etwas genauer an (ein int umfaßt 4 Byte):
kleinstes Array : 15000 * 4 = 60000 Byte = 58,6 kB.
mittleres Array : 150000 * 4 = 600000 Byte = 585,9 kB.
größtes Array : 1500000 * 4 = 6000000 Byte = 5,7 MB.

...und jetzt verrate ich dir noch, dass ich nen Pentium 4M mit 512 kB Cache habe.

...und jetzt darfst du raten. (Bei der C++-Variante ist es noch etwas anders. Die ist eher mit der 3. Java-Variante vergleichbar.)

Mr. N

@Gregor: Die 2. C++ Variante ist vom Code her mit der 2. Java Variante vergleichbar, von der Performance her jedoch eher mit der 3. Java Variante - soviel Zeit muss sein *g*.

Gregor

Original erstellt von Mr. N:
@Gregor: Die 2. C++ Variante ist vom Code her mit der 2. Java Variante vergleichbar, von der Performance her jedoch eher mit der 3. Java Variante - soviel Zeit muss sein *g*.

Nicht, wenn man bedenkt, was der Compiler daraus macht. Sagen wir : Die 2. Assembler-Variante, die du gezeigt hast ist eher mit der 3. Java-Variante, als mit der 2. Java-Variante vergleichbar.

Mr. N

@Gregor: Mach ich das mit Ohne Optimierung, dann müsste ich auch etwa die Java Zeiten kriegen. Bis auf Variante 3, die Java da optimiert.

Gregor

Ich glaube, bei Variante 3 würdest du mit C++ ohne Optimierung auch etwa auf die Java-Zeit kommen! ...hast du es schon ausprobiert?

EDIT : Anscheinend muss man ja als Java-Programmierer mehr von der Hardware wissen, als wenn man ein C++-Programmierer ist, da bei C++ die ganzen Optimierungen in diese Richtung vom Compiler gemacht werden!

[ Dieser Beitrag wurde am 05.01.2003 um 22:24 Uhr von Gregor editiert. ]

Prof84

Original erstellt von Marc++us:
Naja, mit der Taktik der vollständigen Information wurden aber schon Schlachten gewonnen.

Hängt von der Größe der Schlachten ab. Sonst kommt aus dem Abhalten von Briefings, dem Lesen und Schreiben von Mails und Memos nicht mehr raus...

Haste ´n Team oder ´n Heer?

Mr. N

@Gregor: Das glaube ich zwar nicht. Aber testen kann ja nicht schaden.