Multi core

Fastflow – Programmare i multicore

Il mondo dell’hardware ha da anni intrapreso la strada delle piattaforme parallele. Queste piattaforme sono diffuse principalmente sotto forma di
  • processori multicore
  • GPU General Purpose (GPGPU)
  • strutture lato server, eventualmente realizzate con tecnologie cloud

Le cpu multicore offrono una potenza notevole rispetto alle cpu single core e grazie al parallelismo sui task (più processi in esecuzione contemporaneamente) sono in grado di produrre un miglioramento prestazionale visibile anche a livello di utenza generica, per esempio nell’uso di sistemi operativi ed applicativi desktop.

Sfortunatamente per il programmatore però i singoli programmi non sono automaticamente in grado di sfruttare al meglio tali architetture e quindi il famoso “more core – do more” è solo in parte vero. Non è infatti detto che un generico programma (es. compressore di file tipo WinZip) sia capace di sfruttare i core di un processore. Per esempio il programma in questione potrebbe essere strutturato come un’insieme di thread tra loro cooperanti capaci di “sminuzzare” il calcolo in più parti tra loro eventualmente interdipendenti; poi sarebbe necessario allocare ogni thread su un core del processore (in modo statico o dinamico). Questo è indubbiamente il metodo usato per realizzare applicazioni moderne, ma  programmare esplicitamente un software del genere prevede di cimentarsi con una serie di problematiche che possono rendere il processo particolarmente lungo, esposto alla possibilità d’errore e in ultimo costoso.

Ovviamente esistono degli strumenti automatici capaci di fare parte del lavoro per noi, ma non sempre questi strumenti, pur introducendo molte ottimizzazioni, sono così furbi da riuscire a trasformare un algoritmo sequenziale in uno parallelo. Spesso è necessario quindi approcciare il problema da risolvere in modo alternativo per renderle capaci di sfruttare al meglio le potenti risorse oggi presenti in processori anche di fascia “a basso consumo”, come per esempio le architetture ARM multicore.
Fastflow
Grazie a FastFlow e alle tecniche di programmazione parallela strutturata possiamo scatenare la potenza dei nostri processori senza doverci preoccupare degli aspetti tecnici di più basso livello, permettendoci di concentrarci invece sugli aspetti centrali dell’applicazione. FastFlow permette quindi di realizzare applicazioni multicore usando un approccio strutturato, che favorisce il porting di applicazioni legacy, e capace inoltre di semplificare la stesura di codice manutenibile.

In particolare Fastflow si propone di

  1. Promuovere un modello di programmazione parallela strutturata che sia indipendente dalla piattaforma target
  2. Supportare lo sviluppo di applicazioni efficienti e portabili per piattaforme omogenee ed eterogenee, includendo multicore, many-core (es. GPGPU e FPGA) e cluster distribuiti costruiti su queste tecnologie

Questi obiettivi sono ottenuti astraendo i modelli di programmazioni basati sul concetto di memoria condivisa, a passaggio di messaggi e SIMT (Single Instruction Multiple Threads).

 

Struttura di Fastflow
Fastflow è concettualmente suddiviso in livelli. Tali livelli sono impilati l’uno sull’altro e hanno lo scopo di astrarre le funzionalità sottostanti fornendo quindi strumenti di alto livello per l’implementazione delle applicazioni.
L’architettura di Fastflow è organizzata in tre livelli principali
  1. High-level patterns
    Questi sono chiaramente caratterizzati dallo specifico contesto applicativo e sono indirizzati alla parallelizzazione di codice sequenziale legacy. Esempi d’uso di questi costrutti sono lo sfruttamento di cicli paralleli, parallelismo su flusso, algoritmi data-parallel, etc. Questi sono generalmente dotati della capacità di essere auto-ottimizzanti e soffrono di alcuni limiti sulle loro possibilità di composizione ed annidamento. Questi pattern sono costruiti usando le funzionalità del livello dei

    Fastflow architecture
    Struttura di Fastflow

    Core patterns

  2. Core patterns
    Questi pattern forniscono un modello generico e data-centrico di programmazione parallela. Il supporto a run-time del modello di programmazione è inoltre fornito ed è progettato per essere minimale e limitare al minimo l’overhead indotto dall’adozione di tecniche di programmazione parallela. A questo livello sono disponibili due paradigmi (farm e pipeline) la cui semantica può essere modificata usando il modificatore feedback. Questi due costrutti possono essere usati per realizzare processi ciclici organizzati in reti di esecutori paralleli (processi o threads). I task oppure elementi da processare fluiscono attraverso gli esecutori. Questi costrutti sono implementati sul livello Building blocks
  3. Building blocks
    Questo livello contiene i blocchi base usati per costruire (e generare, tramite templates C++ header-only) il supporto a tempo di esecuzione dei core patterns. Oggetti tipici a questo livello sono code, container di processi e threads, scheduler e gatherer. Il supporto a tempo di esecuzione per la memoria condivisa usa in modo esteso algoritmi lock e fence-free, il supporto in ambiente distribuito impiega scambio di messaggi zero-copy, il supporto GPGPU sfrutta invece l’asincronia e algoritmi ottimizzati per il paradigma SIMT.

