amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Mono für Amiga [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 3 4 5 6 [ - Beitrag schreiben - ]

11.07.2004, 18:14 Uhr

amigine
Posts:
[Ex-Mitglied]
Hallo,

die Leute fragen hier, ob es sihc noch lohnt, irgendwelche alten Compiler zum laufen zu bringen und wollen damit teilweise Spiele programmieren oder Software, die kaum nohc jemand nutzen wird.

Warum nutzt ihr die Zeit nicht sinnvoll, indem ihr versucht, Mono auf dem Amiga zu portieren und somit eine Menge andere Software auf dem Amiga zum laufen bringen ?

Gruß,
A. G.

[ - Ändern - Antworten - Zitieren - Direktlink - ]

11.07.2004, 18:18 Uhr

Gary7
Posts: 571
Nutzer
mono ist doch nur die Umsetzung von .NET auf Linux. Warum sollte man sowas benutzen?
--
---
Der Weltraum, unendliche Weiten. Dies sind die Abenteuer...

[ - Antworten - Zitieren - Direktlink - ]

11.07.2004, 19:08 Uhr

chkamiga
Posts:
[Ex-Mitglied]
>die Leute fragen hier, ob es sihc noch lohnt,
>irgendwelche alten Compiler zum laufen zu bringen

Wieso zum laufen zu bringen?
MaxonBasic läuft, ASMPro läuft auch, ohne irgendwelche
Probleme.
--
http://people.freenet.de/CHRAmiga.de

CHRKUM(at)web(punkt)de

[ - Ändern - Antworten - Zitieren - Direktlink - ]

12.07.2004, 05:37 Uhr

Solar
Posts: 3680
Nutzer
Beide habt ihr amigine nicht verstanden.

Natürlich wäre es von Vorteil, eine .NET-Umgebung für den Amiga zu haben. Man hätte Zugriff auf eine Vielzahl zusätzlicher Software, und Entwicklern würde es einfacher gemacht, ihre Software auch für den Amiga anzubieten.

Das dumme ist nur, daß noch nicht einmal eine ordentliche Java-Umgebung für Amigas existiert - und der Aufwand für eine Java-Runtime liegt deutlich unterhalb von .NET, ebenso der "Streitwert", und trotzdem hat's bislang noch niemand zuwege gebracht.

"Warum nutzt ihr die Zeit nicht sinnvoll"... die Leute, die solche Projekte stemmen könnten und in der Vergangenheit auch gestemmt haben, nutzen ihre Zeit durchaus sinnvoll... allerdings inzwischen auf anderen Plattformen. Was übrig geblieben ist, sind Leute, die ASMPro und MaxonBasic mit .NET vergleichen...

::(:

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 06:46 Uhr

gunatm
Posts: 1431
Nutzer
Für solche Umsetzungen braucht man auch immer Leute, die dankbar ein solches Projekt zuende führen und monetär nix zu erwarten haben. Es tut sich doch momentan sehr viel bei den Softwareportierungen. Hinter Mono steht z.B. ein finazkräftiger Partner wie Novell. Man sollte die Ansprüche nicht zu hoch setzen. Ob überhaupt genügend Anwender für den klassischen Amiga vorhanden wären, ist fragwürdig. Vielleicht für AmigaOS4!
--
http://www.webwood.de - offizieller winuae mirror // A2000/060-User mit Hang zum A1200 ;-)

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 09:26 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von gunatm:

Ob überhaupt genügend Anwender für den klassischen Amiga vorhanden wären, ist fragwürdig. Vielleicht für AmigaOS4!


Und woher sollen die kommen? Anzahl OS4-Nutzer <= Anzahl OS3-Nutzer... Ach, vergiß es, den Streit hatten wir schon vor Jahren...

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 10:08 Uhr

amigine
Posts:
[Ex-Mitglied]
> und der Aufwand für eine Java-Runtime liegt deutlich unterhalb von
> .NET,

Sicher ? Java muß soweit ich weiß komplett neu geschrieben werden, weil der Quellcode nicht vorliegt. Mono ist OpenSource und müßte doch wohl anpassbar sein ? (Bis auf Windows.Forms jedenfalls.) Für den Apple haben sie es ja auch geschafft.



>Für solche Umsetzungen braucht man auch immer Leute, die dankbar ein >solches Projekt zuende führen und monetär nix zu erwarten haben.

Kostenlos währe natürlich schön, aber wenn mir jemand Mozilla, Mono und OpenOffice im Paket für Amiga anbieten würde, währe ich auch bereit dafür zu bezahlen. Denn erst dann ist ein AmigaOne brauchbar. Novell hat kein Interesse am Amiga...
Schön währe es ja, wenn diese Amigafirma die portieren würde und in Amiga OS 4 einbauen würde, aber die bekommen vor 2014 ja wohl noch nichtmal das OS selber fertig.


[ - Ändern - Antworten - Zitieren - Direktlink - ]

12.07.2004, 10:21 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von amigine:
> und der Aufwand für eine Java-Runtime liegt deutlich unterhalb von
> .NET,

Sicher ? Java muß soweit ich weiß komplett neu geschrieben werden, weil der Quellcode nicht vorliegt. Mono ist OpenSource und müßte doch wohl anpassbar sein ? (Bis auf Windows.Forms jedenfalls.) Für den Apple haben sie es ja auch geschafft.


Mono ist auf POSIX gemünzt... mit etwas Glück könnte man über die ixemul.library da einiges per "Abkürzung" implementieren.

Insgesamt halte ich Mono aber für komplexer als Java. Ich mag mich aber irren, denn wirklich "drin" bin ich in keinem von beiden.

Zitat:
Kostenlos währe natürlich schön, aber wenn mir jemand Mozilla, Mono und OpenOffice im Paket für Amiga anbieten würde, währe ich auch bereit dafür zu bezahlen.

Hmm...

Mannjahre * (21 Arbeitstage/Monat * 12 Monate/Jahr * 8 Stunden/Tag * 20 ¤ Entwickler-Stundenlohn) =>

Mannjahre * 40.320 ¤ Herstellungskosten, plus Entwicklungsumgebung, plus Infrastruktur, plus Management, plus Vertrieb, plus Investitionsverzinsung.

Verkaufte AmigaOne (potentieller Markt): Ein paar tausend, sehr optimistisch geschätzt. Ein Markt, dessen Überleben in die nächste Hardwaregeneration alles andere als gesichert ist...

Wirtschaftsmathematik ist da gnadenlos: Niemand wird hier investieren. Also "frei", oder gar nicht.

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 10:30 Uhr

chkamiga
Posts:
[Ex-Mitglied]
>Das dumme ist nur, daß noch nicht einmal eine ordentliche
>Java-Umgebung für Amigas existiert - und der Aufwand für
>eine Java-Runtime liegt deutlich unterhalb von .NET,
>ebenso der "Streitwert", und trotzdem hat's bislang
>noch niemand zuwege gebracht.

>"Warum nutzt ihr die Zeit nicht sinnvoll"... die Leute,
>die solche Projekte stemmen könnten und in der
>Vergangenheit auch gestemmt haben, nutzen ihre Zeit
>durchaus sinnvoll... allerdings inzwischen auf anderen
>Plattformen. Was übrig geblieben ist, sind Leute, die
>ASMPro und MaxonBasic mit .NET vergleichen...

ASMPro ist mind. 20 mal schneller als es Java auf
der selben Hardware je sein wird.

MaxonBasic immernoch mind. 5 Mal so schnell.

Weill a) ist es schwirig einen neuen Compiler zu
Programmieren und b) wenns jemand macht dann nicht
in Assemblern.

