Native Code + andere neue Features für WP7 unter review

So hab mal ein Beispiel programmiert. Es handelt sich um eine 1024 Punkt diskrete Fourier Transformation(so ich keine Fehler gemacht hab). Ich habe keine Optimierungen in C++ vorgenommen und das ganze einfach nach C# portiert.

C:

void DFT(double* in, double* out) {

double realout, imagout;

for (int i=0; i<1024; i++) {
realout = 0.0;
imagout = 0.0;
for (int j=0; j<1024; j++) {
realout += in[2*j] * w_1024[(2*(j*i)) & 0x3ff] - in[(2*j+1) & 0x3ff] * w_1024[(2*(j*i)+1) & 0x3ff];
imagout += in[2*j+1] * w_1024[(2*(j*i)) & 0x3ff] + in[(2*j) & 0x3ff] * w_1024[(2*(j*i)+1) & 0x3ff];
}
out[2*i] = realout;
out[2*i+1] = imagout;
}
}

C#:

static void DFT(double[] input, double[] output)
{
double realout, imagout;

for (int i=0; i<1024; i++) {
realout = 0.0;
imagout = 0.0;
for (int j=0; j<1024; j++) {
realout += input[2*j] * w_1024[(2*(j*i)) & 0x3ff] - input[(2*j+1) & 0x3ff] * w_1024[(2*(j*i)+1) & 0x3ff];
imagout += input[2*j+1] * w_1024[(2*(j*i)) & 0x3ff] + input[(2*j) & 0x3ff] * w_1024[(2*(j*i)+1) & 0x3ff];
}
output[2*i] = realout;
output[2*i+1] = imagout;
}
}

Performance Messung:

QueryPerformanceFrequency(out freq);

QueryPerformanceCounter(out start);

for (int i = 0; i < 100; i++)
DFT(input,output);

QueryPerformanceCounter(out stop);

Console.WriteLine("Duration: {0} sec\n", ((double)(stop - start) / (double)freq));

