Hallo
Könnte sicher einige von euch interessieren.
http://www.wpcentral.com/native-code...one-developers
Edit:
http://wmpoweruser.com/microsoft-rev...oper-requests/
Gruss
Cr3dos
Druckbare Version
Hallo
Könnte sicher einige von euch interessieren.
http://www.wpcentral.com/native-code...one-developers
Edit:
http://wmpoweruser.com/microsoft-rev...oper-requests/
Gruss
Cr3dos
Ich frage mich warum die solange zoegern. Es ist unbestritten, dass eine Platform welche sich im Marktumfeld behaupten will, native C/C++ Code erlauben muss. Sowas haette im Prinzip schon von Anfang an vorhanden gewesen sein muessen. Hinzukommt, dass die meisten Echtzeitanwendungen, vorrangig Spiele, keine besonders umfangreiche API Unterstuetzung benoetigen. Auch unter Android ist die verfuegbarkeit von APIs unter dem NDK sehr eingeschraenkt aber ausreichend.
nativer Code ermöglicht exploits. that's why.
Och das mit den Exploits ist ne billige Ausrede, zumindest was Marketplace Apps betrifft. MS koennt zB. vor der Freigabe checken gegen welche DLLs die App gelinkt ist. Wenn unzulaessige DLLs mit im Spiel sind, wirds nicht freigegeben.
Ferner gibt es kein Mobiles OS auf dem Markt ausser WP7, bei welchem native Development nicht moeglich ist. Man sollte auch bedenken, dass ohne native Code einige Apps schlechter sind als auf konkurrierenden Platformen und mehr Strom ziehen. Auch ist es unmoeglich die Neon oder Floatingpoint Erweiterungen von ARM v7 zu nutzen. Zeitkritischer Code bleibt auf WP7 somit immer ein langsames Entlein.
Für Sicherheit kann ich gut damit leben! Was hat es für einen Geschwindigkeitsvorteil wenn ich dann wieder einen Virenscanner brauche, der mein System dann wieder in den Keller zieht!??
Mit der kostenlosen PocketPC.ch App von meinem LG-E900 aus geschrieben.
Nativer Code ist verwaltungsaufwenig !
Das ist der Hauptgrund. Durch den hohen aufwand und durch die vielen Fehler die eben passieren können (und auch ganz klar passieren) steigt die Gefahr für die gesamte Konsistenz des Betriebssystems.
Wieso hat Apple wohl alles 3x in ner Sandbox? Ganz sicher nicht wegen den achso-wichtigen Nutzerdaten.
Sondern weil ein Fehler innerhalb des Codes nicht alles abschmieren lassen soll!
// und wegen den Daten *gg* xD
Bevor hier Missverstaendnisse aufkommen. Auch native Code kann man Sandboxen, wie das Beispiel Apple zeigt. Es geht nicht darum, dass man alles auf System Ebene machen darf, sondern vielmehr, dass man C/C++ Code native compiliert ausfuehren kann.Zitat:
Wieso hat Apple wohl alles 3x in ner Sandbox? Ganz sicher nicht wegen den achso-wichtigen Nutzerdaten.
Sondern weil ein Fehler innerhalb des Codes nicht alles abschmieren lassen soll!
Verwaltungsauswendig ist, wenn ich 2 verschiedene Codebasen C# und C++ verwalten muss, wovon erstere eine Performance zeigt wie vor 5 jaren auf nem 200Mhz Arm Prozessor.Zitat:
Nativer Code ist verwaltungsaufwenig !
Performance? http://www.codeproject.com/KB/cs/CSharpVsCPP.aspx
Aus deinem Link:
Noch verblueffender ist der konstruierte Fall aus deinem verlinkten Artikel, in welchem ein C++ programm dann langsamer ist, wenn es Page Faults erzeugt. Davon abgesehen, bin ich mir recht sicher, dass mit WinCE garkeine Page Faults möglich sind.*Zitat:
Nearly all the threads I've seen that claims C++ is faster writes a small application like this a prove that C++ is atleast n times faster than an equivalent c++ program and yes it's true. Microsoft does not recommend using C# for time-critical applications.
*zumindest in Windows Mobile war Page File support nicht aktiviert.
Dazu fällt mir follgendes ein:
Ob ich jetzt 29 oder 30fps habe macht reichlich wenig aus. Aber so klein werden die Unterschiede nur sein. Außerdem wird ein so optimierter C++ Code wohl ziemlich Verwaltungsaufwendig(bei der Entwicklung), dass es sich nicht lohnen würde. Da man das dann auch noch in eine Sandbox packen muss denke ich nicht, dass es dann überhaupt noch schneller ist. Dann eröffnet man sich noch die Möglichkeit der Memoryleaks, welche es (normalerweise) in Managed Code nicht gibt. Dann gibts noch Bufferoverflows, über den Schadcode reinkommen könnte usw. Das ganze bringt mMn mehr nachteile als VorteileZitat:
premature optimization is the root of all evil
Ich habe genau einmal einen wirklich sinnvollen Vergleichstest gesehen und der ist in der c't vor etlichen Jahren gewesen.
Wenn ich jetzt z.B. ein Math.random mache in C# und C++ ist das in C++ viel schneller, da ein einfacherer Algorithmus genutzt wird, der aber auch deutlich "schlechtere" Zufallszahlen liefert. Solche Unterschiede in den Bibliotheken muss man z.B. bei Vergleichen berücksichtigen => wirklich denselben Algorithmus testen. Im Ergebnis war C# dann schneller, wenn es stark objektorientierten Code zu verarbeiten galt - C++ ist hier durch die Komplexität der Mehrfachvererbung (die es unter C# nicht gibt) im Nachteil. Ansonsten machte der Performance-Vorsprung von C++ im Schnitt 10% aus.
Ansonsten sind Managed Sprachen aufgrund der Garbage Collection für Realtime-Anwendungen ungeeignet - da man im Vorhinein nicht sagen kann wann genau der Garbage-Collector die Ausführung anhalten wird (auch wenn sich hier auch die letzten 2 Jahre noch einiges getan hat im Hinblick darauf was der GC parallel machen kann - hie und da muss man halt die Ausführung dafür doch unterbrechen).
Will ich also dauerhaft eine geringe Latenz garantieren, dann brauche ich Native Code.
Ein anderer Punkt, der beim Start Performance kostet ist eben die JIT-Kompilierung, die vor allem beim Start von Anwendungen auffällt. Allerdings könnte Microsoft hier bei Installation am Gerät mittels NGen die DLLs vorkompilieren, sodass das komplett wegfällt - wäre interessant zu wissen ob das passiert oder nicht.
Diverse ARM-Erweiterungen wie Neon werden teilweise durchaus vom JIT-Compiler genutzt - z.B. bei Matrixmultiplikationen in XNA. Das muss man allerdings über ein Flag in der Assembly auch aktivieren.
Speicherlöcher - d.h. immer weiter steigender Speicherbedarf - kann man auch mit Managed Code produzieren, auch wenn es dort darauf hinausläuft, dass man unbeabsichtigt Referenzen auf nicht mehr benötigte Objekte hält (Eventhandler sind da ein Klassiker) statt, dass man vergisst ein Free für den Speicherbereich aufzurufen.
Es gibt ja auch jetzt schon ein paar Anwendungen für WP7 die Native-Code-Anteile benutzen, z.B. Navigon und auch Tango. Im Ergebnis habe ich mit Navigon auf dem Titan Installationsprobleme und Tango schaltete zunächst mal bei etlichen HTC-Usern die Systemsounds komplett ab bis man das Gerät neu startete.
Vor dem Hintergrund bin ich stark dafür, dass man die Verwendung von Native Code Microsoft gegenüber bei Einreichung der App begründen muss und es regulär nicht gestattet ist Native Code auszuführen. Das würde es für Sonderfälle wie komplexe Soundeffekte erlauben ausgeführt zu werden und würde verhindern, dass Unmengen an Newbies mit ihren Native-Code-Experimenten die Stabilität des Systems beeinträchtigen.
Realtime unter Windows? Wenn es auf solche Dinge ankommt ist das das falsche Betriebssystem. Windows ist kein Echtzeitbetriebssystem, durch den Windows Sheduler. Wäre auch reichlich dumm wenn eine Anwendung mal eben 100& Prozessorzeit bekommt, und das betriebssystem gar nicht mehr läuft ;) Die einzige Möglichkeit die ich kenne um dort etwas unter Echtzeit laufen zu lassen sind Kerneltreiber. Da wird auch nativer Code nichts bringen.
Einspruch. Bei jedem mit XNA Framework entwickelten Spiel handelt es sich gewissermassen um eine Realtime Anwendung, da die Deadline fuer die Rechenzeit pro Frame mit 16ms eingehalten werden muss. Ansonsten ruckelt es nämlich. Wenn da die Garbage Collection unverhofft zuschlägt, ist das tödlich.Zitat:
Realtime unter Windows? Wenn es auf solche Dinge ankommt ist das das falsche Betriebssystem.
Ich brauche nicht zwangsläufig 100% CPU Leistung sondern ein möglichst deterministisches Verhalten. Das ist aber nochnichtmal der Punkt. Managed Code ist für diverse DSP algorithmen generell viel zu langsam, zumal ich selbige auch nur in C++ vorliegen habe. Die 10% Performance Einbusse halte ich für ein Ammenmärchen bei diversen Berechnungs-Kernels.
Zeugt eher von einer fehlenden oder fehler-behafteten Mixer/Sound API als von einem generellen Problem mit native Code.Zitat:
Im Ergebnis habe ich mit Navigon auf dem Titan Installationsprobleme und Tango schaltete zunächst mal bei etlichen HTC-Usern die Systemsounds komplett ab bis man das Gerät neu startete.
Wasimmer der Grund dafür sein mag. Mehrfachvererbung kostet zur Laufzeit garnichts. Welche Virtual Function Table benutzt wird, kann der Compiler statisch evaluieren. dynamic_cast<> kostet natürlich was, sollte aber vermieden werden.Zitat:
C++ ist hier durch die Komplexität der Mehrfachvererbung (die es unter C# nicht gibt) im Nachteil.
Nur mal so interessehalber, bei besagtem Benchmark, wurd also C# Code mit einfach Vererbung gegen C++ Code mit Mehrfachvererbung vergleichen? Inwiefern war das dann noch der "funktional gleiche" Code?
Ich werd bei nächster Gelegenheit mal ein paar Tests hier posten. Mal schaun ob es möglich ist, die C# Variante in den 10% Bereich der C++ Variante zu bekommen.
16ms sind nicht Echtzeit. 16ms sind in der Prozessorwelt eine halbe Ewigkeit. Von Echtzeit spricht man, wenn ein Programm ohne Unterbrechung laufen kann, also niemals die Zeitscheibe an das Betriebssystem abgetreten wird und der Thread schlafen gelegt wird. Auf einem Einkerner ist sowas tödlich, da so immer nur ein Programm laufen kann, und das Betriebssystem keine Rechenzeit bekommt.
Logischer Weise ist C++ nur schneller wenn die mögliche Optimierung vom Programmierer auch ausgenutzt wird. Schließlich steht zum Schluss immer der Compiler, der Binaries erzeugt. Und dass Managed Code unmittelbar vor der Ausführung kompiliert wird hat keinen Einfluss auf die Ausführungsgeschwindigkeit eines Programms zumal dies nur beim ersten Mal der Fall ist.
Selbst wenn Nativ programmiert werden könnte müssten die meisten Anwendungen weiterhin APIs von Windows Phone nutzen um auf bestimmte Daten zuzugreifen..
Im Übrigen basiert Windows Phone auf Windows CE und das war immer und ist auch weiterhin ein Echtzeitbestriebssystem!
Viele Grüße
Die Apps laufen aber nicht in Echtzeit. Wäre ja auch ziemlich blöd wenn as betriebssystem keine Rechenzeit mehr bekommen würde, oder etwa nicht?
Aber theoretisch ist Windows CE ein betriebssystem dass dies unterstützt. Ich bezog mich auf deinen Ausspruch "Realtime unter Windows? usw." Was dann wohl Käse ist.
Ich glaub du haust hier was durcheinander. ThreadX, VxWorks, QNX etc. sind alles Echtzeitbetriebssysteme, in welchen sehr wohl Preemption am Ende einer Zeitscheibe auftritt.Zitat:
Von Echtzeit spricht man, wenn ein Programm ohne Unterbrechung laufen kann, also niemals die Zeitscheibe an das Betriebssystem abgetreten wird und der Thread schlafen gelegt wird.
Du solltest dir vielleicht mal die Frage stellen, wozu das Betriebssystem Rechenzeit braucht wenn eine App laeuft. Dann sollte sich die Frage auch beantworten lassen.Zitat:
Die Apps laufen aber nicht in Echtzeit. Wäre ja auch ziemlich blöd wenn as betriebssystem keine Rechenzeit mehr bekommen würde, oder etwa nicht?
Die Sache ist leider etwas komplexer. Erstmal muss eine runtime compilierung relativ schnell gehen, eine ausgefeilte Analyse wie sie offline moeglich ist duerfte hier flachfallen zumal die Frage des Schedulings und der Register Allocation NP-hard sind. Zweitens gehen durch den Zwischencode Informationen unwiederruflich verloren. Im Zwischencode ist das Programm im allgemeinen nicht mehr strukturiert und statische Typ-Informationen stehen nur sehr eingeschraenkt zur Verfuegung.*Zitat:
Schließlich steht zum Schluss immer der Compiler, der Binaries erzeugt. Und dass Managed Code unmittelbar vor der Ausführung kompiliert wird hat keinen Einfluss auf die Ausführungsgeschwindigkeit eines Programms zumal dies nur beim ersten Mal der Fall ist
*Soweit ich weiss basiert der Zwischencode bei Microsoft auf einer Stack-Maschine und nicht auf einer Registermaschine. Habe mich aber damit noch nicht sehr intensiv beschaeftigt.
Das OS braucht die Rechenzeit für die Hardwaretasten, Tcp/IP, Netz, Wlan, andere Kerneltreiber und unzählige Sachen mehr. Dann kann die App nicht mehr in Echtzeit laufen. Die Software würde ja nur noch Fehler produzieren, weil die Erdorderliche Zeit nicht eingehalten wird.
Hast du dich schonmal mit IL Code beschäftigt? Von der verwendeten Programmiersprache wird nach IL Code optimiert, und dann nochmal zur Laufzeit, um das ganze auf das jeweilige System anzupassen. Zu dieser Zeit ist das ganze immer noch Typsicher. Warum meinst du wäre das Programm nicht mehr strukturiert?
Ich glaube aber das wir langsam wirklich vom Thema abkommen. Ich glaube ein anderer thread wäre ganz sinnvoll
Hardwaretaste, Kerneltreiber -> IRQ haben einen hoeheren Request Level als der hoechste Applikation Level, davon mal abgesehen muesste deine App (bzw die App im Vordergrund auch erstmal einen Driver Request senden), das OS macht das ja nicht weils gerade lustig ist. Ferner laufen die ISRs nur sehr kurz.Zitat:
Das OS braucht die Rechenzeit für die Hardwaretasten, Tcp/IP, Netz, Wlan, andere Kerneltreiber und unzählige Sachen mehr. Dann kann die App nicht mehr in Echtzeit laufen. Die Software würde ja nur noch Fehler produzieren, weil die Erdorderliche Zeit nicht eingehalten wird
TCP/IP-> Wenn deine App keine Verbindung aufgebaut hat, tut sich da abgesehen von ICMP und ARP garnichts
Wie ich bereits sagte, speziell mit IL weniger. Die Konzepte sind mir aber sehr gelaeufig.Zitat:
Hast du dich schonmal mit IL Code beschäftigt?