Artikelkommentarer

Kommentatorn ansvarar själv för sina inlägg. Inlägg som innehåller diskriminerande uttalanden, personliga påhopp eller språk som kan uppfattas som stötande, kommer att tas bort av tjänstgörande redaktör. Även poänglösa datorkrigsinlägg tas bort.

OBS! Läs dessa regler som gäller vid postning av inlägg.

Regler för inlägg i artikelforumet

Kommentatorn ansvarar själv för sina inlägg. Inlägg som innehåller diskriminerande uttalanden, personliga påhopp eller språk som kan uppfattas som stötande, kommer att tas bort av tjänstgörande redaktör. Även datorkrigsinlägg och inlägg som är utanför ämnet, kan tas bort.

IDG förbehåller sig dessutom rätten att i varje enskilt fall bedöma huruvida ett inlägg ska tas bort, även om det inte faller under någon av reglerna ovan.

Upprepat postande av olämpliga inlägg kan medföra avstängning från artikelforumen.

Frågor? Mejla till redaktören, carl.grape@idg.se.

Läs mer om vår policy i diskussionsforum

Kommentarer till:

Microsoft: ”Rätt tid att börja utveckla Metro-appar”

Slutändan?

2012-06-12 08:44

Slutänden!

Depsidee

Slutändan?

2012-06-12 09:18

http://www.dn.se/kultur-noje/spraket/ingen-skillnad-i-slutanden

ButanSkojarn

Protest

2012-06-12 09:46

Det har ju. efter vad jag förstått, varit en del protester mot att gratisversionen av Visual Studio bara klarade att användas för Metro appar, och att Microsoft tvingats backa. Jag skulle gissa att vi kommer att få liknande protester från andra användargrupper vad det gäller andra program. Kan man inte ens få med sig utvecklarna helt och fullt blir det här en svår övergång för Microsoft.

unoengborg

Sannolikt riktigt

2012-06-12 09:46

Apple har precis visat att man satsar på konsumentdatorer medan Microsoft satsar på prestanda i form av GPU-programmering för massorna. På allt från värsta desktop till paddor och telefoner.

hvCAD

Sannolikt riktigt

2012-06-12 10:53

Uhm va? Skulle Microsoft vara ensamma om att det finns GPU-baserade enheter?

falde

Sannolikt riktigt

2012-06-12 11:02

Nej, men Microsoft ligger långt före när det gäller GPGPU programmering.

Som Herb Sutter uttryckte saken: "Is the Hello World parallel GPU program a page and half, or a couple of lines?".

hvCAD

Sannolikt riktigt

2012-06-12 13:30

Var menar du att de ligger långt före?

Vad har den sista frågan med ämnet att göra?

falde

Sannolikt riktigt

2012-06-12 13:34

Den sista frågan är svaret på den första.

OpenCL är nästa hopplöst tungrott i förhållande till C++ AMP som döljer det mesta arbetet bakom en uppsättning templates. Dessutom kan man fortsätta programmera i C++.

hvCAD

Sannolikt riktigt

2012-06-12 14:42

"Den sista frågan är svaret på den första."
Nej.

"OpenCL är nästa hopplöst tungrott i förhållande till C++ AMP som döljer det mesta arbetet bakom en uppsättning templates. Dessutom kan man fortsätta programmera i C++."
Jag tycker inte att OpenCL skulle vara mer tungrutt än C++ men det är off topic. Var någonstans skulle C++ AMP ligga före andra ramverk för att komma åt GPGPU i C++?

Sen är ju C++ AMP i sin tur hopplöst tungrott i förhållande till Forth.
": HELLO ( -- ) CR ." Hello, world!" ;

HELLO <cr>
Hello, world!"
Blir det färre rader kod i C++ amp?

falde

Sannolikt riktigt

2012-06-12 14:58

Mitt påstående skall inte tas som att C++ AMP presterar bättre än OpenCL utan som att det är smidigare att använda. I min värld påverkar det hur mycket kod jag kan tänka mig att flytta över till GPUn.

Du tycker tydligen inte att det är någon skillnad mellan C resp C++ och i så fall tycker jag att vi kan enas om att vara oense; vi lär knappast övertyga varandra.

hvCAD

Sannolikt riktigt

2012-06-12 16:24

"Mitt påstående skall inte tas som att C++ AMP presterar bättre än OpenCL utan som att det är smidigare att använda. I min värld påverkar det hur mycket kod jag kan tänka mig att flytta över till GPUn."
Det togs det inte heller som, men mitt påstående är att OpenCL inte är mindre smidigt att använda.