Ergebnis: 1.8 sec (C#) 0.6 sec (C++)

Wir reden hier nicht um 10% oder was marginales, es geht um Faktor 3! Aus meiner Sicht völlig inakzeptabel. Und selbst wenn die Performance fuer einfache Games reicht, weil man GPU limitiert ist, so braucht die CPU fuer die entsprechende Berechnungen 3 mal solange, mit entsprechend hoeherem Batterie-Verbrauch.
Vielleicht kann mir ja einer der Experten hier zeigen wie ich den Code auf 10% and die C++ Version ranbekomme.

wo denn? auf nem x64? da kann der C++ compiler ja auch ordentlich optimieren.
kurz und gut suggestion box

Test lief auf nem Intel i7, 32 bit Code. 64 bit Code wäre bei der Applikation etwas langsamer. Auf WP7 kann ich native Code leider nicht testen.
Was ich aber sagen kann ist, dass viele meiner Algorithmen auf nem Axim X50 (Arm v5, 600MHz, 6 Jahre alt) native übersetzt deutlich schneller sind als in C# auf dem Omnia 7 (1GHz, Arm v7). Durch den Umstieg auf C# (für zeitkritische Berechnungen) sind mal so eben 6 Jahre CPU Entwicklung zunichte gemacht.

ps. Code wie oben würde man normalerweise auch noch Neon/SSE optimieren unter C. Da ist dann im Normalfall auch nochmal Faktor 2+ drin.

gut, dann ist das wohl so. Aber Fritz hat nicht unrecht. Pack es in die Suggestion Box, dann wird MS schon drüber nachdenken, es zuzulassen. Ich befürchte wohl eher nicht, da DLLs prüfen einiges aufwändiger ist als Aufrufe von Managed Code.

Hab meine Stimme hier http://wpdev.uservoice.com/forums/110705-app-platform abgegeben.

Immerhin ist die Forderung nach einem native SDK da auf Platz 4.

Ja, da hat Tala recht - für Devs gibt es ein eigenes Uservoice. Die Suggestion-Box für User-Wünsche kam erst später nachdem etliche User das Dev-Uservoice kontaminiert hatten.

MS hat nun auch auf andere Anfragen reagiert und hat Features wie z.B. SMS-API auf eine Liste gesetzt von neuen Features für WP7
http://wmpoweruser.com/microsoft-rev...oper-requests/

Sehr schön. Die Sache mit den SMSen muss dann aber gut gesichert sein mit expliziter Bestätigung des benutzers bevor man zugreifen kann. Ich habe keine Lust das jemand meine privaten Nachrichten liest

Das Problem wird da wieder sein: die App fordert den Zugriff an und man bekommt es angezeigt. Aber einfach den Zugriff verbieten wird nicht gehen => bliebe nur auf die App zu verzichten. Bisher gibt es ja nur ein Feature wo explizit von Microsoft ein Opt In gefordert wird und das ist die Location-Info. Adressbuch und Kalender gibts ja auch freien Lesezugriff wenn man die Permission hat.

Hallo,
ich weis zwar nicht wie das Beispiel oben compilieren soll oder was es genau macht, aber ich wollte das nun auch mal testen.
Ich hab alles mal compilierbar gemacht, hier der Code:
C#

using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
DateTime t1 = DateTime.Now;
double[] input = new double[2049];
for (int i = 0; i < 2049; ++i)
input[i] = i;
double[] output = new double[2049];
for (int i = 0; i < 100; ++i)
DFT(input, output);
DateTime t2 = DateTime.Now;
TimeSpan ts = t2 - t1;
Console.Write(ts.Milliseconds.ToString());
Console.ReadLine();
}
static void DFT(double[] input, double[] output)
{
double realout, imagout;
for (int i = 0; i < 1024; ++i)
{
realout = 0.0;
imagout = 0.0;
for (int j = 0; j < 1024; ++j)
{
realout += input[2 * j] * input[(2 * (j * i)) & 0x3ff] - input[(2 * j + 1) & 0x3ff] * input[(2 * (j * i) + 1) & 0x3ff];
imagout += input[2 * j + 1] * input[(2 * (j * i)) & 0x3ff] + input[(2 * j) & 0x3ff] * input[(2 * (j * i) + 1) & 0x3ff];
}
output[2 * i] = realout;
output[2 * i + 1] = imagout;
}
}
}
}

C++

#include "stdafx.h"
#include <stdio.h>
#include <time.h>

void DFT(double* in, double* out) {

double realout, imagout;
for (int i=0; i<1024; ++i) {
realout = 0.0;
imagout = 0.0;
for (int j=0; j<1024; j++) {
realout += in[2*j] * in[(2*(j*i)) & 0x3ff] - in[(2*j+1) & 0x3ff] * in[(2*(j*i)+1) & 0x3ff];
imagout += in[2*j+1] * in[(2*(j*i)) & 0x3ff] + in[(2*j) & 0x3ff] * in[(2*(j*i)+1) & 0x3ff];
}
out[2*i] = realout;
out[2*i+1] = imagout;
}
}

int _tmain(int argc, _TCHAR* argv[])
{
clock_t t1 = clock();
double *input = new double[2049];
for (int i = 0; i < 2049; ++i)
input[i] = i;
double *output = new double[2049];
for (int i = 0; i < 100; ++i)
DFT(input,output);
clock_t t2 = clock();
double d =(double)(t2-t1);
printf("%g", d);
getchar();
return 0;
}

jeweils als Console Application


Meine Ergebnisse:
C++: ~470ms
C#: ~650ms
Das schaut nun doch schon ganz anders aus. Und alles ohne weitere Optimierungen

Bei der C# Berechnung der Zeitspanne steht

Console.Write(ts.Milliseconds.ToString());

Du meinst aber sicher

Console.Write(ts.TotalMilliseconds.ToString());

@FourSpotProject
korrekt, war mein Fehler. Dann komm ich auf die ersteren Verhältnisse. Trotzdem überrascht mich die Differenz