I livelli descritti sono puramente concettuali, le funzionalità dei livelli sono compilate staticamente ed ottimizzate nel codice binario tramite tecniche di programmazione generativa (es. uso di template C++ inline)

 

 Riferimenti
  1. http://calvados.di.unipi.it/dokuwiki/doku.php/ffnamespace:architecture
  2. https://en.wikipedia.org/wiki/Algorithmic_skeleton#FastFlow

 

bbva-open4u-api-first

API First – Il potere delle API

Il potere delle API

Negli ultimi anni lo sviluppo di servizi web disponibili tramite API ha generato una vera e propria economia di prodotti derivati costruiti usando i servizi altrui come mattoncini base. Il paradigma di strutturare un’applicazione introducendo un livello di funzioni consistente da semplice soluzione tecnica è diventato un vero e proprio canale di vendita alternativo per i propri servizi.

Pensandoci bene molte applicazioni web, anche di nicchia, possono trarre enormi benefici dall’esposizione dei propri servizi a terzi. Questo permette infatti ad altri programmatori di creare i cosiddetti “mashup”, siti e app derivate che nel tempo possono portare una fetta considerevole di ricavi ai fornitori di servizi primari.

Per favorire la diffusione della propria API è necessario considerare gli sviluppatori come un segmento di mercato importante. Ha senso quindi parlare di progettazione API-first come un’insieme di tecniche ed azioni volte a rendere i propri servizi disponibili ai programmatori di applicazioni, tenendo in conto dei loro bisogni in termini di usabilità, stabilità e documentazione.

Questo approccio svincola l’API dal suo contesto tecnico (es. soluzione architetturale per risolvere un problema specifico) facendola diventare uno strumento importante per diffondere l’uso del proprio servizio ed accrescere la propria presenza sul mercato.

API-first, i primi passi

Si parla spesso di Esperienza Utente (UX – User eXperience) in riferimento alle caratteristiche che ha un prodotto di essere acceduto dagli utenti, nel caso di un’API ha senso quindi parlare di Esperienza Sviluppatore (DE – Developer eXperience). Ottenere una buona developer experience è fondamentale per garantire il successo della propria API presso il segmento di riferimento, ovvero gli sviluppatori.

Una api a questo punto può essere vista come un prodotto software qualsiasi, deve essere ben progettata, possibilmente andando incontro a standard (anche “de facto”) già consolidati nel particolare settore operativo, deve possedere una documentazione chiara e supportata da esempi, deve essere sviluppata tenendo presente obiettivi di qualità e quindi includere nel processo di sviluppo meccanismi di testing adeguati.

Per ottenere successo nell’arena delle API è bene tenere presente alcuni obiettivi di natura generale:

  • Time-to-market rapido
    Meglio essere presenti rapidamente sul mercato con un prodotto semplice ma efficace che arrivare tardi con un prodotto completo ma complesso
  • Allettare gli sviluppatori
    Sempre più spesso sono gli sviluppatori interni ad una azienda che hanno il potere decisionale su quale tecnologia andare ad usare come fondamenta per i prodotti aziendali. E’ quindi necessario non sottovalutare la Developer Experience
  • Tecnologia e metodologie di sviluppo agili
    Le soluzioni complesse spesso sono potenti e sono in passato state usate da grossi “early adopters”. In particolare le tecnologie SOAP e WSDL conoscono tutt’oggi larga applicazione in settori enterprise, anche se molte nuove grandi realtà si sono spostate su paradigmi molto più semplicemente comprensibili ed implementabili, mantenendo un approccio “agile” allo sviluppo prevedendo quindi rilasci rapidi e frequenti con una forte componente di “design for change”

 