"Du tycker tydligen inte att det är någon skillnad mellan C resp C++ och i så fall tycker jag att vi kan enas om att vara oense; vi lär knappast övertyga varandra."
Hur kom C in i diskussionen? Ja lägger du ord i munnen på mig och tar upp ett språk som vi inte ens har diskuterat så är det klart att "vi" är oense...

För övrigt hade jag för brottom i mitt tillägg, jag menade givetvis Fortran.
----
program helloworld
write (*,*) "Hello, world."
end program helloworld
----
Sådär - kan du skriva något i C++ som blir enklare än denna OpenCL-kod så varsågod.

Men som sagt nu gällde ju inte disussionen skillnaden mellan olika språk. Var någonstans är Microsofts C++-lib för GPGPU bättre än andra C++-lösningar för samma sak. Tex . Den frågan svarade du inte på.

Här har du tex ett OpenCL-exempel skrivet i C/C++, hur menar du att det skulle vara smidigare att implementera detta med Microsofts lösning?
---------------
void run (data_t xmin, data_t ymin, data_t xmax, data_t ymax, data_t step, data_t range,
town pt[rangex][rangey] ,town t[nb])
{
size_t i, j, k;
fprintf (stderr, "begin computation...\n");
for(i=0;i<rangex;i++)
for(j=0;j<rangey;j++) {
pt[i][j].latitude =(xmin+step*i)*180/M_PI;
pt[i][j].longitude =(ymin+step*j)*180/M_PI;
pt[i][j].stock =0.;
for(k=0; k<nb; k++) {
data_t tmp = 6368.* acos(cos(xmin+step*i)*cos(t[k].latitude)
* cos((ymin+step*j)-t[k].longitude)
+ sin(xmin+step*i)*sin(t[k].latitude));
if(tmp<range)
pt[i][j].stock += t[k].stock / (1+tmp);
}
}
fprintf(stderr,"end computation...\n");
}

falde

Sannolikt riktigt

2012-06-12 17:40

Med "Hello World" åsyftades inte möjligheten att skriva ut "Hello world" utan att göra det enklaste du kan tänkas vilja använda GPGPU-programmering till, som t.ex. addition av två vektorer.

Ditt exempel är inte komplett. Det ser ut att vara delen som skall köras på GPU'n. Alltså saknas kod för att anropa kompilering samt minneskopiering mellan grafikminne/internminne och anrop. Det är där skon klämmer. Referensen till C++ betraktar jag som fåfäng: stoppa in en std::vector parameter så önskar jag lycka till med kompileringen.

Följande exempelkod finns på MSDN:

void AddArrays() {
int aCPP[] = {1, 2, 3, 4, 5};
int bCPP[] = {6, 7, 8, 9, 10};
int sumCPP[5] = {0, 0, 0, 0, 0};

array_view<int, 1> a(5, aCPP);
array_view<int, 1> b(5, bCPP);
array_view<int, 1> sum(5, sumCPP);

parallel_for_each(
sum.extent,
[=](index<1> idx) restrict(amp)
{
sum[idx] = a[idx] + b[idx];
}
);

for (int i = 0; i < 5; i++) {
std::cout << sum[i] << "\n";
}
}

Först definieras tre arrayer i internminnet, sedan tre array_view som sköter datakopiering till och från grafikminnet. Därefter utförs beräkningarna på GPU'n, för att slutligen skrivas ut med CPU-kod. Det funkar utmärkt att mata array_view med std::vector objekt och samma kod kan köras på CPU'n.

hvCAD

Sannolikt riktigt

2012-06-12 21:27

På vilket sätt är det mindre omständligt än det exempel jag angav. Jag skriver om koden till OpenCL-kod skriven i standard C/C++.

Vad är är sämre med koden nedan? Eventuellt kan du även slå ihop looparna men jag har inte testat ifall loop unfoldingen lyckas bryta isär dem vid kompilering. Istället låter jag dem stå kvar som separata loopar för att vara säker på att kompilatorn skickar den ena loopen till OpenCL.

Jag korrigerade även ditt programmeringsfel i sista lopen, det heter endl i C++ streams, inte "\n".

----------------
void AddArrays() {
int aCPP[] = {1, 2, 3, 4, 5};
int bCPP[] = {6, 7, 8, 9, 10};
int sumCPP[5] = {0, 0, 0, 0, 0};

for (int i = 0; i < 5; i++) {
sumCPP[i] = aCPP[] + int bCPP[];
}

for (int i = 0; i < 5; i++) {
std::cout << sum[i] << endl;
}
}

falde

How Microsoft Lost The API Wars.