Wer Programmiert schon in Java?
--
http://people.freenet.de/CHRAmiga.de

CHRKUM(at)web(punkt)de

[ - Ändern - Antworten - Zitieren - Direktlink - ]

12.07.2004, 11:35 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von chkamiga:

ASMPro ist mind. 20 mal schneller als es Java auf
der selben Hardware je sein wird.

MaxonBasic immernoch mind. 5 Mal so schnell.


"Schneller" kann nicht nur die Lauf-, sondern auch die Entwicklungszeit sein.

Eine Assembler-Umgebung und einen proprietären BASIC-Dialekt mit einer Java-Runtime zu vergleichen, zeigt nur, daß Du (wieder einmal) von einer Sache keinen Schimmer hast.

Zitat:
Wer Programmiert schon in Java?

Zig-tausend mal mehr Leute als in ASMPro und MaxonBasic zusammen.

Aber Du trollst mal wieder nur, nicht wahr?

:X(: :nuke: :X(: :nuke: :X(:

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 11:39 Uhr

Buzzy
Posts: 102
Nutzer
Zitat:
Original von chkamiga:

ASMPro ist mind. 20 mal schneller als es Java auf
der selben Hardware je sein wird.

MaxonBasic immernoch mind. 5 Mal so schnell.

Weill a) ist es schwirig einen neuen Compiler zu
Programmieren und b) wenns jemand macht dann nicht
in Assemblern.

Wer Programmiert schon in Java?


Kannst du uns mal von deinen unqualifizierten Kommentaren verschonen? Wenn man keine Ahnung hat, einfach mal die Fresse halten.


[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 12:13 Uhr

Han_Omag
Posts: 1458
Nutzer
Zitat:
Original von Buzzy:
Kannst du uns mal von deinen unqualifizierten Kommentaren verschonen? Wenn man keine Ahnung hat, einfach mal die Fresse halten.


... und da liegt schon der Hase im Pfeffer: wenn man schon keine Ahnung hat, fehlt häufig auch die Einsicht, das man keine Ahnung hat. Die wenigsten, die sich mit dem Denken etwas schwer tun, wissen um ihr Problem...
Das war jetzt in keiner Weise abfällig gemeint.
--
Wir haben Augen, doch wir schauen nicht hin.
Wir haben Ohren, doch wir hören nicht zu.
Wir haben einen Mund. Damit reden wir ohne Unterlass
und doch sagen wir nichts.

Der Zeitreisende

[ Dieser Beitrag wurde von Han_Omag am 12.07.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 14:30 Uhr

chkamiga
Posts:
[Ex-Mitglied]
>Zig-tausend mal mehr Leute als in ASMPro und MaxonBasic
>zusammen.

Und wieviele Amiga-user Programmieren darunter?

1-2?

Also alles was man unter Java zustande bringt wird
grotten lahm also völlig nutzlos.
--
http://people.freenet.de/CHRAmiga.de

CHRKUM(at)web(punkt)de

[ - Ändern - Antworten - Zitieren - Direktlink - ]

12.07.2004, 15:21 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von chkamiga:

Und wieviele Amiga-user Programmieren darunter?


Und weil's auf Amiga keine Java-Runtime gibt, ist Java also Mist und viel unwichtiger als ASMPro oder MaxxonBasic?

Wie schön, dann brauchen wir ja auch keine Cascading Style Sheets, keinen XML-Parser, keine DVD-Authoring-Software und keine Office-Suite. Haben wir nicht, also brauchen wir's nicht.

Zitat:
Also alles was man unter Java zustande bringt wird
grotten lahm also völlig nutzlos.


Wieviel Java hast Du schon programmiert?

Ich habe eine Familie damit ernährt. Und Du wärst wahrscheinlich gleich über zwei Sachen erstaunt: Wie schnell Java sein kann, wenn man weiß, was man tut - und wie wenig es in 95% der Anwendungen eine Rolle spielt, wie schnell eine Anwendung läuft, wenn sie nur schnell (weiter-) zu entwickeln und gut zu benutzen ist und ihren Job erfüllt.

Ich arbeite seit über zwei Jahren an einer zentralen Bankanwendung - Datenbanken im zwei- bis dreistelligen Gigabyte-Bereich. Und für ca. 80% unseres Codes würde es keinen spürbaren Unterschied machen, wenn er in Java statt in C++ geschrieben wäre.

Dabei habe ich Dinge wie "nutzbarer Software-Pool", "Rapid Application Development", "Client / Server Architecture" und einige weitere noch gar nicht angesprochen.

Aber in Deiner kuscheligen Wahrnehmungsblase hast Du sicher auch daran etwas auszusetzen.

[ Dieser Beitrag wurde von Solar am 12.07.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 16:45 Uhr

Holger
Posts: 8116
Nutzer
Wer sich wirklich ernsthaft mit der Geschwindigkeitsthematik auseinandersetzen will, dem empfehle ich ich folgenden (englischsprachigen) Artikel.
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html


Interessanter als die Erkenntnis, dass Java durchaus schneller als C sein kann, finde ich den Hinweis, dass es oft problemlos möglich ist, einen Benchmark, der "A ist zweimal schneller als B" liefert, durch nur weniger Änderungen an den Randbedingungen zur Aussage "B ist zweimal schneller als A" zu bringen.
Aber da das Hauptproblem der Amigawelt nicht die Geschwindigkeit, sondern die Verfügbarkeit von Software darstellt, aber viele User sich trotzdem lieber daran ergötzen, wie schnell ein einzelnes Pixel auf ihrem System gemalt werden kann, und alles andere schlechtreden ....
Wahrscheinlich ist der Softwaremangel eher ein Segen für viele Amiga-User, denn reale Software könnte ja auch reale Mängel des heißgeliebten Systems aufdecken.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 12.07.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 19:14 Uhr

chkamiga
Posts:
[Ex-Mitglied]
>Wieviel Java hast Du schon programmiert?

Gar nix, ich bin ein Amiganer.


>Ich habe eine Familie damit ernährt. Und Du wärst
>wahrscheinlich gleich über zwei Sachen erstaunt: Wie
>schnell Java sein kann, wenn man weiß, was man tut
>- und wie wenig es in 95% der Anwendungen eine Rolle
>spielt, wie schnell eine Anwendung läuft, wenn sie nur
>schnell (weiter-) zu entwickeln und gut zu benutzen
>ist und ihren Job erfüllt.
usw.


Gut muss ich wieder weiter ausholen.
Nehmen wir an Java wird auf dem Amiga Portiert.
Da keiner mehr unter Assembler programmieren kann(oder will) und
eine Portierung eine Komplette neuschreibung gleich käme
wird es unter C gemacht. C ist schonmal deutlich
langsamer als ASM, auch nur eine Hochsprache.
Daher wird eine Hochsprache unter einer Hochsprache geschrieben.
Wahrscheinlich noch nicht mal gut.
Daher wird das Ergebniss schnarch lahm.

Würde es unter Assembler gemacht und dann noch Vernünftig ist
es sicher so schnell wie C, ist ja keine Frage.

Simples Java auf einem 400 MHZ PC ist schon lahm
und ziemlich Buggy. Siehe webchat.freenet.de


--
http://people.freenet.de/CHRAmiga.de

CHRKUM(at)web(punkt)de

[ - Ändern - Antworten - Zitieren - Direktlink - ]

12.07.2004, 20:33 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von chkamiga:
Da keiner mehr unter Assembler programmieren kann(oder will) und
eine Portierung eine Komplette neuschreibung gleich käme
wird es unter C gemacht. C ist schonmal deutlich
langsamer als ASM, auch nur eine Hochsprache.
Daher wird eine Hochsprache unter einer Hochsprache geschrieben.

Auch wenn es keinerlei Sinn hat, jemanden, der ohne jegliche Ahnung drauflosschwafelt, irgendetwas zu erklären, werde ich mal darauf antworten, vielleicht nützt es ja denen, die mitlesen und tatsächlich etwas verstehen wollen.
Das Ergebnis eines JIT-Compilers ist selbstverständlich Maschinencode, ganz egal in welcher Sprache der JIT-Compiler selbst geschrieben wurde. Der Anteil des JIT-Compilers an der gesamten Ausführungszeit beträgt ungefähr 2%, d.h. es ist vollkommen unwichtig, wie schnell er selbst arbeitet, einzig die Qualität des prodzierten Code´s ist von Interesse. Und das auch nur bei weniger als 10% des zu übersetzenden Code, in denen sich die Anwendung ca. 90% der Zeit aufhält. Bei diesen sog. Hot-Spots lohnt sich tatsächlich, den Code zu optimieren, während für den Rest des Codes ein einfacher Algorithmus ausreicht, manchmal reicht es auch, dort interpretiert zu arbeiten, weil die Übersetzung selbst mehr Zeit benötigen würde, als die Ausführung.
Abgesehen davon ist die Aussage "C ist schonmal deutlich langsamer als ASM" für sich allein genommen schon Blödsinn, aber das nur am Rande.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 12.07.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.07.2004, 21:29 Uhr

chkamiga
Posts:
[Ex-Mitglied]
>Das Ergebnis eines JIT-Compilers ist selbstverständlich
>Maschinencode, ganz egal in welcher Sprache der
>JIT-Compiler selbst geschrieben wurde. Der Anteil des
>JIT-Compilers an der gesamten Ausführungszeit beträgt#
>ungefähr 2%, d.h. es ist vollkommen unwichtig, wie schnell
>er selbst arbeitet, einzig die Qualität des prodzierten
>Code's ist von Interesse. Und das auch nur bei weniger als
>10% des zu übersetzenden Code, in denen sich die
>Anwendung ca. 90% der Zeit aufhält. Bei diesen sog.
>Hot-Spots lohnt sich tatsächlich, den Code zu optimieren,
>während für den Rest des Codes ein einfacher Algorithmus
>ausreicht, manchmal reicht es auch, dort interpretiert zu
>arbeiten, weil die Übersetzung selbst mehr Zeit benötigen
>würde, als die Ausführung.

Wie soll man einen JIT Programmieren wenn man keine
Ahnung von Assemblern hat?
Wie soll man den JIT beibringen ASM auszugeben wenn
man selbst kein ASM kann?
Das werden dann sicher C anweisungen die dann anstatt
aus einer Zeile aus 10 besteht!


>Abgesehen davon ist die Aussage "C ist schonmal deutlich
>langsamer als ASM" für sich allein genommen schon
>Blödsinn, aber das nur am Rande.

Beispiel, z.B. Proof.library
ist für anfänger gut nachzuvollziehen, wurde erst
in ASM geschrieben, dann in C.

Oder die Math librarys von OS3.9 gegen z.B. fmath
sind ein gutes beispiel dafür.
--
http://people.freenet.de/CHRAmiga.de

CHRKUM(at)web(punkt)de

[ - Ändern - Antworten - Zitieren - Direktlink - ]

12.07.2004, 22:11 Uhr

dante
Posts: 111
Nutzer
Welche für Normaluser sinnvolle Anwendungen gibts denn derzeit, die in .net oder Java daherkommen, und somit ohne grösseren Aufwand bei Vorhandensein einer entsprechenen vm/jit anwendbar sind?
Wie ich das hier mitbekommen hab, wünschen sich die meisten MorphOs/AOS4-User hier Sachen wie Gimp, Mozilla oder OpenOffice. Mozilla würde von einer JavaVM ja wenigstens noch in Form eines Plugins für einige Webseiten profitieren, aber ansonsten ist ein gcc für die Portierung dieser Monster nötig, kein "C Schaaaf". ;)

Zum Thema Java vs. C vs. ASM: je schneller die Rechner, desto mehr verschwimmen die Unterschiede. Ob man nun einen JIT oder einen "echten" Compiler benutzt, Benchmarks messen da eher das Können der Compiler-Programmierer und nicht die Güte einer Sprache. Dennoch find ich die Langsamkeit von Java teilweise immer noch erschreckend. Gerade bei GUI's, dem Bereich, wo die Geschwindigkeit einer Sprache eigentlich irrelevant sein sollte, suckt Java elendigst. Programme wie JBuilder oder Limewire sind glatte Anti-Java-Werbung...:lach:
Assembler ist heute zwar in einigen Bereichen immer noch unersetzbar, aber das sind eher exotischere Sachen - sei es VU-Code für PS2, Shader-Programmierung für neue Grafikkarten, oder kleine SSE-Hacks... Kein "normaler" Programmierer, also Anwendungs-, Datenbank-Entwickler u.ä., wird heutzutage Assembler benutzen oder auch nur vermissen.

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 09:24 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von chkamiga:

Wie soll man einen JIT Programmieren wenn man keine
Ahnung von Assemblern hat?


Von den vielen Megabyte, aus denen eine Java-Runtime besteht, profitiert nur ein winziger Teil davon, wenn der Entwickler "Ahnung von Assemblern" hat. Die Technologie, die in einem JIT-Compiler steckt, ist zu großen Teilen Plattformunabhängig. (Ähnlich wie die Optimierungsroutinen in einem C-Compiler.)

Wie das so ist - für das kleine bißchen, für das man echte "ASM-Kenne" braucht, holt man sich einen Spezialisten. Für den Rest braucht's keine Assembler-Kenntnisse.

Wobei ich wirklich nicht sehe, wieso das nun ein Kriterium für oder gegen Java sein soll - dieses Problem stellt sich bei jeder Anwendung mit zeitkritischen Teilen.

Zitat:
Das werden dann sicher C anweisungen die dann anstatt
aus einer Zeile aus 10 besteht!


Ach Mann, mach' doch mal den Kopf zu! Assembler mag ja schneller sein, wenn man weiß was man tut (was auf dem PPC schon mal deutlich schwieriger ist als auf einem 68k). Es ist aber definitiv nicht kürzer, im Sinne von Programmzeilen.

Die Zeit, in der ganze Anwendungen in ASM geschrieben wurden, sind vorbei, genauso wie die Zeiten der Classic Amiga-Hardware.

Zitat:
>Abgesehen davon ist die Aussage "C ist schonmal deutlich
>langsamer als ASM" für sich allein genommen schon
>Blödsinn, aber das nur am Rande.

Beispiel, z.B. Proof.library
ist für anfänger gut nachzuvollziehen, wurde erst
in ASM geschrieben, dann in C.

Oder die Math librarys von OS3.9 gegen z.B. fmath
sind ein gutes beispiel dafür.


Gutes C ist schneller als schlechtes ASM. Mit jeder Prozessorgeneration wird es schwerer, schlechtes ASM zu vermeiden. Mit jeder Prozessorgeneration wird ASM komplizierter. C bleibt gleich.

Und es ließen sich wahrscheinlich genausoviele Gegenbeispiele finden, wo eine in ASM geschriebene Anwendung tatsächlich langsamer läuft. Nur bin ich kein ASM-Frickelfritze, der jetzt Spaß daran hätte, diese auch herauszusuchen...

Zitat:
Original von dante:

Welche für Normaluser sinnvolle Anwendungen gibts denn derzeit, die in .net oder Java daherkommen, und somit ohne grösseren Aufwand bei Vorhandensein einer entsprechenen vm/jit anwendbar sind?


SourceForge führt über 12.000 Java-Projekte auf. (Vergleich: C - 13.000; C++ - 13.000; Assembler - 1400.)

Ich weiß nicht, was Du für "sinnvoll" hältst. Ich finde da P2P-, VNC-, E-Mail- und IRC-Clients, Chatserver, HTML- und Text-Editoren, Relationale Datenbanken, 3D-Modellierer, Entwicklungsumgebungen (nicht nur) für Java, GUIs für WGet oder DVD-Authoring, Entwicklungstools und -bibliotheken (z.B. XML, Unit-Testing, Refactoring, Libs für isometrische Grafik, ...), Dutzende Spiele (inkl. einer Quake2-Engine, einem BattleTech-Netzwerkspiel sowie diversen Rollenspielen), eBay-Sniper, SSH-Clients, ...


Dazu kommt eine Sache, die glaube ich von vielen arg unterschätzt wird.

Ein angehender Entwickler, der auf dem Amiga "groß" geworden ist, steht irgendwann einmal vor der Wahl, zwischen Hobby (Amiga) und Karriere Prioritäten setzen zu müssen. Mir war es schon Mitte der 90er zu unsicher, meine Zeit in das Aneignen der Amiga-API zu investieren; inzwischen kann man es als Profi bzw. Halbprofi kaum noch vor sich selbst vertreten, sich in diese Richtung einzubringen.

Java böte hier die Möglichkeit, Zukunftsinvestition und Unterstützung der Lieblingsplattform zusammenzubringen. In der Freizeit erworbenes Know-How ist für die Karriere nicht verloren, wie es bei ASMPro, MaxxonBasic, oder selbst Amiga-spezifischen C/C++ wäre.

[ Dieser Beitrag wurde von Solar am 13.07.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 09:50 Uhr

chkamiga
Posts:
[Ex-Mitglied]
>Assembler mag ja schneller sein, wenn man weiß was man
>tut (was auf dem PPC schon mal deutlich schwieriger ist
>als auf einem 68k). Es ist aber definitiv nicht kürzer,
>im Sinne von Programmzeilen.

Guck dir die math librarys von OS3.9 an und guck
dir fmath an, du solltest einen deutlichen unterschied in
der Größe feststellen.
Falls du Porgrammieren kannst, was ich nicht glaube,
schreib mal ein "Hello World" Programm unter C,
schick es mir, ich schick dir eins in ASM.
Du wirst einen größenunterschied feststellen.

>Die Zeit, in der ganze Anwendungen in ASM geschrieben
>wurden, sind vorbei, genauso wie die Zeiten der
>Classic Amiga-Hardware.

Es gibt immerhin noch mehr Amiga anwender als
AONE und PEG zusammen!
Also hör mit deinem getrolle auf.

>Gutes C ist schneller als schlechtes ASM. Mit jeder
>Prozessorgeneration wird es schwerer, schlechtes ASM zu
>vermeiden. Mit jeder Prozessorgeneration wird ASM
>komplizierter. C bleibt gleich.

So schlecht kann man ASM nicht Porggen damit es langsamer
wird als C.
--
http://people.freenet.de/CHRAmiga.de

CHRKUM(at)web(punkt)de

[ - Ändern - Antworten - Zitieren - Direktlink - ]

13.07.2004, 10:14 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von chkamiga:

Guck dir die math librarys von OS3.9 an und guck
dir fmath an, du solltest einen deutlichen unterschied in
der Größe feststellen.


Kleineres Executable bedeutet nicht weniger Zeilen (wie Du behauptet hast). Kleines Executable bedeutet auch nicht schnellere Ausführung.

Zitat:
Falls du Porgrammieren kannst, was ich nicht glaube...

:lach: :lach: :lach: :lach: :lach:

"Was kümmert es die deutsche Eiche, wenn sich die Sau an ihr reibt."

Zitat:
schreib mal ein "Hello World" Programm unter C,
schick es mir, ich schick dir eins in ASM.
Du wirst einen größenunterschied feststellen.


#include <iostream>
#include <ostream>
int main() { std::cout << "Hello World" << std::endl; return 0; }

So. Jetzt zeige mir mal bitte ein ASM-Pendant, das:

* weniger als 104 Zeichen hat;
* weniger als 3 Zeilen hat;
* Dich weniger als 30 Sekunden Arbeit gekostet hat;
* auf jeder beliebigen Plattform und mit jedem beliebigen Assembler funktioniert;
* die für die jeweilige Plattform korrekte Zeilenende-Kombination ausgibt.

Ich bezweifle nicht, daß Du eine ASM-Version schreiben kannst, die kleiner ist. Mit dem Rest wirst Du Schwierigkeiten bekommen.

Oh, verdammich, ich sollte ja C schreiben. Sonst heißt es noch, ich könnte kein C-"Hello World":

#include <stdio.h>
int main() { printf("Hello Worldn"); return 0; }

Hm. Gut, nicht mehr die richtige Zeilenende-Kombination, aber nur 68 Zeichen auf 2 Zeilen.

Oder, noch besser:

#!/usr/bin/perl
print "Hello Worldn";

Dieses "Programm" ist 39 Byte groß. Schaffst Du das kleiner?

Was ich hier zeigen will ist, daß weder Executable-Größe noch Executable-Geschwindigkeit die einzig seligmachenden Kriterien für die Güte einer Programmiersprache sind. Portierbarkeit, Verbreitung, Entwicklungsaufwand und noch viele andere Faktoren machen eine gute Sprache aus. Assembler rangiert bei vielen dieser Faktoren genausoweit hinten, wie es - in der Hand eines Könners - in Sachen Executable-Größe und Ausführungsgeschwindigkeit vorne liegen kann.

Steve Wozniak hat auch recht schnell aufgehört, AppleOS in Assembler zu schreiben... warum wohl, wenn's so toll wäre wie Du sagst? Bestimmt nicht, weil er ein schlechter ASM-Coder war...

Zitat:
>Die Zeit, in der ganze Anwendungen in ASM geschrieben
>wurden, sind vorbei, genauso wie die Zeiten der
>Classic Amiga-Hardware.

Es gibt immerhin noch mehr Amiga anwender als
AONE und PEG zusammen!
Also hör mit deinem getrolle auf.


Was Du als Getrolle bezeichnest, bezeichnen klügere Leute als Du als sachliche Feststellung.

Blöderweise haben sich Amiga-"Fanatiker" wie Du so tief eingegraben ("wir gegen den Rest der Welt"), daß ihr nicht einmal mehr das Sonnenlicht seht.

Oder, um es anders zu sagen: SourceForge hat mehr nicht-ASM-Projekte als der Amiga Anwender - Classic, AOne und Pegasos zusammengenommen.

Zitat:
>Gutes C ist schneller als schlechtes ASM. Mit jeder
>Prozessorgeneration wird es schwerer, schlechtes ASM zu
>vermeiden. Mit jeder Prozessorgeneration wird ASM
>komplizierter. C bleibt gleich.

So schlecht kann man ASM nicht Porggen damit es langsamer
wird als C.


Darauf würde ich Dich gerne festnageln. Welche ASM-Dialekte außer 68k kannst Du denn?


[ Dieser Beitrag wurde von Solar am 13.07.2004 editiert. ]

[ Dieser Beitrag wurde von Solar am 13.07.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 11:22 Uhr

kadi
Posts: 1528
Nutzer
Mir fällt grad auf, das immer mehr Leute für umsonst das Chkamiga-sitting übernehmen ... danke erstmal für die gute Arbeit. Aber sollte man dafür nicht Geld bekommen?

Das wär doch mal ein Anreiz. Wir profitieren in den anderen Threads schließlich ungemein davon, wenn jemand den Chk beschäftigt und von den anderen Threads ein Bischen ablenkt.

Ich weiß das ist ein Harter Job, vieleicht sollte man mal ein Konto einrichten in das jeder der einen Thread eröffnet etwas einzahlt. Von dem Geld werden die Chkamigasitter bezahlt.

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 11:25 Uhr

Solar
Posts: 3680
Nutzer
Solange er sich fachlich derart aus dem Fenster hängt und ich nur noch ein bißchen zupfen muß, daß er auf die Klappe fällt, mache ich das sogar ehrenhalber.

:lach:

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 11:56 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von chkamiga:
Wie soll man einen JIT Programmieren wenn man keine Ahnung von Assemblern hat?
Wie soll man den JIT beibringen ASM auszugeben wenn
man selbst kein ASM kann?

Verdammt noch mal, kennst Du überhaupt den Unterschied zwischen Maschinencode und Assembler. Ein JIT gibt keinen Assembler-Code aus, der dann nochmal übersetzt werden müßte. Assembler ist eine fast 1:1 Beschreibung des zu erstellenden Maschinencodes, die ein JIT-Programmierer überhaupt nicht kennen muß. Um effizienten Maschinencode zu erstellen muß ich jemanden mitarbeiten lassen, der die CPU genau kennt, aber oh Wunder, genau von der Sorte gibt es beim Hersteller der CPU genügend Leute, die nicht nur die Fähigkeiten, sondern auch das Interesse daran haben, daß die Anwendungen auf ihrer CPU möglichst schnell ausgeführt werden.
So konzentriert der CPU-Experte sich auf den JIT, während der Anwendungsprogrammierer sich auf die Anwendungen konzentriert, das nennt man Teamwork, oh je versuche ich gerade einem Amiga-Fanatiker das Konzept der Zusammenarbeit zu erklären :dance3: Das macht ja gar keinen Sinn.
Zitat:
Das werden dann sicher C anweisungen die dann anstatt
aus einer Zeile aus 10 besteht!

Völlig unqualifizierter Kommentar. Java-Bytecode ist bereits ein Maschinencode, nur eben für eine virtuelle CPU. Diesen in einen anderen Maschinencode zu übersetzen, hat überhaupt nichts mit "C-Anweisungen" oder Zeilenanzahl zu tun.
Zitat:
Beispiel, z.B. Proof.library
ist für anfänger gut nachzuvollziehen, wurde erst
in ASM geschrieben, dann in C.

Oder die Math librarys von OS3.9 gegen z.B. fmath
sind ein gutes beispiel dafür.

War ja klar. Wir reden von Anwendungsprogrammierung und Du kommst mit irgendwelchen low-level Bibliotheken, die zudem noch von keiner reale Anwendung benutzt werden. Wie ich schon sagte, Du gehörst genau zu dieser Sort Amiga-Fanatikern, die sich auf die Geschwindigkeit ihrer in Assembler geschriebenen math-library einen runterholen und noch nicht einmal bemerken, daß es keine Software gibt, die diese benutzt, abgesehen von ihrem Benchmark vielleicht.
Aber wozu brauchst Du überhaupt eine in Assembler geschrieben Bibliothek? Warst Du nicht ohnehin derjenige, dessen Amiga ohne zutun schneller als alle GHz-Rechner auf dieser Welt ist?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 12:20 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von dante:
Welche für Normaluser sinnvolle Anwendungen gibts denn derzeit, die in .net oder Java daherkommen, und somit ohne grösseren Aufwand bei Vorhandensein einer entsprechenen vm/jit anwendbar sind?
Wie ich das hier mitbekommen hab, wünschen sich die meisten MorphOs/AOS4-User hier Sachen wie Gimp, Mozilla oder OpenOffice.

Ich dachte, die meisten Anwender wünschen sich eine zeitgemäße Bildbearbeitung, einen zeitgemäße Browser und ein zeitgemäßes Office-Packet. Ich glaube nicht, daß es dabei wichtig ist, daß diese gimp, mozilla und open-office heißen.
Wobei, wir reden hier von Amiga-Usern....
Aber für die, denen Namen nicht wichtig sind, gibt es, wie Solar schon angeführt hat, 12000 Source-Forge Projekte und auch jede Menge kommerzieller Software. Abgesehen davon entsteht durch die Möglichkeit mitunter auch Motivation zur Entwicklung von Software, ich habe z.B. keinerlei Grund eine bestimmte Software in Java zu schreiben, wenn es auf allen Systemen, auf denen Java bislang läuft, solche Software schon gibt. Diese Software für den Amiga zu schreiben könnte mich als alten Amiga-User vielleicht zu einem Freizeit-Projekt motivieren, aber eben nicht mit C + AmigaOS3.x API.
Zitat:
Gerade bei GUI's, dem Bereich, wo die Geschwindigkeit einer Sprache eigentlich irrelevant sein sollte, suckt Java elendigst. Programme wie JBuilder oder Limewire sind glatte Anti-Java-Werbung...:lach:
Komisch, Du stellst selbst fest, daß die Geschwindigkeit bei GUI´s nicht von der Sprache abhängt, führst aber genau das hier an. Was sagen denn diese Beispiele aus? Das offenbar die Entwickler dieser Software keine Kompentenz in Sachen responsive UI haben, würde sich das Ändern, wenn sie in C oder C++ programmieren würden?
Definitiv nicht. Die Eclipse-Entwickler haben gleich von Anfang an die Schuld auf Java geschoben und ihr SWT programmiert und was kam dabei heraus? Eine grottenlahme native Oberfläche.
In einem Punkt hast Du recht, es ist glatte Anti-Java Werbung. IBM hat intensiv die Werbetrommel gerührt für ihre "schnelle native" Oberfläche und jetzt denkt jeder DAU, wenn "sogar diese native" Oberfläche so lahm ist, dann ist Java ja noch schlimmer als gedacht.
Liegt aber nicht an Java. Geschwindigkeitsoptimierungen sollte man erst bei fertiger Software unter Verwendung eines objektiven Profilers vornehmen. Wer wie bei Eclipse geschehen schon VOR der Entwicklung mit performance-motivierten Entscheidungen auf Grundlage von Bauchgefühl herangeht, kann nur katastrophale Ergebnisse liefern.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 12:25 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Solar:
#!/usr/bin/perl
print "Hello Worldn";

Dieses "Programm" ist 39 Byte groß. Schaffst Du das kleiner?

?"Hello World" ::D:
Zitat:
Zitat:
Original von chkamiga:
So schlecht kann man ASM nicht Porggen damit es langsamer
wird als C.

Darauf würde ich Dich gerne festnageln. Welche ASM-Dialekte außer 68k kannst Du denn?
außer 68k?
Du glaubst im Ernst, chkamiga könne programmieren? :lach:

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 13.07.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 12:55 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Solar:
Zitat:
chkamiga:
schreib mal ein "Hello World" Programm unter C

#include <iostream>
#include <ostream>
int main() { std::cout << "Hello World" << std::endl; return 0; }

Irre ich mich oder hatte er nicht C gefordert?

SCNR,
Gunther

Nachtrag: Die C Version hatte ich übersehen. *schaem*


[ Dieser Beitrag wurde von gni am 13.07.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 13:00 Uhr

gni
Posts: 1106
Nutzer
Zitat:
chkamiga:
Guck dir die math librarys von OS3.9 an und guck dir fmath an, du solltest einen deutlichen unterschied in der Größe feststellen.

fmath ist _nur_ für 040/060 mit FPU, OS3.9 für _alle_ Prozesoren mit oder ohne FPU.
Im übrigen darfst Du raten, welche Version korrekte Ergebnisse liefert ;->
Zitat:
So schlecht kann man ASM nicht Porggen damit es langsamer wird als C.
*ROTFL*

[ - Antworten - Zitieren - Direktlink - ]

13.07.2004, 14:58 Uhr

chkamiga
Posts:
[Ex-Mitglied]
>So. Jetzt zeige mir mal bitte ein ASM-Pendant, das:

Witzig, ich rede von einer ausfürbaren datei!
Weisst du was C da alles noch reinknallt.
Compilere es und schick es mir.


>* auf jeder beliebigen Plattform und mit jedem beliebigen
>Assembler funktioniert;

Wir reden immernoch von der Geschwindigkeit, nicht
von der leichten Portierbarkeit.

>Dieses "Programm" ist 39 Byte groß. Schaffst Du das
>kleiner?

Compilere es dann sinds keine 39 Byte mehr.

>...
>hinten, wie es - in der Hand eines Könners - in
>Sachen Executable-Größe und Ausführungsgeschwindigkeit
>vorne liegen kann.

Blub, Blub. Ein Amiga hat keinen 1 GHZ Prozessor sondern
max. einen mit 240 MHZ. Daher ist Assembler der
richtige weg.
Es ist irrelevant ob man das Portiren kann oder nicht,
es ist für den Amiga gedacht und nicht für den PC.


>Steve Wozniak hat auch recht schnell aufgehört,
>AppleOS in Assembler zu schreiben... warum wohl,
>wenn's so toll wäre wie Du sagst? Bestimmt nicht, weil
>er ein schlechter ASM-Coder war...

Faulheit?


>Darauf würde ich Dich gerne festnageln. Welche
>ASM-Dialekte außer 68k kannst Du denn?

Nur x86 ein bisschen und ein wenig PPC, nicht so
das ich groß drunter was machen könnte.
68k reicht aber für den Amiga völlig aus, es sei
denn für sehr kritische Anwendungen MPEG2 Encoden...



>Verdammt noch mal, kennst Du überhaupt den Unterschied
>zwischen Maschinencode und Assembler. Ein JIT gibt keinen
>Assembler-Code aus, der dann nochmal übersetzt werden
>müßte.

Warum solle er nochmal übersetzt werden?
Ja, wenn mans genau nimmt, denkst du jetzt
ASM-Soure. Für mich ist das ziemlich das gleiche
ob ich mir ASM Source angucke oder direkt den Maschinencode.
ASM-Source ist etwas übersichtlicher.


>Assembler ist eine fast 1:1 Beschreibung des zu
>erstellenden Maschinencodes, die ein JIT-Programmierer
>überhaupt nicht kennen muß. Um effizienten Maschinencode
>zu erstellen muß ich jemanden mitarbeiten lassen, der
>die CPU genau kennt, aber oh Wunder, genau von der Sorte
>gibt es beim Hersteller der CPU genügend Leute, die nicht
>nur die Fähigkeiten, sondern auch das Interesse daran
>haben, daß die Anwendungen auf ihrer CPU möglichst schnell
>ausgeführt werden.
>So konzentriert der CPU-Experte sich auf den JIT, während
>der Anwendungsprogrammierer sich auf die Anwendungen
>konzentriert, das nennt man Teamwork, oh je versuche
>ich gerade einem Amiga-Fanatiker das Konzept der
>Zusammenarbeit zu erklären :dance3: Das macht ja gar
>keinen Sinn.

Aha, das Problem ist nur ich glaub kaum das es davon
bei Motorolla davon gibt die den Amiga Programmier eine
JIT schreiben für 68k und 603e/604e, wobei es von den
68k den 68000, 010, 020, 030, 040 und den 060 gibt.
000 und 010 kannst du wie 020 und 030 zusammenschmeissen,
den Rest nicht. Also ein JIT für 6 Prozessoren.

Son mist da gibts ja dann auch 020 mit FPU und 030 mit
FPU. Also nochmal eine FPU Version.

> quote:
> Das werden dann sicher C anweisungen die dann anstatt
> aus einer Zeile aus 10 besteht!
>Völlig unqualifizierter Kommentar. Java-Bytecode
>ist bereits ein Maschinencode, nur eben für eine
>virtuelle CPU. Diesen in einen anderen Maschinencode
>zu übersetzen, hat überhaupt nichts mit "C-Anweisungen"
>oder Zeilenanzahl zu tun.

Ah, emulation, deshalb ist Java so grotten lahm sogar
auf einem 400 MHZ PC.

>War ja klar. Wir reden von Anwendungsprogrammierung
>und Du kommst mit irgendwelchen low-level Bibliotheken,
>die zudem noch von keiner reale Anwendung benutzt werden.

PhotoFolio z.B.

>Aber wozu brauchst Du überhaupt eine in Assembler
>geschrieben Bibliothek? Warst Du nicht ohnehin derjenige,
>dessen Amiga ohne zutun schneller als alle GHz-Rechner
>auf dieser Welt ist?

Ja, im allgemeinen Arbeiten. Und was glaubst du warum
der Amiga so schnell ist?
--
http://people.freenet.de/CHRAmiga.de

CHRKUM(at)web(punkt)de

[ - Ändern - Antworten - Zitieren - Direktlink - ]


-1- 2 3 4 5 6 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Mono für Amiga [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.