Interessant utveckling kring Java8 streams

I teorin är async/await ett väldigt välkommet tillägg då det möjliggör programmering på ett sätt som liknar Go/Erlang, det sättet är väldigt trevligt när man jobbar med system som utför väldigt mycket samtidig I/O men det man kör mellan operationerna inte drar supermycket CPU-kraft. Har själv lagt väldigt mycket kraft på att fundera på hur man kan få Go/Erlang modellen i C, men det är bara att konstatera att sättet Go/Erlang i sina definitioner beskriver hur anropsstacken ska hanteras är ett hårt krav för att det ska fungera bra.

Var därför väldigt förvånad när C# fick async/await för precis som C (och Java, C++, Pythot m.fl) saknar alla dessa "rätt" hantering av anropsstacken. Visar sig också att async/await har effektivitetsproblem just p.g.a. sättet man måste implementera det, så rekommendationen är att inte använda denna finess för högprestanda-servers.

Problemet kokar till stor del ner till detta:
"For asynchronous methods that actually yield execution (due to awaiting an object that’s not yet completed), the asynchronous method infrastructure needs to allocate a Task object to return from the method, as that Task serves as a unique reference for this particular invocation."
länk
Använder man detta i UI-sammanhang kommer ofta data finnas tillgängligt och man undviker denna kostnad, handlar det om I/O mot nätverk, filsystem, databaser etc så är en CPU så pass snabb att man i princip aldrig kommer ha data tillgängligt och därför måste ta de kostnader (som inte existerar i Erlang/Go) som beskrivs under "Know When Not to Use Async".

Java har överhuvudtaget ingen motsvarighet sett till koddesign, men funktionellt skulle man använda en kombination av "executors" och "NIO". Inte lika enkelt som Go/Erlang men resultat presterar lika bra.

Minst två väldigt viktiga saker saknas:

• Moderna JVMer erbjuder sedan Java7 en långt mycket effektivare runtime-plattform än vad .NET har, framförallt kring multicore. Det spelar ingen roll om man utvecklar något som ska köras på en eller några få servers och den prestandakritiska biten inte ligger i den kod man själv skriver (väldigt vanligt i praktiken när det är en relationsdatabas med i mixen). Det är absolut kritiskt för program som ska köras på mindre enheter (Java ser ut att bli väldigt populärt inom IoT) eller när man kör i molnet där man i praktiken betalar i proportion mot använd CPU-tid. När programmet ska köras på många enheter så betyder mer effektivt program potential till billigare HW -> blir mycket pengar när det är många enheter. Omvänt så är inte utvecklingskostnaden alls lika viktig när den sätts i relation till kostnad per enhet.

• Det absolut vanligaste användningsområdet för LINQ är LINQ-to-objects. Java8 streams och LINQ har en del fundamentala skillnader, i det specifika fallet LINQ-on-objects så är streams LINQ-done-right. Båda är i grunden rotade i den funktionella världen, inte så förvånande i fallet LINQs då en av dess skapare Eric Meijer jobbat väldigt mycket med funktionell programmering. Men de är rotade ur olika delar, streams är typisk map/reduce vilket är förklaringen till varför det fungerar så väl i parallella-system, även GPUer som inte nödvändigtvis ens är cache-koherenta. LINQ kommer i stället från konceptet monad funktioner (vilket möjliggör saker som JOIN, något som är väldigt icke-funktionellt). PLINQ är inte i närheten lika effektiv som parallel-streams och givet utgångspunkten de designat med borde det inte förvåna någon.

Då du kan både Java och C#, nämn en enda sak du kan göra med LINQ-to-objects som inte går att göra med ungefär samma arbetsinsats med Java-streams. Jämför sedan effektiviteten på din lösning, redan på en CPU-kärna är Java klart bättre, på multicore är den överlägsen.

Finns helt klart trevliga saker, men om det bara handlar om finesser och hur kort man kan skriva något skulle alla gått till Scala. Språk som Java och C är inte populära trots att de saknar mer avancerade språkkonstruktioner, de är populära p.g.a. detta.
Prio#1 för .NET borde vara att jobba på runtime-plattformen, framförallt om molnet eller IoT blir i närheten så stort som spås.

Tänk igen. Ihop med Javas inriktning mot effektiv parallellism och därmed mer funktionell modell enligt map/reduce så vore det fel väg att möjliggöra att returvärden också kan skickas via argument, för vilken annan vettig användning finns för pass by ref?