2012-06-12 13:10

http://www.joelonsoftware.com/articles/APIWar.html

falde

How Microsoft Lost The API Wars.

2012-06-12 14:14

Kanske vill du komplettera med en historia om hur Apple utlovade en 64-bitars version av Carbon men sedan drog tillbaka löftet, trots att den kommit ut i beta.

hvCAD

How Microsoft Lost The API Wars.

2012-06-12 16:33

Hur skulle det vara kompletterande då debattinlägget jag hänvisar till inte handlar om hur Microsoft la ner Win16-stödet i 64:bit Windows.

Bägge relaterade händelserna är ju intressanta, men inget som har med ämnet att göra.

falde

How Microsoft Lost The API Wars.

2012-06-12 17:15

Det är roligt hur många grupper det finns som klagar på Microsoft.

I ena änden finns dom som tycker att Microsoft jobbar för mycket med bakåtkompatibilitet, sen finns en stor massa mängd med folk, och i andra änden finns en grupp som tycker att Microsoft har för dålig bakåtkompatibilitet. :)

Kul att följa. :)

giddorah - http://www.wpsverige.com - Nu även forum!

How Microsoft Lost The API Wars.

2012-06-12 18:13

Vilka tycker att Microsoft jobbar för mycket med bakåtkompatibilitet? Går det ens att jobba för mycket med bakåtkompatibilitet?

falde

How Microsoft Lost The API Wars.

2012-06-12 21:30

Du har ju alltid Kjell Kamsvag som den absolut största motståndaren till Microsofts bakåtkompatibilitet.

Jag har för mig att han tyckte att det var en nackdel att man kan uppgradera hela vägen från Windows 1.0 till Windows 7 utan problem.

giddorah - http://www.wpsverige.com - Nu även forum!

How Microsoft Lost The API Wars.

2012-06-12 23:31

Utan problem vet jag inte om jag tror på. Att gå från et OS som rullar bäst på FAT till ett som rullar bäst på NTFS är nog inte helt sunt...

Någon nackdel är det ju inte att det går, frågan är hur efterfrågat det är.

För det flesta företag är ominstallationer inget problem. Det är binärkompatibiliteten som är det viktiga, dvs att jag kan installera och köra mitt program.

Här måste jag ju säga att Wine ligger mycket bättre till än Windows. Wine har inte haft något problem med mina Win16-program. Den kör DosBOX med en egen implementation av Win16 ovanpå. Precis som WoW för 16-bit då förutom att DosBOX emulerar hela hårdvaran och kan köra på AMD64

falde

How Microsoft Lost The API Wars.

2012-06-13 00:20

Intressant att höra sina åsikter...

"För det flesta företag är ominstallationer inget problem. Det är binärkompatibiliteten som är det viktiga, dvs att jag kan installera och köra mitt program."

+1

Kjell Kamsvag

How Microsoft Lost The API Wars.

2012-06-12 17:55

Du vet mycket väl att artikeln du refererar till handlar om bakåtkompatibilitet för en liten delmängd av Microsofts produkter.

Om Microsoft har förlorat kriget finns det rimligtvis en vinnare och Apple ligger rimligtvis bra till. Jag tog mig friheten att insinuera att Apples tredjepartsutvecklare har liknande erfarenheter. Kaoset på Android behöver väl inte ens nämnas?

hvCAD

How Microsoft Lost The API Wars.

2012-06-12 18:24

Nej, det är inte vad artikeln handlar om.

Jag ser inga tecken på att Apple skulle vara någon vinnare. Utvecklaren som jag länkade till anser att Webb-standarder blir vinnaren vilket till jag till viss del håller med om - när det gäller administrativa system och liknande.

När det gäller program med en tung klientdel, tex spel, så är inte webben ännu någon vinnare. Där är det istället de standardiserade API:erna som blir allt mer använda. POSIX, Single Unix, OpenGL, Qt, SDL, SQLite och en lång rad andra API:er ser man allt mer av. Även .Net/Java ser man allt mer av.

Framförallt är det behovet av att koda för flera operativsystem utan att skriva olika kod som blir allt mer aktuellt.

Själv portar jag förs Win16/32-kod till sådana API:er, först när det fungerar på XP portar jag till Windows 7, OS X och Linux samtidigt. Eller till Java/.NET/Webben.

"Om Microsoft har förlorat kriget finns det rimligtvis en vinnare och Apple ligger rimligtvis bra till. Jag tog mig friheten att insinuera att Apples tredjepartsutvecklare har liknande erfarenheter. Kaoset på Android behöver väl inte ens nämnas?"
Jag har utvecklat mycket till Apple och Android och har inte några sådana erfarenheter alls. Vad det är för "kaos" du snackar om när det gäller Android har jag ingen aning om, det har inte uppstått något kaos för mig när jag utvecklat för plattformen.