Metodologia di sviluppo

La metodologia di sviluppo orientata alle API è ovviamente una reinterpretazione specializzata di tecniche di ingegneria del software consolidate. Per semplicità possiamo prevedere le fasi seguenti

  • Pianificazione
    Avere le idee chiare sul servizio e le sue caratteristiche nodali è sempre un’ ottimo punto di partenza
  • Progettazione
    Cominciare a elencare i dettagli dell’oggetto per capirne la fattibilità, simularne l’utilizzo e evidenziare i principali flussi di lavoro
  • Congelamento dei requisiti
    Una volta identificate le funzionalità principali, si procede alla formalizzazione della API anche mediante l’impiego di strumenti semi-automatici (RAML, Swagger) capaci di fornire una rappresentazione formale delle funzionalità a supporto delle successive fasi di produzione del codice e di documentazione
  • Controllo di consistenza
    A questo punto è necessario controllare la consistenza della API rispetto ai casi d’uso evidenziati fino ad ora, appianando eventuali discrepanze tra le funzionalità (es. segnature ed arietà delle funzioni) contribuendo a migliorare l’esperienza d’uso dello sviluppatore. In questa fase è inoltre possibile realizzare i test automatizzati delle varie funzionalità esposte dalla API
  • Implementazione
    Grazie alle precedenti fasi si hanno adesso tutti gli elementi necessari per permettere una implementazione agevole delle componenti del nostro sistema. Il lato server può essere realizzato anche inizialmente mediante l’uso di funzioni abbozzate che siano compatibili a livello di invocazione ed output con le specifiche, ma la cui logica interna sia ancora in divenire (stub). Il lato client può essere sviluppato in parallelo sulle varie architetture target poichè l’unico punto di interazione tra il sistema ed il cliente è la API stessa, di cui disponiamo tutti i dettagli

 

Questi passi possono essere ripetuti in più iterazioni volte a raffinare il prodotto dopo aver tratto gli insegnamenti di ritorno dalla comunità di utenti.

single-rose-petal-in-focus-f5

Single page applications

Applicazioni a pagina singola - Single Page Applications (SPA)

Le Single Page Applications (o brevemente SPA) non sono certo una novità nel campo delle applicazioni per il web. Molti programmatori hanno iniziato a strutturare le loro applicazioni web in questo modo non appena il supporto dei browser ha raggiunto il livello minimo necessario. Alcune applicazioni web (gmail in primis) hanno da sempre tentato di offrire un look-and-feel da applicazione desktop sfruttando al massimo le capacità dei browser moderni, usando approcci ad-hoc e -considerando i tempi- pionieristici. Oggi la tecnica e gli strumenti per realizzare questo tipo di applicazioni hanno raggiunto una certa maturità, rendendo questo approccio interessante ed applicabile anche in altri contesti.

Cos'è una SPA?
No, non si tratta di terme, ma di un tipo di applicazioni web. La loro particolarità risiede nel fatto che il codice lato client viene caricato nel browser tutto all'interno di un singolo "page load". Dopo questo primo caricamento le successive richieste vengono effettuate in modo asincrono senza necessità di ricaricare la pagina nel suo complesso. Questa caratteristica migliora notevolmente la user experience evitando all'utente gli spiacevoli momenti di "bianco" che esistono tra il caricamento di una pagina e l'altra. L'aspetto del rendering delle pagine web viene demandato a Javascript e a quell'insieme di tecnologie che oggi sono comunemente note come Html5.

Vantaggi

In breve ecco i vantaggi che è possibile ottenere con una SPA

  • Compatibilità dell'applicazione su dispositivi portatili (smartphone e tablet) e desktop
  • Elevata user experience, interattività e reattività migliorata
  • Distribuzione dell'applicazione sugli store delle varie piattaforme mobile (apple, android)
  • Perfetta integrazione con API di terze parti
  • Possibilità di introdurre modalità di lavoro offline