Varför irriterar du dig i så fall inte på att "extension methods" i C# inte har "dymanisk-dispatch", gillar man OOP borde det vara en riktig WTF! I Java diskuterande man väldigt läge att göra något liknande men alla förslag som hade "static-dispatch" som C# extension methods röstades ner då det finns en rad sätt att skjuta sig i fötterna. I Java8 kom till slut defender/default methods.

För att gå tillbaka till topic: det är definitivt stort om en så populär plattform som Java på ett vettigt sett man börja använda GPGPU (SIMD kan ses som ett specialfall av detta, vilket är precis vad t.ex. OpenCL gör). Utan något som är så pass enkelt lär det nog aldrig bli något en en relativt smal nisch.

Finns väldigt många anledningar varför man väljer ett visst språk/plattform, en av de absolut vanligaste är att det man jobbar på är en utökning av något existerande och då är valet av språk/plattform redan gjort.

Helt klart finns det saker C och C++ är effektivare på och det har med CPU-cache att göra, ser däremot inte hur din illustration visar detta. Orsaken stavas främst "prefetch". I Java (och typ alla språk som använder sig av någon form av automatik GC) så representeras en array av objekt på detta sätt med C++ syntax (använder Javas "ordinary object pointer" klass som exempel)

vector<oop> arrary_of_some_ref_type;

D.v.s. minnet för objekten ligger inte direkt i C++ vector, där ligger pekare till objekten. För alla enklare formare av prefetcher kommer dessa inte lyckas att lura ut vilket minne som bör prefetchas, utrymmet där pekare ligger kommer effektivt prefetchas av den enklaste implementation. Inte ens de mest avancerade implementationer kommer gissa rätt på objekten om de inte råkar ligga "på rad" i minnet i samma ordning som deras pekare ligger.

Läser man spelbloggar och liknande hittar man kommenterar kring hur viktigt det är att tänka på sin minneslayout, vector<T> kan i prestanda kritiska situationer vara väldigt mycket snabbare än vector<T*> och i dessa situationer kan inte GC-språk som Java matcha språk med möjlighet till explicit minneshantering (C++11 har redan i standarden stöd för automatisk minneshantering, bygger på referensräkning men ger samma effekt i "collections").

Vill man vara säker på att ett program fungerar på alla x86_64 plattformar går det bara att använda SSE2, finns sätt runt detta genom att dynamisk lära sig vad som finns och ha flera olika implementationer. Men det ökar komplexiteten och därmed kostnaden, för GPGPU kommer den matrisen rätt snabbt bli ohållbar. Med JIT behöver utvecklaren inte tänka på denna komplexitet, det gör i stället plattformen. Det kommer inte ge riktigt samma effekt men det är väldigt mycket enklare och därmed långt sannolikare att det faktiskt används i praktiken.

Det skrivet, för det tråden handlar om är det totalt irrelevant.

Java8 streams handlar främst om detta:
"Second, how can we process really large collections efficiently? Ideally, to speed up the processing, you want to leverage multicore architectures. However, writing parallel code is hard and error-prone."

Skulle man göra ett liknande ramverk i C++ skulle jag gissa att det skulle vara något snabbare (dock mindre en en faktor 2) än Java-versionen. Språk med s.k. "tracing GC" (Java och C# har båda en sådan, referensräkning är inte en sådan) möjliggör användning av vissa klasser av datatyper som skalar extremt effektivt över CPU-kärnor, ett exempel är persistent data structure. Det är tekniskt möjligt att använda dessa typer av datastrukturer i språk utan "tracing GC", men det finns (än så länge i alla fall) inget sätt som inte leder till usel skalbarhet över CPU-kärnor vilket tar bort en av huvudpoängerna.

Rent praktiskt är det enklare att använda många CPU-kärnor i en plattform som JVM jämfört med C++. I specifika fall med utvecklare som har extremt detaljkunskap i cache-design och liknande är det ofta möjligt att matcha eller göra snabbare saker i C++. I det generella fallet är det bara att konstatera att språk med "tracing GC" och där runtime-plattformen i övrigt inte sätter käppar i hjulet så kan inte språk som C och C++ matcha skalbarheten över CPU-kärnor.

JVM-baserade språk dominerar totalt de plattformar som finns för "big data", ramverk som Storm och Spark. Sättet kod körs i dessa ramverk kräver intermediär kod likt Java bytekod och som användare kan man inte göra antagande om underliggande HW. Att då "automatiskt" kunna dra nytta av GPGPU och SIMD där det finns är ju guld värt.