Der Managed Code der CLR prüft bei jedem Zugriff auf ein Array ob sich der Zugriff innerhalb von dessen Grenzen befindet, das kostet z.B. schon mal Zeit. Soweit ich weiß gibt es aber durchaus Möglichkeiten den Code so zu schreiben, dass der JIT die Abfragen rausoptimiert, da er erkennen kann dass man innerhalb der Grenzen bleibt - muss ich mal wieder nachsehen.

Gerade diese Sicherheitsabfragen (und die damit nicht so gravierenden Bugs) sind ja immer ein Argument pro Managed Code aber das kommt natürlich für einen Preis.

Der Grund für den Zeitverlust dürfte wie von StevieBallz beschrieben größtenteils an den Array bound checks liegen. Eine gern benutze Optimierungsmöglichkeit bei weniger komplexen Beispielen ist es, möglichst auf for each-Schleifen zurückzugreifen. Weitere Optimierungen finden sich hier.

So wie das Beispiel hier steht, wird da aber ohne Einiges an Aufwand nicht mehr viel gehen (zumindest hab' mit ner halben Stunde Gefrickel nicht viel an Speed rausholen können).

Meiner Erfahrung nach hat C++ bei rein mathematischen Aufgabenstellungen die Nase deutlich vorn, Managed code punktet dafür auf vielen anderen Gebieten:

• Code Sicherheit
• Reflection
• Bibliotheken
• bessere Unterstützung was die Tools angeht (z.B. einen Webservice unter Visual Studio einzubinden ist normalerweise ne Sache von drei Klicks)
• meiner Meinung nach leichter erlernbar
• schnellere Weiterentwicklung (z.B. Lambda Ausdrücke gibt es bei C# seid Version 3.0, sprich 2007, in C++ erst seid 2011 mit C++11)

Aber ich finde es recht müßig, darüber zu diskutieren, welche Sprache letztendlich besser ist. Das ist ungefähr so, als ob die Farbe Blau besser ist als Rot. Das kann höchstens je nach Anwendungsfall entschieden werden (Mein Dach gefällt mir z.B. besser in rot, um bei der Analogie zu bleiben). Und meistens ist es sowieso die persönliche Präferenz.

Aber es stimmt definitiv auch, dass ne ordentliche C++ Unterstützung in Windows Phone fehlt. Die wird aber spätestens kommen, wenn WinRT auf WP übertragen wird (ich bin da skeptisch, ob Microsoft das schon mit Apollo Ende des Jahres schafft, oder erst mit Windows Phone 9). Ich hoffe nur, dass dann auch gemixte Bibliotheken möglich sind, so dass man den Performance-kritischen code in C++ schreiben kann, und für den Rest C#.

Grüße!

Na ja, wenn es keine gemischten Libraries gibt ist es eigentlich auch kein Beinbruch. Dann kommt der kritische Code halt in ne eigene DLL die in C++ geschrieben ist. Wenn man das dann nicht alles über das Marshaling x-mal drüberwürgt sollte es schon passen. Das ist scheinbar ohnehin die Richtung in die es geht. Also evtl. sehen wir mit Apollo die Möglichkeit bestimmte Code-Teile in ner Native-Assembly haben und ausführen zu können aber UI-Zugriff, etc. aus dem Native-Code wird nicht gehen.

@StevieBallz,

Stimmt, das meinte ich ja auch

@Tala unter welcher Konfiguration hast du dein C# beispiel kompiliert?

Kompiliert wurde das Beipiel unter VS 2010 Ultimate, C# Console Application, Release Configuration

Ich hab mich mit den Compilersettings da jetzt mal kurz gespielt, Ergebnis auf einem Core 2 Quad 2,93 Ghz:

Release ist ca. 200 ms schneller als Debug
x86-Code ca. doppelt so schnell wie x64-Code

Liegt an den fehlenden Optimierungen in der Debugversion. Was auch bremst ist das Projekt zu Debuggen. Dann werden im Assemblercode Nops eingebaut.