falde

How Microsoft Lost The API Wars.

2012-06-12 19:10

Varför finns där då en rubrik med texten "Microsoft Lost the Backwards Compatibility Religion"?

Jag ser Webb-gränssnitt som en tillfällig utveckling, driven av brist på bättre industristandarder, motarbetad av mobila enheters batteritid. Man får helt enkelt bättre batteritid med "appar", en utveckling som varit synnerligen viktig för bl.a. iPhone/iPad utveckling och därmed Apple.

Jag gick från MFC till wxWidgets, vilket också fungerade utmärkt på Mac, tills Apple drog tillbaka 64-bitars Carbon. Det fungerar nog hyfsat på Linux också men den porten har jag aldrig tagit ända fram.

Det är säkert bara elakt förtal att det finns många typer av Androidenheter.

hvCAD

How Microsoft Lost The API Wars.

2012-06-12 23:40

Det är svarade jag på vilket försvann.

Rubriken finns därför att en liten grupp internt på Microsoft bestämt sig för att bakåtkompatibiliteten inte är bra. Reseten av artikeln handlar om hur det i sin tur leder till att utvecklare av 3:eparts-applikationer lämnar Microsofts API:er helt.

Varför skulle Webb-gränssnitt vara en tillfällig utveckling? Webb-standarnerna är just industristandarder och därför används de. Det kommer nya obh bättre webb-standarder med jämna mellanrum. Till exempel Efficient XML Interchange (EXI) som är på gång och förhoppningsvis eliminera behovet av en parser i webbläsarna, annat än för kompatibiliet med äldre standarder.

Vad får dig att tro att native appar skulle ha lägre batteriförbrukning än webb-appar?

Vad hade du för problem med att köra wxWidgets ovanpå Cocoa?

Själv föredrar jag Qt då mina applikationer fungerar smärtfritt på OS X, Linux och Windows med denna. wxWidgets tycker jag är för buggig.

Varför skulle det vara elakt förtal att det finns många typer av Androidenheter. Och vad har det med min fråga om "chaoset" att göra? Jag har inte upplevt något "chaos" när jag utvecklat till Android.

falde

Comments powered by Disqus

Fler nyheter

- TechWorld:

Jörgen Städje

Under över alla Uber


- TechWorld:

Så hackas du genom en kattfilm


- TechWorld:

Marcus Murray

"Vi är på väg in i en helt ny it-värld"


- TechWorld:

anonym

Rätt tjänst gör dig rätt anonym


- TechWorld:

hackarnas verktygslåda

Hackarens verktygslåda: Insticksprogram

- TechWorld:

"Det finns inget som är NSA-proof"


- TechWorld:

ubuntu

Ubuntu 14.10 är här


- TechWorld:

grön it

Grön it - snällt eller bara snålt?


- TechWorld:

moderkort

Moderkort genom tiderna


- TechWorld:

kodsnack

Kodsnack: Att bygga in kunskap i system

- TechWorld:

kali linux

Hackarens verktygslåda: Kali Linux


- TechWorld:

koppar

Teknikens byggstenar del 10: Ni, Cu och Zn


- TechWorld:

Premiär för Jörgen Städjes makalösa tv-program!


- TechWorld:

vmworld

VMware lägger om kursen mot molnet


- TechWorld:

ios 8 utveckling

IOS 8 - utvecklarpusslet växer

- TechWorld:

Daniel Åhlin

"Android mer robust än någonsin"


- TechWorld:

Jörgen Städje

Blå lysdioder - värda ett nobelpris?


- TechWorld:

soghoian

"It-säkerhet bara för de som har råd"


- TechWorld:

radera data

Så fungerar rätten att bli raderad


- TechWorld:

kambi

De sparar storkovan på att spola Splunk

Whitepapers, webcasts, kompendier och partnermaterial Fler utvalda whitepapers

Flasha med närminnet
Drifta själv eller välja molnet?
Illusion att flash är dyrare
Mainframe makeover
Gratis nyhetsbrev
Välj ett nyhetsbrev:
Weekly - Security -
Open Source Update





Please don't insert text in the box below!
Kontakta oss
Postadressen är:
TechWorld, Karlbergsvägen 77, 106 78 Stockholm

För prenumerationsärenden:
Logga in här eller ring 08-799 62 39.




Copyright © 1996-2013 International Data Group
Sök efter artiklar och produkter: