Köra program på alla datorer

Ta molnet, du betalar i princip per spenderad CPU-cykel och >80% av kostnaden kommer efter att man utvecklat programvaran. Vad bör optimeras?

Sedan Java7 har Java fått långt bättre runtime-prestanda än .NET någonsin haft, framförallt på system med många CPU-kärnor. Det är helt enkelt lägre driftkostnad med Java förutsatt att man har ett system med någorlunda hög last.

Är absolut ingen expert på UI-programmering så det kommenterar jag inte, Java har dock fått JavaFX (standardfiness i Java8) som verkar vara ett rejält lyft.

C# får väldigt mycket nytt, Java får saker som fungerar. Jag föredrar i alla fall det senare...

var container = new Container();
container.Bind<IFoo>().To<FooOne>();
container.Bind<IFoo>().To<FooTwo>();

//Eller ännu mer dynamiskt
container
   .ForAssemblyWithType<FooOne>()
   .BindAll<IFoo>();

public MyConstructor(IEnumerable<IFoo> foos)
{
   this.foos = foos;
}

public class MyViewModel : IHandle<SomeEvent>
{
   public MyViewModel(IEventAggregator eventAggregator) 
   {
       eventAggregator.Subscribe(this);
   }

   public void Handle(SomeEvent message)
   {
       ...
   }
}

        public IEnumerable<IResult> Click()
        {

            var confirm = new ConfirmResult("Proceed?");
            yield return confirm;

            if (confirm.Result == ConfirmResults.Cancel)
                yield break;

            yield return new AlertResult("FOOOOO");
        }

$p.Click = function FooViewModel_Click() {
        var $stateMachineFunc = function() {
            var $this = this;
            var $state = 0;
            var $stateMachine = new (System.YieldIterator$1(Knockout.BindingConventions.DuoCode.IResult).ctor)();
            var confirm = null;
            var $moveNext = function() {
                $top:
                while (true) {
                    switch ($state) {
                        case 0:
                            confirm = new ViewModels.ConfirmResult.ctor("Proceed?");
                            $state = 1;
                            $stateMachine.set_Current(confirm);
                            return true;
                        case 1:
                            if (confirm.get_Result() == 2 /* ConfirmResults.Cancel */) {
                                $state = 3;
                                continue $top;
                            }
                            $state = 2;
                            continue $top;
                        case 2:
                            $state = 5;
                            $stateMachine.set_Current(new ViewModels.AlertResult.ctor("FOOOOO"));
                            return true;
                        case 3:
                            $state = 4;
                            return false;
                        case 4:
                            $state = 2;
                            continue $top;
                    }
                    return false;
                }
            };
            $stateMachine.System$Collections$IEnumerator$MoveNext = function() {
                return $moveNext.call($this);
            };
            $stateMachine.Clone = function() {
                return $stateMachineFunc.call($this);
            };
            return $stateMachine;
        };
        return $stateMachineFunc.call(this);
    };

Hoppas du inser att JS koden du postade är ungefär som att kompilera C och sedan posta den resulterande assemblerkoden, det säger ingenting om hur motsvarade kod skulle se ut om en människa faktiskt skrev motsvarande.

Varför inte så här

function Click() {
	var confirm = new ConfirmResult("Proceed?")
	return new Continuation(confirm, function () {
		if (confirm.Result == ConfirmResult.Cancel)
			return new Continuation()
		return new Continuation(new AlertResult("FOOOOO"))
	})
}

där Continuation är en klass där man kan ta nuvarande värde (första argument) samt anropa Then() för att gå till nästa steg (köra funktionen som är andra argumentet). Logiskt exakt samma sak som du skrev, fast utan "magi" (programming by coincidence) då det inte är en kompilator som gör något utan all logik finns för allmän beskådan.

Det första du skrev, kan du förklara på svenska vad målet med övningen överhuvudtaget är? Kan riktigt inte se vad du vill visa med detta, men är övertygad att det går att göra något som är logiskt ekvivalent på ungefär samma antal rader i både Java och TypeScript.

Nah, det är egentligen mina två hundar som loggar in och gillar. Använder namnet på ena hunden som nick så den andra är lite putt, därför det bara blir en "gilla".

Eller hur. Vad tror du är största flaskhals på en webbplats som Stack Exchange? Det är I/O, vart utförs I/O? I OS-kärnan, så det skulle lika gärna kunna vara skrivet i t.ex. Node.js utan att prestanda på något sätt ändras.

I stället för att ta mitt ord på detta, skriv lite saker själv med TPL och jämför skalbarhet mot Java. Ett populärt test-fall för de som utvecklar runtime-miljöer för parallellism är att göra en parallell version av den rekursiva version av beräkning av Fibonacci-serien. Anledningen är att den innehåller alla kritiska element, är extremt hög teoretisk parallellism, varje underproblem kan lösas separat men det krävs att man sammanfogar delar för det slutliga svaret.

Java fork/join totalt demolerar TPL redan på 4-kärniga maskiner med HyperThreading, på Xeon E5 maskiner skiljer det mer än en tiopotens.

Varför postade du output från kompilatorn som exempel hur komplicerat det blir i JS om du själv tycker att sådan output är irrelevant?

Då undrar jag vad du klassar som "stort" system. Hur många rader kod? Hur många utvecklare? Hur många samtida sessioner ska systemet hantera? vilket typ av maskin körs det på?
För konsensus verkar annars vara att explicit slår implicit varje gång när saker ska skalas upp. Den inkapsling jag gjorde med Contination håller reda på två väldigt enkla saker, nuvarande tillstånd (första argumentet) samt en closure som när den anropas returnerar nästa tillstånd i form av en ny Contination (andra argumentet). Vad exakt gör "yield" med en mening? Det finns saker man måste känna till om "yield" för att undvika vissa fel, så det är en "leaky abstraction" och det är "Programming by Coincidence" att inte exakt först det som händer bakom kulisserna.

Nej, det är inte ett promise. "Promise" är en utfästelse om att någon gång leverera ett värde (av en specifik typ i statiskt typade språk), finns ingen "continuation" (sätt att få tag i nästa tillstånd) associerad med en "promise". Finns två sidor, ett kontext som ska på något sätt leverera värdet och ett kontext som eventuellt väljer att konsumera värdet. Den senare sidan represteras ofta som en typ som kallas future, i C# heter den Task<T>.

Varför är detta

return new Continuation(<state#0>, function() { 
    foo()
    ...
    return new Continuation(<state#1>, ...) 
})

mindre läsbart än detta?

  yield return <state#0>;
  foo();
  ...;
  yield return <state#1>;
  ...;

I första fallet är det helt explicit vad som sker, man går igenom ett pärlband av [tillstånd, closure-till-nästa-tillstånd], i det andra fallet är det logiskt sett samma sak men kompilatorn kommer generera kod (en tillståndsmaskin) som man inte exakt kan förstå med mindre än att läsa genererad IL/maskinkod.
[QUOTE="CyberVillain;15399559"]

container
   .Bind<ITransferProvider>()
   .To<SomeTransferProvider>()
   .Named(TransferProviders.SomeTransferProvider>(); //TransferProviders.SomeTransferProvider är en enum

public class ListAvailableTransfersQueryHandler : IQueryHandler<ListAvailableTransfersQuery, IEnumerable<Transfer>>
{
   private readonly ITransferProviderLocator transferProviderLocator;

   public ListAvailableTransfersQueryHandler(ITransferProviderLocator transferProviderLocator) 
   {
      this.transferProviderLocator = transferProviderLocator;
   }

   public Task<IEnumerable<Transfer>> Handle(ListAvailableTransfersQuery query)
   {  
      //transferProviderLocator.Get är en abstraktion av container.Get då det är ett antipattern att ha beroenden till di containern direkt
      return transferProviderLocator.Get(query.Provider).ListAvailableTransfers(Mapper.Map<AvailabilityParameters>(query));
   }
}

Vad är "fullskalig" IoC (Inversion-of-control)? Varför använder du ibland termen IoC och ibland termen DI (Dependency Injection), de är samma sak fast man ansåg att IoC missförstods av så många att det krävdes ett bättre namn. DI är inget mer än separation av skapandet av objekt från dess användande (och det är i de flesta fall en bra design).

Vad du vill göra är alltså att kunna definiera ett uttryck som filtrerar en ström av event för att avgöras om ska släppas igenom eller ej, eller? Varför gör du inte det t.ex. med DI där du stoppar in en closure som när den anropas säger om man är intresserade av händelsen eller ej? Det är långt mer generellt än att bara göra filtrering baserad på typen hos händelsen.

Hopblandning av koncept igen, DirectCompute kan i bästa fall användas för att lösa problem som är dataparallella, ett koncept som i stort sett är ortogonalt mot uppgiftsparallella problem. TPL och fork/join är bara vettiga för det senare.

Har du grundläggande kunskap om Java fork/join och C# TPL kan du väldigt enkelt testa själv och se att det stämmer.

C# PLINQ och Java 8 parallel streams är ett annat sådant exempel där Java demolerar C# i skalbarhet. Enligt Microsoft är det överlägset vanligast användningen av LINQ på formen LINQ-to-objects och i det läget går det logiskt att göra motsvara på mycket snarlikt sätt med Java8 steams. Skillnaden är att de som designade Java8 streams begriper sig på map/reduce och vad som kan göras och inte kan göras om man vill få något som går att skala väl över CPU-kärnor. LINQ är broken-by-design för parallellism då det innehåller konstruktioner som inte kan göras korrekt och effektivt över CPU-kärnor, nämns till och med i dokumentationen att vissa saker måste undvikas om det ska bli någon skalning alls att tala om (ofta svårt att ens få x2 speedup).

Edit: PLINQ och parallell streams har fall som är dataparallella, i Java pågår faktiskt arbete att automatiskt utnyttja SIMD (Intel jobbar på det) och även GPGPU (comunity drivet, antagligen baserat på OpenCL) helt automatiskt på system som har stöd för detta (alla moderna x86 har ju SSE/AVX så SIMD finns ju nästan alltid).

Varför inte ta en titt på Marmalade?

https://www.madewithmarmalade.com/

Då kan du programmera i C++, Javascript eller LUA för de flesta plattformar. Har själv testat att göra spel till Android mha Marmalade.

if(...) {
   if(...) {
   } else if (...) {
      if(..) {
      }
   }
} else {
}

Och du anser att det du skriver som motsvarar

if (setjmp()) {
state#1
longjmp(); }
if (setjmp()) {
state#2
longjmp(); }
}

är bättre?

Nu har jag tidigare jobbat (som konsult) med "enterprisekod" så har ett visst hum om vad du försöker få att låta som det är väldigt stort och komplicerat (och om det kommer till att "pull rank" så är jag rätt säker att min titel är högre än din men sådant är löjligt att använda på ett teknikforum). Är därför jag frågade om vad du klassar som "stor system". Att skriva affärslogik är jämfört med saker som verkligen är "stort och komplicerat" en parkpromenad, är därför du inte skriver antal rader kod, antal utvecklare etc. på 90-talet fyllde VB och ASP samma nisch, VB var på den tiden det språk med flest aktiva programmerare av alla då existerande språk. BASIC kanske inte var väldens bästa språkval, så C# är ett klart lyft. .NET är inget man kan använda att utveckla saker där det som är svårt och komplicerat inte är databasen och webfront-end, utan faktiskt den kod man själv skriver.

Har läst på om IoC och DI, du har missförstått vad detta är eller så får du helt enkelt hävda att Martin Fowler (en av de största auktoriteterna som finns kring OOP och design patterns ) missförstått det. Finns flera andra stackoverflow diskusioner kring detta och i andra pekar man på att det är ett missförstånd att de inte skulle vara samma sak, IoC var ett dåligt namn för folk missförstår vad det är.

För att ta en annan kort beskrivning kring vad DI är

"Dependency Injection" is a 25-dollar term for a 5-cent concept.
...
Dependency injection means giving an object its instance variables. Really. That's it.

Min poäng är att allt du skriver här kring problem med "type erasure" har inget med IoC eller DI, de koncepterna är helt frikopplade från sådana detaljer. Du verkar bara se ett verktyg, C#/OOP, sedan anser du att t.ex. TypeScript/JS inte är lika bra för de har eventuellt problem att lösa något på exakt samma sätt (polymorfism baserad enbart på typ, en parametriserad typ i detta fall). TS/JS har så många fler sätt än det som erbjuder polymorfism, så det går att lösa problemet på andra sätt och med bredare/mer flexibla urvalskriterier för polymorfism går det att göra mer generella lösning (och det är ingen hastighetsoptimering, har mer än ett verktyg i min låda )

Är fullt med på det, men det beror på att en extremt vanlig uppgift är att man skriver relativt lite kod som sitter mellan en webfront-end (som typiskt är utvecklad i C++ av prestandaskäl) och en databas (som av prestandaskäl också är utvecklad i C++), detta körs på ett OS som av flera skäl (bl.a. prestandaskäl) är skrivet i C. Affärslogik är på det stora hela en extremt liten del av all kod som körs och det är sällan man gör en speciellt avancerad transform av data -> det spelar i stort sätt ingen roll (ur prestandahänseende) om det är skrivet i ultraoptimerad C eller i Ruby (som inte är känt för att exekvera snabbt, ändå kör man rätt stora webbplatser på Rails).

Om man däremot utvecklar saker som ska köra inuti en OS-kärna, vara del av virtualiseringsinfrastruktur, utvecklare middleware, något som på något sätt utför en lite mer komplex transform på data eller om man ska hantera väldigt många samtida sessioner så är prestanda (som kan betyda många saker) kritiskt. Och det handlar inte om att knacka "smarta saker" i assembler, prestanda i storskaliga system kommer främst från bra arkitektur och rätt val av algoritmer (ligger man riktigt i framkant kanske man måste forska fram nya algoritmer, något som bl.a. är min arbetsuppgift för tillfället).

Att Java (eller C) är sämre syntaxmässigt än C# är däremot en åsikt som långt ifrån alla delar med dig. I stora projekt med många utvecklare är det en fördel om de som ingår verkligen behärskar språket som används. Som språk börjar C# närma sig C++ i antal språkfinesser, ytterst få behärskar alla saker som finns i dessa språk och den delmängd folk kan överlappar inte alltid. Java är ett betydligt enklare språk och det är rimligt att känna till alla språkliga finesser.

Frågan är hur stora projekt C# används i? Största jag hittat är Roslyn som innehåller ca 1.5M rader C# (och faktiskt ungefär likna mycket VB) vilket inte är speciellt mycket (finns flera Java-projekt på GitHub som är större, C/C++ har kodbaser som närmar sig 100M rader). Projekt som räknas i låga 100k rader kod skulle jag på sin höjd klassa som "medelstora", där behöver man inte alls tänka lite mycket på prestanda i sin arkitektur. En av produkterna jag jobbar som arkitekt har ~400k rader Python (där börjar det bli växtvärk men Python används inte i den kritiska delen utan är del av testsystemet), är nästan 10M rader C med riktigt hårda krav på effektivitet i huvudfunktionen.

Med tanke på att en "user story" rimligen borde ha minst en "task" och en "task" rekommenderas beskriva något som i alla fall tar 4 timmar att utföra handlade det alltså om ett rätt projekt med >2000 manmånaders jobb. Det är rätt stort, begriper inte riktigt vad man hållit på med om inte det skulle ha resulterat i >1M rader kod. Mycket kod är i sig knappast ett misslyckande, om det man ska lösa är fundamentalt svårt och komplext så kommer det bli mycket kod. Moderna OS och moderna webbläsare (som faktiskt nästan kan ses som OS) kliver över 10M rader kod utan att de bryter mot DRY. Själv kan jag definitivt inte bryta mot det då min "bibel" säger

"DRY—Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Starcounter verkar om man tittar på patentet bygga på minnesmappad I/O. Även om det finns grundläggande stöd för detta sedan .NET4.0 så räcker det inte alls till för vad man gör här. I deras whitepaper nämns en "C runtime" och vet inte riktigt hur denna kodbas relaterar till det projektet.

Men givet antalet buggar jag hittar i den här filen
https://github.com/Starcounter/Starcounter/blob/develop/src/C...
under de första sekunderna jag läser "push_front()" så skulle jag inte lita på någon data som finns i den databasen... Uppenbarligen har den som skrivit filen hört talas om minneskonsistensmodeller då denne inser att x86 är har en väldigt "strikt" sådan, men det är totalt fel även på x86.

En korrekt implementation behöver 2 "pekare" (kan vara räknare som i denna impl) för consumer och 2 för producer. Den ena är utrymmet den som har för avsikt att läsa/skriva lyckats reserverat, den andra är för producer det data som är redo att konsumeras och för consumer det utrymme man kan (åter)använda. Reseverationen måste göras med en atomär läs nuvarande-värde-om-det-är-det-förväntande-byt-det-till-nytt, d.v.s. en CAS (Compare And Swap). Explicita minnesbarriärer behövs i princip aldrig på x86, sfence/lfence behövs bara om man jobbar med s.k. Non-Temporal SSE/AVX instruktioner (där är ett fel i filen ovan men långt ifrån det enda).