Debuggare pagine PHP con Notepad
1)scaricare plugin
Scaricare il plugin DBGpPlugin_0_12b_dll.zip o versioni equivalenti.
Una volta scaricato ed installato il plugin per l'editor (cosa che consiste nel copiare la dll contenuta nel pacchetto zip del plugin, nella cartella "plugins" nel percorso di installazione del Notepad++), siamo pronti ad attrezzare la nostra installazione di PHP dei moduli necessari per il debug.
2) installare Xdebug
Il modulo in questione è il modulo XDebug. Anche in questo caso l'installazione risulta poco complessa. L'unica particolarità risiede nel fatto che si deve installare la versione del debugger compilata ad-hoc per la versione di PHP presente sul sistema per il debug.
Una volta scaricato il modulo corrispondente alla nostra versione del PHP, lo si può copiare nella cartella ext di PHP o direttamente sotto la radice di PHP stesso.
Per permettere la gestione del modulo da parte di PHP è necessario aprire il file PHP.ini presente nella cartella di installazione del PHP e aggiungere le seguenti righe di configurazione:
#zend_extension_ts="Drive:/percorso/verso/il/modulo/xdebug/php_xdebug-2.0.5-5.2.dll"
zend_extension="C:\xampp\php\ext\php_xdebug.dll"
xdebug.profiler_append=1
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=0
xdebug.profiler_output_dir=
xdebug.profiler_output_name=cachegrind.out
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.trace_output_dir="C:\xampp\tmp"
zend_extension_ts=C:\xampp\php\ext\php_xdebug.dll
xdebug.default_enable=On
xdebug.remote_log=
xdebug.remote_mode=req
xdebug.idekey=devphp
3) verificare php
A questo punto, se abbiamo scelto il modulo giusto per la nostra versione di PHP, il debugger dobrebbe essere integrato. Si può verificare l'installazione del modulo controllando l'output della funzione phpinfo() che dovrebbe riportare una sezione relativa a xdebug.
4)eseguire
A questo punto dovrebbero sussistere tutti i presupposti per poter eseguire il debug degli script PHP.
Aprire quindi con il notepad++ il file all'interno dello spazio web gestito da Apache che vogliamo debuggare e attivare il plugin del debugger selezionandolo dall'apposito menu (plugins -> DBGp -> Debugger).
Portandoci su una riga di codice PHP, possiamo inserirvi un breakpoint, clickando sul pallino rosso, in modo che l'esecuzione dello script si fermi su quella linea.
Per lanciare l'esecuzione dello script, aprire un browser internet e digitare il percorso della pagina da debuggare sul server locale.
In fondo al percorso alla pagina all'interno del browser web, dobbiamo aggiungere un parametro get che permetta la definizione del nome di una sessione di debug.
Ecco un esempio di percorso alla pagina da debuggare con la formattazione necessaria:
http://localhost/pagDaDebuggare.php?XDEBUG_SESSION_START=NomeSessione
Il nome della sessione può essere del tutto arbitrario. A questo punto dovrebbe iniziare a lampeggiare l'applicazione del Notepadd++ nella barra di sistema, a segnalare che il debug dello script è stato avviato.
5)Watchs
Clikare su watchs ->tasto dx mouse -> add watch -> inserire nome variabile
lunedì 28 febbraio 2011
sabato 26 febbraio 2011
problemi di concorrenza
Strumenti e tecniche per identificare i problemi di concorrenza
Rahul V. Patil e Boby George
In questo articolo verranno discussi i seguenti argomenti:
| In questo articolo verranno utilizzate le seguenti tecnologie: Analisi dinamica, analisi statica e controllo del modello |
Sommario Per soddisfare l'eterna esigenza di aumentare la potenza di calcolo, il settore dell'hardware si sta costantemente muovendo verso sistemi di processori multicore. Al contrario del miglioramento delle prestazioni ottenuto grazie a processori più veloci con velocità di clock più elevate, il miglioramento delle prestazioni in sistemi multicore può essere ottenuto solo scrivendo programmi paralleli efficienti.
Da molto tempo nel settore del software esistono forme di parallelismo. Tuttavia, per creare applicazioni software tradizionali che utilizzino la piena potenza dell'hardware parallelo, è necessario modificare in modo sostanziale le pratiche pensate per le applicazioni sequenziali.
Il test delle applicazioni parallele non è semplice. Ad esempio, è difficile rilevare bug di concorrenza a causa del comportamento non deterministico mostrato dalle applicazioni parallele. Anche se si riesce a rilevare questi bug, è difficile riprodurli in modo coerente. Inoltre, dopo aver corretto un difetto, è difficile essere certi che quel difetto è stato veramente risolto e non semplicemente mascherato. La parallelizzazione può anche comportare nuovi colli di bottiglia delle prestazioni che devono essere identificati.
In questo articolo, esaminerò le tecniche di test per i programmi paralleli e presenterò sei utili strumenti che possono essere usati per individuare difetti potenzialmente gravi. Inizierò definendo le seguenti categorie di bug di concorrenza: condizioni di competizione, esclusioni reciproche errate e riordino della memoria.
Condizioni di competizione, deadlock e altro
Una condizione di competizione si verifica quando due o più thread di esecuzione di un programma multithread tentano di accedere agli stessi dati condivisi e almeno uno degli accessi è in scrittura. Condizioni di competizione dannose comportano imprevedibilità e sono spesso difficile da rilevare. Le conseguenze di una condizione di competizione possono diventare visibili solo molto tempo dopo o in una parte completamente diversa del programma. Sono anche difficilissime da riprodurre. È possibile evitare le competizioni usando tecniche di sincronizzazione per mettere correttamente in sequenza le operazioni tra i thread.
Talvolta le competizioni possono essere sicure e intenzionali. Ad esempio, può esserci un flag globale chiamato done, per il quale esiste solo un thread scrittore ma molti thread lettori. Il thread scrittore imposta il flag in modo da indicare a tutti i thread di terminare in modo sicuro. Tutti i thread lettori possono essere eseguiti in un loop utilizzando while (!done), leggendo ripetutamente il flag. Dopo che un thread ha rilevato l'impostazione del flag done, esce dal proprio loop while. In molti casi si tratta di una competizione favorevole. Come vedremo più avanti in questo articolo, sono disponibili degli strumenti per il rilevamento delle condizioni di competizione. Tuttavia tali strumenti potrebbero segnalare competizioni che in realtà sono favorevoli, riportando errori conosciuti come falsi positivi.
Un deadlock si verifica quando due o più thread sono in attesa l'uno dell'altro, dando vita a un ciclo e impedendo a tutti loro di fare ulteriori progressi. I deadlock possono essere introdotti dal programmatore nel tentativo di evitare condizioni di competizione. Ad esempio, l'uso errato di primitivi di sincronizzazione, come l'acquisizione di blocchi in un ordine sbagliato, può comportare l'attesa reciproca di due o più thread. I deadlock possono verificarsi anche nei casi in cui non si usano costrutti di blocco; qualsiasi tipo di attesa circolare può risolversi in un deadlock.
Esaminiamo l'esempio seguente di una potenziale situazione di deadlock. Il thread 1 effettua quanto segue:
Acquire Lock A;
Acquire Lock B;
Release Lock B;
Release Lock A;
Thread 2 proceeds like so:
Acquire Lock B;
Acquire Lock A; // if thread 1 has already acquired lock
// A and waiting to acquire lock B, then
// this is a deadlock
Release Lock A;
Release Lock B;Per starvation, o inedia, si intende un ritardo indefinito o un blocco permanente di uno o più thread eseguibili in un'applicazione multithread. I thread la cui esecuzione non è pianificata, sebbene non stiano bloccando o aspettando nulla, vengono detti in condizione di starvation. La condizione di starvation è generalmente il risultato di regole e criteri di pianificazione. Ad esempio, se si pianifica un thread ad alta priorità, non bloccante e continuamente in esecuzione insieme a un thread a bassa priorità, in una CPU a singolo core, il thread a bassa priorità non avrà mai la possibilità di essere eseguito. Per evitare tali condizioni, l'utilità di pianificazione di Windows® interviene frequentemente per ridurre la starvation, aumentando occasionalmente le priorità dei thread in starvation.
I livelock, attese indefinite, si verificano quando i thread sono pianificati ma non stanno facendo progressi perché stanno reagendo continuamente al cambiamento di stato di ognuno di loro. Il modo migliore per descrivere questa condizione è con questo esempio: due persone che si avvicinano in un corridoio stretto e ognuna si fa da parte per far passare l'altra, bloccandosi reciprocamente la strada. Questo farsi da parte impedisce l'avanzamento e comporta un livelock. Un elevato utilizzo di CPU senza alcun sintomo di un lavoro realmente in corso è il classico segnale di un livelock. I livelock sono difficilissimi da rilevare e diagnosticare.
Problemi di riordino della memoria
Quando il compilatore ottimizza il codice, può decidere di riordinare parti di codice per migliorare le prestazioni. Tuttavia può generare un comportamento imprevisto nei thread che tengono sotto controllo le modifiche allo stato globale. Ad esempio, supponiamo di avere due thread di esecuzione: il thread 1 e il thread 2. Supponiamo anche di avere due variabili globali, x e y, inizializzate entrambe su 0. Il thread 1 esegue queste righe:
x=10; y=5;
Il thread 2 esegue queste righe:
if (y == 5)
{
Assert(x != 10);
}In questo caso il compilatore di ottimizzazione potrebbe osservare che, alla fine, a y verrà riassegnato comunque il valore 5 e potrebbe riordinare il codice in modo che a y venga assegnato 5 prima che a x venga assegnato 10; dal punto di vista del singolo thread che esegue queste due assegnazioni, l'ordinamento è ininfluente. Pertanto c'è una possibilità che l'asserzione del thread 2 non valga più, dato che x potrebbe non essere uguale a 10.
Se necessario, è possibile evitare il riordino della memoria da parte del compilatore usando variabili volatili ed elementi intrinseci del compilatore. È importante accennare anche al fatto che, con comuni flag di ottimizzazione attivati, il thread 2 potrebbe non vedere mai un aggiornamento alle variabili y o x. In questo caso sarà necessario usare variabili volatili.
Il riordino da parte del compilatore non è l'unica complicazione. Con le ottimizzazioni dell'accesso alla memoria, come il caching e il recupero avanzato per mezzo di esecuzioni speculative, può succedere che le operazioni di memoria eseguite da un thread in una CPU vengano percepite come eseguite in un ordine diverso da un altro thread su un'altra CPU. Questo tipo di percezione di riordino della memoria può verificarsi solo in un sistema con più CPU o CPU multicore.
Per chiarire supponiamo di avere due thread di esecuzione: il thread 1 e il thread 2. Quindi supponiamo che m e n siano variabili globali inizializzate entrambe su 0 e che a, b, c, d siano variabili locali. Il thread 1 (nel processore 1) ha queste istruzioni:
m = 5; // A1 int a = m; // A2 int b = n; // A3
Il thread 2 (nel processore 2) ha queste istruzioni:
n = 5; //A4 int c = n; //A5 int d = m; //A6
Per logica, in un ambito di memoria coerente e sequenziale, dopo l'esecuzione di tutte queste istruzioni, non può mai verificarsi b == d == 0. Tuttavia, con il riordino della memoria hardware, le scritture nella memoria condivisa (A1 e A4) possono essere indirizzate al buffer di archiviazione, di conseguenza diversi processori possono osservare le scritture in modo diverso.
Strategie di test
Il test di un'applicazione concorrente implica le verifica della correttezza, dell'affidabilità, delle prestazioni e della scalabilità. La correttezza dell'applicazione viene determinata usando tecniche quali l'analisi statica, l'analisi dinamica e il controllo del modello. Le prestazioni e l'affidabilità vengono controllate per mezzo dello studio degli overhead introdotti dal parallelismo e il test di stress. La scalabilità viene controllata analizzando le prestazioni dell'applicazione in sistemi di diversa grandezza.
Le tecniche di analisi statica analizzano il codice senza eseguire effettivamente il programma. Di solito, l'analisi statica viene eseguita esaminando i metadati di un'applicazione compilata o il codice sorgente con annotazioni. L'analisi include in genere un'ispezione formale per garantire che l'intento e i presupposti del programmatore impediscano un comportamento errato. I due strumenti di analisi statica per le applicazioni native più famosi sono Prefix e Prefast mentre FxCop è molto usato per il codice gestito.
L'analisi statica presenta vantaggi e svantaggi. Tra i vantaggi vi sono la copertura completa e dettagliata, la garanzia dell'affidabilità del progetto del codice e la precisione dei report sugli errori che facilitano l'individuazione e la correzione dei bug. Tuttavia, per gestire i bug di concorrenza, l'analisi statica richiede un grosso impegno di annotazione. Inoltre, queste annotazioni devono essere corrette da sole. Gli strumenti che usano l'analisi statica tendono anche a generare molti falsi positivi e quindi richiedono un notevole impegno per ridurli al minimo.
Nell'analisi dinamica i bug vengono rilevati dall'esame dei footprint di esecuzione. Esistono due tipi di analisi dinamica: online e offline. Gli strumenti che usano l'analisi dinamica online analizzano un programma mentre è in esecuzione; gli strumenti che usano l'analisi dinamica offline registrano le tracce e le analizzano in un secondo momento per rilevare i bug. L'analisi dinamica è uno strumento utile in quanto richiede un lavoro minimo, se non nessuno, allo sviluppatore al momento della programmazione, genera un numero minore di falsi positivi e facilita la soluzione dei problemi più ovvi. Poiché i bug vengono rilevati solo nel percorso di esecuzione, i percorsi attraversati più spesso generano la prima serie di bug. In questo modo è più facile migliorare l'affidabilità.
Ma ci sono anche degli svantaggi. I bug possono essere rilevati solo nel percorso di esecuzione ed è necessario affidarsi ai test case per avere una buona copertura del codice. Infatti alcuni strumenti possono cogliere una competizione solo se questa si verifica in quell'esecuzione. Pertanto, se lo strumento non riporta nessun bug, non si può essere certi che non ve ne siano. Molti strumenti di analisi dinamica si fondano su una sorta di strumentazione che può modificare il comportamento del runtime, il che è un altro svantaggio. A causa della complessità, le prestazioni di questi strumenti tendono a essere molto scarse.
L'ultimo metodo è il controllo del modello: il metodo per verificare la correttezza di un sistema concorrente con stato finito. Consente un ragionamento deduttivo formale. Uno strumento di controllo del modello cerca di simulare condizioni di competizione e deadlock. Utilizzando il controllo del modello, è possibile dimostrare formalmente l'assenza di competizioni e deadlock. Questo metodo garantisce una maggiore affidabilità del progetto e dell'architettura e richiede un numero minimo di driver esterni.
Come altri metodi di test, il controllo del modello presenta alcuni svantaggi. Spesso è molto difficile estrarre automaticamente il modello dal codice (esistono rari casi con uso limitato). Anche l'esecuzione manuale dell'estrazione del modello è piuttosto noiosa. Inoltre richiede una verifica estesa a causa del problema conosciuto come "state space explosion", una condizione in cui il numero potenziale di stati possibili è troppo grande da analizzare. Questa condizione può essere controllata in una certa misura applicando tecniche di riduzione che usano una complicata euristica. Anche l'euristica presenta dei limiti, come il non saper rilevare i bug in applicazioni a esecuzione prolungata.
Infine il controllo del modello richiede una rigorosa pianificazione del progetto e dell'implementazione. Il controllo del modello può dimostrare che il progetto è privo di errori ma non l'implementazione. In pratica, il controllo del modello è utile per piccole e importanti sezioni di un prodotto. Altre tecniche ibride includono la combinazione di analisi dinamica e controllo del modello. Un esempio è dato da CHESS che verrà descritto in breve.
L'algoritmo "lockset", usato in entrambi gli strumenti di analisi statica e dinamica, segnala una competizione potenziale quando due o più thread accedono alla memoria condivisa senza gestire un blocco comune. L'algoritmo indica in sostanza che, per ogni variabile v della memoria condivisa, ogni thread gestirà una serie non vuota di blocchi C(v) durante l'accesso alla variabile. Inizialmente C(v) è l'elenco di tutti i blocchi. Ogni thread gestisce anche due serie di blocchi: locks(t) indica tutti i blocchi gestiti e writeLocks(t) indica tutti i blocchi in scrittura gestiti. Ecco come procede l'algoritmo:
- Per ogni variabile v della memoria condivisa gestisce una serie C(v) di blocchi. Inizialmente C(v) è l'elenco di tutti i blocchi.
- Ogni thread gestisce anche due serie di blocchi: locks(t) indica tutti i blocchi gestiti e writeLocks(t) indica tutti i blocchi in scrittura gestiti.
- In ogni lettura di v da parte del thread t:
- Set C(v) = C(v) intersection locks(t).
- If C(v) == NULL set, then raise an error.
- In ogni scrittura di v da parte del thread t:
- Set C(v) = C(v) intersection writeLocks(t).
- If C(v) ==NULL set, then raise an error.
Sostanzialmente, man mano che l'applicazione procede, la serie C(v) di ogni variabile inizia a restringersi. Viene generato un errore se C(v) diventa nullo (ad esempio, se le intersezioni dei lockset dei thread sono nulle al momento di accedere alla memoria condivisa).
Purtroppo non tutte le competizioni segnalate da un algoritmo "lockset" sono competizioni reali. È possibile scrivere codice libero da competizioni senza usare blocchi applicando trucchi intelligenti di programmazione o usando primitivi di sincronizzazione come la segnalazione. Ciò complica notevolmente l'individuazione dei veri bug. Le annotazioni e determinate soppressioni possono aiutare ad alleviare questo problema.
Un altro algoritmo per rilevare le competizioni è "happens-before" che si basa sull'ordinamento parziale degli eventi in sistemi distribuiti. Ecco una panoramica dell'algoritmo che calcola l'ordine parziale per stabilire quali eventi sono successi prima di un altro evento (in questo contesto, per eventi si intendono tutte le istruzioni, comprese quelle di lettura, scrittura e blocchi):
- All'interno di ogni singolo thread, gli eventi vengono ordinati in base al loro verificarsi.
- Tra i thread, gli eventi vengono ordinati in base alle proprietà dei primitivi di sincronizzazione. Ad esempio, se lock(a) viene acquisito da due thread, allora si è verificato uno sblocco da parte di un thread prima del blocco di un altro thread.
- Se due o più thread accedono a una variabile condivisa e gli accessi non sono ordinati in modo deterministico dalla relazione "happens-before", allora si è verificata una competizione.
L'algoritmo è illustrato nella Figura A.
Lo sblocco del thread 1 si è verificato prima del blocco del thread 2. Pertanto, l'accesso alla variabile condivisa non può mai verificarsi allo stesso tempo e non esiste competizione. Uno dei principali svantaggi dell'algoritmo deriva dal fatto che il monitoraggio di tali relazioni può essere molto dispendioso.
Il problema più grande è che la capacità di questo algoritmo di rilevare le competizioni dipende completamente dall'ordine di pianificazione. L'ordine parziale viene creato solo per questa specifica istanza della pianificazione e può non cogliere i bug per lo stesso test in un altro giorno. La Figura B non riporta nessuna competizione mentre un ordine di esecuzione nella Figura C riporta le competizioni. È stato appurato che molte competizioni si sono verificate solo diversi anni dopo il rilascio di un prodotto. Pertanto questo rilevamento non garantisce di avere un'assoluta copertura.
D'altro canto, l'algoritmo "happens-before" genera solo pochi falsi positivi. La maggior parte dei bug sono reali. Tuttavia "happens-before" induce a molti falsi negativi, non rilevando diversi errori, ed è molto difficile da implementare in modo efficiente.
L'algoritmo "lockset", invece, è molto efficiente e può rilevare più errori, sebbene tenda a generare troppi falsi positivi. Si sono fatti molti sforzi per unificare questi algoritmi e superare gli svantaggi di entrambi gli approcci. Nota: questi algoritmi di rilevamento delle competizioni si sono evoluti nel corso di diversi anni; informazioni su di essi sono reperibili nei portali ACM /IEEE.
Figura A Algoritmo Happens-Before (Fare clic sull'immagine per ingrandire la vista)
Figura B Non verranno rilevate competizioni (Fare clic sull'immagine per ingrandire la vista)
Figura C Verranno rilevate competizioni (Fare clic sull'immagine per ingrandire la vista)
Strumenti di test della concorrenza
In commercio sono disponibili diversi strumenti di test della concorrenza, utili per gestire potenziali deadlock, livelock, blocchi e tutti gli altri problemi che possono presentarsi durante l'esecuzione di transazioni parallele. Ogni strumento che esamineremo è utile in una particolare area.
CHESS. Creato da Microsoft Research, CHESS è un'originale combinazione di controllo del modello e di analisi dinamica (vedere go.microsoft.com/fwlink/?LinkId=116523, in inglese). Rileva gli errori di concorrenza esplorando sistematicamente le pianificazioni dei thread e l'interfoliazione. È in grado di trovare condizioni di competizione, deadlock, blocchi, livelock e problemi di danneggiamento dei dati. Per aiutare il debugging, fornisce anche un'esecuzione completamente ripetibile. Come molti controlli del modello, l'esplorazione sistematica fornisce una copertura totale.
In quanto strumento di analisi dinamica, CHESS esegue ripetutamente un normale unit test a determinati intervalli, in base a una speciale pianificazione. A ogni ripetizione, sceglie un ordine di pianificazione diverso. In quanto strumento di controllo del modello, controlla la speciale utilità di pianificazione che è in grado di creare specifiche interfoliazioni di thread. Per controllare il problema "state space explosion", CHESS applica la riduzione dell'ordine parziale e un'originale limitazione del contesto di iterazione.
Nella limitazione del contesto di iterazione, invece di limitare lo "state space explosion" in base alla profondità, CHESS limita il numero di passaggi di thread in una determinata esecuzione. Il thread può eseguire qualsiasi numero di fasi tra un passaggio e l'altro, lasciando la profondità di esecuzione illimitata (un grande successo sul tradizionale controllo del modello). Ciò si basa sulla prova empirica che un numero limitato di passaggi di thread sistematici è sufficiente a mostrare la maggior parte dei bug di concorrenza.
CHESS può rilevare deadlock e competizioni, usando l'algoritmo "Goldilocks lockset" spiegato in go.microsoft.com/fwlink/?LinkId=116877 (in inglese) ma si basa sulle asserzioni del programmatore per la verifica di altri stati. Inoltre prevede la chiusura di tutti i programmi e garantisce l'equità di progresso per tutti i thread. Pertanto, se il programma entra in uno stato di loop continuo, CHESS segnala un livelock.
Dal punto di vista del test, è preferibile iniziare eseguendo CHESS con un limite del contesto di iterazione di 2. Una volta che non ci sono più bug da trovare, aumentare il limite a 3 e così via. È stato dimostrato in modo empirico che la maggior parte dei bug viene rilevata con un limite di 2 e 3. Pertanto si tratta di un modo molto efficiente per eliminare subito i bug.
Per quanto riguarda la strumentazione, CHESS devia le chiamate di sincronizzazione dell'API Win32® da controllare e introduce intenzionalmente il non determinismo. Inoltre richiede che il codice dello sviluppatore includa molte asserzioni per garantire la coerenza degli stati (ciò che ogni buon codice dovrebbe fare comunque). Tuttavia, come la maggior parte degli strumenti di analisi dinamica, richiede una valida suite di test per garantire un'ampia copertura. CHESS costituisce un vantaggio per tutti quegli sviluppatori e collaudatori che devono affidarsi esclusivamente allo stress per eseguire un test interfoliato migliore. Esegue normali unit test e simula metodicamente interessanti interfoliazioni.
Intel Thread Checker. È uno strumento di analisi dinamica per trovare i deadlock (compresi quelli potenziali), gli stalli, le competizioni di dati e gli usi impropri delle API di sincronizzazione native Windows (vedere go.microsoft.com/fwlink/?LinkId=115727, in inglese). Thread Checker deve dotare sia il codice sorgente sia il codice binario compilato degli strumenti necessari a rendere osservabili ogni riferimento alla memoria e ogni primitivo di sincronizzazione Win32 standard. In fase di runtime, il codice binario così attrezzato fornisce informazioni sufficienti affinché l'utilità di analisi costruisca un ordine parziale di esecuzione. Lo strumento quindi esegue un'analisi "happens-before" dell'ordine parziale. Fare riferimento all'intestazione laterale "Algoritmi di rilevamento delle competizioni" per ulteriori informazioni sull'analisi "happens-before".
Per motivi di prestazioni e scalabilità, invece di ricordare tutti gli accessi a una variabile condivisa, lo strumento ricorda solo gli accessi recenti. Ciò aiuta a migliorare l'efficienza dello strumento durante l'analisi di applicazioni a esecuzione prolungata, tuttavia lo strumento non rileverà alcuni bug, un classico compromesso: forse è più importante trovare molti bug in applicazioni a esecuzione prolungata che trovare tutti i bug in un'applicazione di durata molto breve.
L'altro grande svantaggio dello strumento è che non può rendere conto della sincronizzazione tramite operazioni interlock, come quelle usate in blocchi rotanti personalizzati. Tuttavia, per le applicazioni che usano solo primitivi di sincronizzazione standard, si tratta di uno degli strumenti di test meglio supportati a disposizione per le applicazioni native di test della concorrenza.
RacerX. Questo strumento di analisi statica sensibile al flusso è usato per rilevare competizioni e deadlock. Non richiede noiose annotazioni nell'intero codice sorgente. Infatti, l'unico requisito di annotazione è quello per cui gli utenti devono fornire una tabella che specifica le API usate per acquisire e rilasciare i blocchi. È possibile specificare anche gli attributi dei primitivi di blocco, come spinning, blocking e re-entrancy. Questa tabella in genere sarà molto piccola (30 voci al massimo). In questo modo si riduce enormemente l'onere dell'annotazione del codice sorgente per grandi sistemi.
Nella prima fase, RacerX esegue l'iterazione in ogni file del codice sorgente e crea un CFG (Control Flow Graph). Il CFG contiene informazioni relative alle chiamate alle funzioni, alla memoria condivisa, all'uso di puntatori e ad altri dati. Mentre crea il CFG, fa anche riferimento alla tabella dei primitivi di sincronizzazione ed effettua chiamate a queste API.
Una volta creato il CFG, subentra la fase di analisi che include l'esecuzione dello strumento di controllo delle competizioni e dei deadlock. Attraversare il CFG può essere un'operazione lunga ma è possibile usare tecniche appropriate di riduzione e caching per ridurre al minimo l'impatto. Man mano che si attraversa il flusso del contesto, viene usato l'algoritmo "lockset" per rilevare competizioni potenziali (fare riferimento all'intestazione laterale "Algoritmi di rilevamento delle competizioni" per dettagli sull'algoritmo). Per quanto riguarda l'analisi dei deadlock, lo strumento calcola i cicli di blocco ogni volta che viene preso un blocco.
La fase finale riguarda la postelaborazione di tutti gli errori segnalati per stabilire la priorità di importanza e la pericolosità dell'errore. Come per l'analisi statica, gli autori hanno dedicato molto tempo al tentativo di ridurre i falsi positivi e presentare i bug con una notevole sicurezza. I risultati di questo strumento sono stati impressionanti; sembra molto pratico dal punto di vista dell'ingegneria di test.
Chord. È uno strumento di analisi statica per Java, sensibile al contesto e insensibile al flusso. Essendo insensibile al flusso, è molto più scalabile di altri strumenti statici ma a scapito della precisione. Prende anche in considerazione i primitivi di sincronizzazione disponibili in Java. L'algoritmo usato è molto complesso e richiederebbe l'introduzione di molti concetti. Per ulteriori informazioni su Chord, vedere go.microsoft.com/fwlink/?LinkId=116526 (in inglese).
KISS. Sviluppato da Microsoft Research, questo strumento di controllo del modello è valido per i programmi C concorrenti. Poiché in un sistema concorrente si verifica subito un problema "state space explosion", KISS trasforma un programma C concorrente in un programma sequenziale che simula l'esecuzione dell'interfoliazione. Per eseguire l'analisi, viene quindi usato uno strumento di controllo del modello sequenziale.
L'applicazione viene dotata di istruzioni che convertono il programma concorrente in un programma sequenziale e KISS si occupa di controllare il non determinismo. Il passaggio al contesto di non determinismo è limitato da principi simili a quelli descritti sopra per CHESS. Si presuppone che il programmatore introduca asserzioni che convalidano i presupposti di concorrenza. Lo strumento non riporta falsi positivi. Lo strumento è un prototipo di ricerca ed è stato usato dal team dei driver di Windows, che usa principalmente il codice C (vedere go.microsoft.com/fwlink/?LinkId=115723, in inglese).
Zing. Questo strumento è un puro strumento di controllo del modello, pensato per la verifica del progetto di programmi concorrenti. Zing ha un proprio linguaggio personalizzato che è usato per descrivere transizione e stati complessi ed è perfettamente in grado di modellare macchine a stati. Come gli altri strumenti di controllo del modello, Zing fornisce un metodo completo per verificare i progetti; aiuta a garantire la qualità del progetto in quanto è possibile verificare i presupposti e dimostrare formalmente la presenza o l'assenza di determinate condizioni. Affronta anche il problema "state space explosion" con innovative tecniche di riduzione.
Il modello usato da Zing (per controllare la correttezza del programma) deve essere creato manualmente o da convertitori. Mentre è possibile scrivere alcuni convertitori specifici, dobbiamo ancora trovare convertitori completi e funzionanti per le applicazioni native o CLR. Senza convertitori, crediamo che Zing non possa essere usato in grandi progetti software tranne che per la verifica della correttezza di sottosezioni critiche del progetto (vedere go.microsoft.com/fwlink/?LinkId=115725, in inglese).
Test delle prestazioni
Il test delle prestazioni è parte integrante ed essenziale del processo di test della concorrenza. In fondo, uno dei motivi principali per sviluppare applicazioni parallele è offrire prestazioni migliori di quelle delle applicazioni sequenziali. Come postulato nella legge di Amdahl e nella legge di Gustafson, il miglioramento delle prestazioni ottenuto per mezzo di un'applicazione parallela è in gran parte influenzato dalla capacità di parallelizzazione dell'algoritmo, dalla quantità di parti sequenziali nel programma, dall'overhead di parallelizzazione e dalle caratteristiche di dati/carico di lavoro. L'esecuzione di test delle prestazioni consente ai soggetti interessati di capire e analizzare le caratteristiche delle prestazioni delle applicazioni parallele.
La metodologia generale per eseguire test delle prestazioni delle applicazioni parallele resta la stessa del test delle prestazioni delle applicazioni sequenziali. La sezione seguente descrive come alcune fasi essenziali del test delle prestazioni debbano essere adattate alle applicazioni concorrenti. Per una comprensione dei fattori di misurazione più utili, vedere l'intestazione laterale "Identificazione dei dati di test e reporting delle metriche".
La fase più importante del test delle prestazioni consiste nel definire gli obiettivi o lo scopo del test. Per le applicazioni parallele, tra gli obiettivi validi del test vi sono la comprensione della capacità di parallelizzazione/scalabilità dell'algoritmo usato, la comprensione delle caratteristiche delle prestazioni di varie alternative di progettazione, la scoperta degli overhead di comunicazione e sincronizzazione e la convalida che i requisiti delle prestazioni sono stati soddisfatti.
È opportuno notare che gli obiettivi e lo scopo del test delle prestazioni possono variare anche in base a chi conduce il test. Ad esempio, i clienti che implementano un'applicazione parallela potrebbero eseguire test delle prestazioni per assicurarsi che siano soddisfatte le esigenze dell'azienda, mentre il team di sviluppo potrebbe essere interessato a eseguire un test completo delle prestazioni per identificare i colli di bottiglia e migliorare la capacità di parallelizzazione del programma. Inoltre, gli obiettivi del test possono variare nel ciclo di sviluppo del software. Durante la fase di progettazione e implementazione, l'obiettivo del test potrebbe essere comprendere e migliorare le caratteristiche delle prestazioni dell'applicazione, mentre durante le fasi di test e rilascio (fasi di stabilizzazione) l'obiettivo potrebbe essere assicurarsi che le prestazioni non peggiorino durante i build.
La definizione degli scenari del test e la definizione degli obiettivi sono un'altra fase importante nel processo di test delle prestazioni. I team di sviluppo interessati alla comprensione delle caratteristiche delle prestazioni di un'applicazione parallela dovrebbero definire tre tipi di scenari di test: test in scenari dei clienti, test dell'indicatore KPI (Key Performance Indicator) e test dei MBM (Micro BenchMark).
La relazione tra questi tipi diversi di test delle prestazioni può essere considerata equivalente a quella che esiste tra i test di sistema, i test di integrazione e gli unit test. In altre parole, i test di uno scenario dei clienti generano una serie di test KPI e un test KPI genera una serie di test MBM. La comprensione della relazione tra questi tipi diversi di test consente agli sviluppatori di comprendere le relazioni delle prestazioni tra le varie sottoparti di un'applicazione parallela. Acquisire questa comprensione permette anche di definire una migliore priorità dei bug delle prestazioni e, ancora più importante, consente al team di sviluppo di rispondere alle lamentele dei clienti sulle prestazioni con suggerimenti orientati ai risultati.
L'impostazione di obiettivi di prestazioni per qualsiasi applicazione non banale è un'operazione difficile, figuriamoci per le applicazioni parallele. Un approccio consiste nel ricavare l'obiettivo da metriche di triangolazione ottenute da una determinata metrica delle prestazioni a livello teoretico o di algoritmo per ogni componente e sottocomponente dell'applicazione, dall'analisi comparativa (tra i candidati al confronto ci sono applicazioni simili rivali) e dalla definizione del profilo dell'implementazione/applicazione eventualmente esistente.
Ogni scenario di test dovrebbe definire una serie di criteri di accettazione (una serie di valori che convalidano i risultati del test). Nel caso di scenari di test paralleli, è possibile usare le variabili seguenti come criteri di accettazione.
Varianza nei risultati del test. Indica un'applicazione instabile. La varianza nei risultati del test può essere compresa calcolando la deviazione standard dei risultati.
Utilizzo della CPU. Un basso utilizzo della CPU potrebbe indicare bug di concorrenza, come deadlock e overhead di sincronizzazione. Al contrario, un elevato utilizzo della CPU non è necessariamente un indicatore positivo in quanto i livelock si verificano proprio con un elevato utilizzo della CPU.
Garbage Collection. Per le applicazioni gestite, troppe operazioni di gestione della memoria possono ostacolare l'esecuzione effettiva del lavoro e potrebbero indicare errori di progettazione o implementazione.
Tempo totale di esecuzione del thread. Consente di calcolare all'incirca il tempo totale di esecuzione se il programma doveva essere eseguito sequenzialmente. Confrontando il tempo totale di esecuzione del thread con il tempo trascorso dell'implementazione sequenziale dello stesso programma algoritmo, è possibile comprendere gli overhead di parallelizzazione (e vedere se il test è valido).
Utilizzo totale della memoria. La misura dell'utilizzo totale della memoria è preziosa per capire il profilo della memoria dell'applicazione. Per le applicazioni gestite, il garbage collector ricopre un ruolo significativo nel modificare l'utilizzo totale della memoria dell'applicazione e dovrebbe essere preso in considerazione durante la valutazione dell'utilizzo della memoria.
Prima di iniziare il test delle prestazioni, ci sono tre fasi importanti da seguire per garantire risultati più pertinenti. Innanzitutto, ridurre al minimo la varianza nell'ambiente di test (la varianza può essere introdotta sia dall'applicazione che dall'ambiente di test). È possibile ridurre le varianze nell'ambiente di test interrompendo i servizi e le applicazioni non necessarie e riducendo le interferenze di rete. La varianza causata dall'applicazione può essere ridotta eseguendo iterazioni warm-up e raccogliendo misure da più iterazioni del test.
In secondo luogo, per le applicazioni gestite, l'esecuzione inopportuna del garbage collector può invalidare i risultati del test. Di conseguenza, è opportuno ridurre al minimo le possibilità che il garbage collector venga richiamato durante le misurazioni delle prestazioni forzandone il richiamo prima o dopo la raccolta della misura e/o cambiando GCLatencyMode in LowLatency (ciò è vero solo in Microsoft® .NET Framework 3.5).
In terzo luogo, eseguire il warm-up prima della raccolta delle metriche. Il warm-up, ottenuto eseguendo il test una volta prima della raccolta della misurazione, riduce il costo di operazioni come l'inizializzazione delle variabili, il costo JITing (nelle applicazioni gestite) ed evita la latenza per la cache iniziale. Notare che, a seconda degli scenari delle prestazioni, potrebbe essere importante misurare anche l'avvio a freddo delle prestazioni (per ulteriori informazioni sul miglioramento delle prestazioni all'avvio di un'applicazione, vedere msdn2.microsoft.com/magazine/cc337892.aspx).
Using Synchronization
Bugslayer: Wait Chain Traversal
No More Hangs: Advanced Techniques to Avoid and Detect Deadlocks in .NET Apps
venerdì 11 febbraio 2011
sviluppo di un business online
Leadership sulla cecità sociale esempio media
Con il potere viene responsabilità
Respelt.com - Controllo ortografico automatico il tuo blog
seo doctor
ManageWP diventa più potente
Non mi scaricare e utilizzare il plugin!
Plugin Wordpress Top Recensione
Come per la ricerca di Google con la ricerca personalizzata per disabili
mercoledì 9 febbraio 2011
parole chiave
Oggi ti propongo le 100 poarole chiave più costose in Adwords,cioè le Keywords dove gli inserzionisti spendono una fortuna per far cliccare un singolo utente sul loro annuncio,quindi sicuramente un buon modo per scegliere un argomento di un articolo o addirittura il tema principale di un blog.
Certo,il tema di un blog dovrebbe sempre raffigurare la propria passione,le proprie competenze,la voglia di scrivere di un certo argomento,ma dare un’occhiata alle keywords (quindi a potenziali nicchie) proficue non è certo un male… :mrgreen:
Keyword Cost Per Click Clicks/Day Cost/Day
selling structured settlements $64.81 0.1 $0.00
cash for structured settlements $63.87 0.1 $0.00
auto insurance quotes florida $62.57 0.1 $0.00
california auto insurance quotes $57.34 0.1 $0.00
auto insurance quotes california $57.01 0.1 $0.00
student loan consolidation interest rate $56.86 0.1 $0.00
lendingtree .com $56.35 3.5 $197.22
consolidate loan refinance student $55.86 0.1 $0.00
audio conference calling $55.32 0.1 $0.00
arizona divorce attorneys $53.56 0.1 $0.00
dui attorney los angeles $52.75 0.5 $26.37
business conference calls $52.41 0.1 $0.00
personal injury attorneys chicago $51.59 0.1 $0.00
mesothelioma treatment options $51.31 0.1 $0.00
copper repiping $50.94 0.1 $0.00
conference calling services $49.65 1.0 $49.65
houston criminal lawyer $49.59 0.5 $24.79
criminal houston lawyer $49.59 0.5 $24.79
corporate conference calls $49.35 0.1 $0.00
sell annuity settlement $49.11 0.1 $0.00
student loan consolidation rates $48.80 0.1 $0.00
irs tax attorney $48.78 1.0 $48.78
california criminal defense lawyers $48.38 0.1 $0.00
universal life insurance quote $48.34 2.0 $96.68
san diego criminal lawyer $48.30 0.1 $0.00
irs help $48.27 4.5 $217.21
web based conferencing services $47.80 0.1 $0.00
american tax relief $47.37 0.5 $23.68
criminal defense attorney los angeles $47.34 0.1 $0.00
pacific coast pillows $47.24 1.0 $47.24
chicago personal injury lawyers $46.81 0.1 $0.00
sell annuity payments $46.73 0.1 $0.00
san diego criminal attorney $46.61 0.1 $0.00
los angeles criminal defense attorney $46.59 0.1 $0.00
data recovery seattle $46.59 0.1 $0.00
student loan consolidation rate $46.29 2.0 $92.58
college loan consolidation $46.29 2.5 $115.72
dui attorney san diego $46.04 0.1 $0.00
consolidate school loans $45.94 0.1 $0.00
federal criminal defense attorneys $45.86 0.1 $0.00
irs problem $45.68 1.5 $68.52
mesothelioma lawyers $45.48 2.0 $90.96
chicago injury lawyers $45.22 0.1 $0.00
federal criminal lawyer $45.18 0.5 $22.59
white water rafting maine $45.18 0.5 $22.59
maine white water rafting $45.18 0.5 $22.59
best home equity loans $45.14 1.5 $67.71
universal life quote $45.11 2.5 $112.77
consolidate college loans $45.09 0.5 $22.54
Queste sono parole chiave che in Google Adwords costano davvero parecchio, ma come vedi nella terza colonna non sempre queste Keywords generato clic e quindi profitto.
Per questo ecco un’altra tabella che ti mostra le parole chiave più redditizie cioè che generano tanti clic,a livello mondiale:
Keyword Cost Per Click Clicks/Day Cost/Day
insurance $17.41 49,893.5 $868,645.81
hotels $3.52 200,636.0 $706,238.75
film $2.88 183,044.0 $527,166.75
home $3.89 102,282.5 $397,878.91
car $5.09 52,069.5 $265,033.75
schools $4.13 60,913.0 $251,570.69
acting $2.28 106,337.0 $242,448.36
credit $8.67 25,705.0 $222,862.34
cheap $2.71 82,139.5 $222,598.05
digital $1.70 130,607.0 $222,031.91
hotel $2.38 84,776.5 $201,768.06
film schools $5.64 35,501.5 $200,228.45
software $3.23 61,259.5 $197,868.19
new $2.17 90,415.0 $196,200.55
auto insurance $29.48 6,453.0 $190,234.44
rental $5.97 31,635.5 $188,863.94
free $1.06 172,680.5 $183,041.33
travel $5.02 35,084.5 $176,124.19
auto $7.28 23,610.5 $171,884.44
video $2.01 83,295.0 $167,422.95
mortgage $13.03 12,172.0 $158,601.16
flights $1.91 75,692.0 $144,571.72
editing $2.37 57,747.0 $136,860.39
refinance $20.01 6,827.0 $136,608.27
loans $9.38 13,966.5 $131,005.77
uk $1.43 86,623.5 $123,871.60
computer $3.67 33,043.5 $121,269.64
buy $2.06 58,840.5 $121,211.43
extended stay $20.13 5,758.0 $115,908.54
home insurance $18.75 6,152.0 $115,350.00
training $3.60 31,112.0 $112,003.20
travel insurance $11.29 9,861.0 $111,330.69
cars $3.90 26,198.5 $102,174.15
debt $9.17 11,104.5 $101,828.26
furniture $1.76 57,463.5 $101,135.76
Trackbacks
1. Technotizie.it
2. pligg.com
3. pligg.it
4. www.upnews.it
5. feedburner.it
6. BlocNum.com
7. rankalo.net
8. pligg.com
9. Anonimo
10. www.pubblicanews.it
Certo,il tema di un blog dovrebbe sempre raffigurare la propria passione,le proprie competenze,la voglia di scrivere di un certo argomento,ma dare un’occhiata alle keywords (quindi a potenziali nicchie) proficue non è certo un male… :mrgreen:
Keyword Cost Per Click Clicks/Day Cost/Day
selling structured settlements $64.81 0.1 $0.00
cash for structured settlements $63.87 0.1 $0.00
auto insurance quotes florida $62.57 0.1 $0.00
california auto insurance quotes $57.34 0.1 $0.00
auto insurance quotes california $57.01 0.1 $0.00
student loan consolidation interest rate $56.86 0.1 $0.00
lendingtree .com $56.35 3.5 $197.22
consolidate loan refinance student $55.86 0.1 $0.00
audio conference calling $55.32 0.1 $0.00
arizona divorce attorneys $53.56 0.1 $0.00
dui attorney los angeles $52.75 0.5 $26.37
business conference calls $52.41 0.1 $0.00
personal injury attorneys chicago $51.59 0.1 $0.00
mesothelioma treatment options $51.31 0.1 $0.00
copper repiping $50.94 0.1 $0.00
conference calling services $49.65 1.0 $49.65
houston criminal lawyer $49.59 0.5 $24.79
criminal houston lawyer $49.59 0.5 $24.79
corporate conference calls $49.35 0.1 $0.00
sell annuity settlement $49.11 0.1 $0.00
student loan consolidation rates $48.80 0.1 $0.00
irs tax attorney $48.78 1.0 $48.78
california criminal defense lawyers $48.38 0.1 $0.00
universal life insurance quote $48.34 2.0 $96.68
san diego criminal lawyer $48.30 0.1 $0.00
irs help $48.27 4.5 $217.21
web based conferencing services $47.80 0.1 $0.00
american tax relief $47.37 0.5 $23.68
criminal defense attorney los angeles $47.34 0.1 $0.00
pacific coast pillows $47.24 1.0 $47.24
chicago personal injury lawyers $46.81 0.1 $0.00
sell annuity payments $46.73 0.1 $0.00
san diego criminal attorney $46.61 0.1 $0.00
los angeles criminal defense attorney $46.59 0.1 $0.00
data recovery seattle $46.59 0.1 $0.00
student loan consolidation rate $46.29 2.0 $92.58
college loan consolidation $46.29 2.5 $115.72
dui attorney san diego $46.04 0.1 $0.00
consolidate school loans $45.94 0.1 $0.00
federal criminal defense attorneys $45.86 0.1 $0.00
irs problem $45.68 1.5 $68.52
mesothelioma lawyers $45.48 2.0 $90.96
chicago injury lawyers $45.22 0.1 $0.00
federal criminal lawyer $45.18 0.5 $22.59
white water rafting maine $45.18 0.5 $22.59
maine white water rafting $45.18 0.5 $22.59
best home equity loans $45.14 1.5 $67.71
universal life quote $45.11 2.5 $112.77
consolidate college loans $45.09 0.5 $22.54
Queste sono parole chiave che in Google Adwords costano davvero parecchio, ma come vedi nella terza colonna non sempre queste Keywords generato clic e quindi profitto.
Per questo ecco un’altra tabella che ti mostra le parole chiave più redditizie cioè che generano tanti clic,a livello mondiale:
Keyword Cost Per Click Clicks/Day Cost/Day
insurance $17.41 49,893.5 $868,645.81
hotels $3.52 200,636.0 $706,238.75
film $2.88 183,044.0 $527,166.75
home $3.89 102,282.5 $397,878.91
car $5.09 52,069.5 $265,033.75
schools $4.13 60,913.0 $251,570.69
acting $2.28 106,337.0 $242,448.36
credit $8.67 25,705.0 $222,862.34
cheap $2.71 82,139.5 $222,598.05
digital $1.70 130,607.0 $222,031.91
hotel $2.38 84,776.5 $201,768.06
film schools $5.64 35,501.5 $200,228.45
software $3.23 61,259.5 $197,868.19
new $2.17 90,415.0 $196,200.55
auto insurance $29.48 6,453.0 $190,234.44
rental $5.97 31,635.5 $188,863.94
free $1.06 172,680.5 $183,041.33
travel $5.02 35,084.5 $176,124.19
auto $7.28 23,610.5 $171,884.44
video $2.01 83,295.0 $167,422.95
mortgage $13.03 12,172.0 $158,601.16
flights $1.91 75,692.0 $144,571.72
editing $2.37 57,747.0 $136,860.39
refinance $20.01 6,827.0 $136,608.27
loans $9.38 13,966.5 $131,005.77
uk $1.43 86,623.5 $123,871.60
computer $3.67 33,043.5 $121,269.64
buy $2.06 58,840.5 $121,211.43
extended stay $20.13 5,758.0 $115,908.54
home insurance $18.75 6,152.0 $115,350.00
training $3.60 31,112.0 $112,003.20
travel insurance $11.29 9,861.0 $111,330.69
cars $3.90 26,198.5 $102,174.15
debt $9.17 11,104.5 $101,828.26
furniture $1.76 57,463.5 $101,135.76
Trackbacks
1. Technotizie.it
2. pligg.com
3. pligg.it
4. www.upnews.it
5. feedburner.it
6. BlocNum.com
7. rankalo.net
8. pligg.com
9. Anonimo
10. www.pubblicanews.it
Pionieri dell'informatica
Elenco dei pionieri in informatica
Da Wikipedia, l'enciclopedia libera
Contenuti |
Persona | Realizzazione | Ach. Data |
|---|---|---|
| John Atanasoff | Costruito il primo computer elettronico digitale, il Atanasoff-Berry Computer, Anche se non era né programmabile né Turing-completo. | 1939 |
| Charles Babbage | Progettato il Analytical Engine e costruito un prototipo di meno potente calcolatore meccanico. | 1822 1837 |
| John Backus | Inventato FORTRAN (Permula Trantuite), la prima pratica di programmazione ad alto livello linguistico, e ha formulato le Backus-Naur form che ha descritto il linguaggio formale sintassi. | 1954 1963 |
| George Boole | Formalizzati Algebra booleana, La base per logica digitale e informatica. | 1847 1854 |
| Nikolay Brusentsov | Costruito computer ternario SHENAR. | 1958 |
| Vint Cerf e Bob Kahn | Progettato il Transmission Control Protocol e Internet Protocol (TCP / IP), I dati primari protocolli di comunicazione della Internet e altri reti di computer. | 1978 |
| Alonzo Church | Fondata contributi alla scienza informatica teorica, in particolare per lo sviluppo del lambda calcolo e la scoperta del indecidibilità problema all'interno di esso. | 1936 |
| Wesley Clark A. | Progettato LINC, Il primo computer funzionante in scala verso il basso e un prezzo per il singolo utente. Messo in servizio nel 1963, molte delle sue caratteristiche sono visti come prototipi di quello che dovevano essere gli elementi essenziali dei personal computer. | 1962 |
| Edmund M. Clarke | Sviluppato model checking e la verifica formale di software e hardware con E. Allen Emerson. | 1981 |
| Edgar F. Codd | Proposto e formalizzato la modello relazionale di gestione dei dati, la base teorica di basi di dati relazionali. | 1970 |
| Stephen Cook | Formalizzata la nozione di NP-completezza, ispirando un grande sforzo di ricerca in teoria della complessità computazionale. | 1971 |
| James Cooley | Con John W. Tukey, Ha creato il Fast Fourier Transform. | 1965 |
| Ole-Johan Dahl | Con Kristen Nygaard, Ha inventato il proto-oggetto linguaggio orientato SIMULA. | 1962 |
| Edsger Dijkstra | progressi compiuti in algoritmi, Goto considerato nocivo, Il semaforo (programmazione), rigore, E la pedagogia. | 1968 |
| J. Presper Eckert | Con John Mauchly, Progettato e costruito la ENIAC, Il moderno, di prima (tutte elettronico, Turing-completo) computer, e il UNIVAC I, Il primo computer disponibile in commercio. | 1943 1951 |
| E. Allen Emerson | Sviluppato model checking e la verifica formale di software e hardware con Edmund M. Clarke. | 1981 |
| Douglas Engelbart | Meglio conosciuto per aver inventato il mouse del computer (in uno sforzo congiunto con Bill in inglese), come un pioniere dell'interazione uomo-computer il cui gruppo ha sviluppato Augment ipertesto, computer collegati in rete, E precursori di GUI. | 1963 |
| Tommy Flowers | Progettato e costruito la Mark 1 e le dieci migliori Mark 2 Colosso computer, Il primo al mondo programmabile, digitale, elettronica, informatica dispositivi. | 1943 |
| Gottlob Frege | Sviluppato primo ordine di calcolo dei predicati, Che è stato precursore di un requisito fondamentale per poter sviluppare la teoria di calcolo. | 1879 |
| Seymour Ginsburg | Dimostrato "don't-care"Minimizzazione del circuito non deve necessariamente portare a risultati ottimali, hanno dimostrato che ALGOL linguaggio di programmazione è context-free (così da legare teoria dei linguaggi formali al problema della compilatore scrittura), e inventato AFL Teoria. | 1958 1961 1967 |
| Kurt Gödel | Dimostrato che Peano aritmetica assiomatizzata non poteva essere sia logicamente coerente e completa in primo ordine di calcolo dei predicati. Chiesa, Kleene, Turing e sviluppato le basi della teoria di calcolo basato sulla corollari al lavoro di Gödel. | 1931 |
| Lois Haibt | Era un membro del team persona che ha inventato dieci Fortran e tra le prime donne a svolgere un ruolo cruciale nello sviluppo della scienza informatica. | 1954 |
| C.A.R. Hoare | Ha sviluppato il linguaggio formale Comunicare processi sequenziali (CSP) e Quicksort. | 1960 1978 |
| Grace Hopper | lavori avviati sulla necessità di linguaggi di programmazione ad alto livello, che ha definito programmazione automatica, E ha scritto l'A-O compilatore, Che condiziona fortemente la COBOL lingua. | 1952 |
| Cuthbert Hurd | Ha aiutato la International Business Machines Corporation sviluppare il suo primo computer general-purpose, l' IBM 701. | 1952 |
| Kenneth E. Iverson | Aiutato nella istituisce il primo corso di laurea in informatica (a Harvard) E ha insegnato quel corso; inventato il APL linguaggio di programmazione e contributo al calcolo interattivo. | 1954; 1962 |
| Jacek Karpinski | Sviluppato il primo analizzatore differenziale che usate di transistor, e sviluppato una delle prima macchina algoritmi di apprendimento per il carattere e il riconoscimento delle immagini. È stato anche l'inventore di uno dei primi minicomputer, il K-202. | 1973 |
| Alan Kay | molte delle idee alla base dei linguaggi di programmazione object-oriented Introdotti, ha guidato il team che ha sviluppato Smalltalk, e ha dato contributi fondamentali per il personal computing. | 1970~ |
| Stephen Cole Kleene | Lanciato il lavoro con Alonzo Church sul Lambda Calculus che per primo ha gettato le basi della teoria della computazione. | 1936 |
| Donald Knuth | Ha scritto The Art of Computer Programming e ha creato TeX. | 1968 1989 |
| Leslie Lamport | Formulato algoritmi per risolvere molti problemi fondamentali nei sistemi distribuiti (ad esempio il panificio algoritmo). Sviluppato il concetto di un clock logico, Che permette la sincronizzazione tra entità distribuite in base agli eventi attraverso il quale comunicare. | 1974 1978 |
| Sergei Lebedev Alekseyevich | Indipendentemente progettato il primo computer elettronico in Unione Sovietica, MESM, A Kiev, Ucraina. | 1951 |
| Gottfried Leibniz | progressi della logica simbolica, come la Calcolo ratiocinator, Che sono stati pesantemente influenti sulla Gottlob Frege. sviluppi Made in primo ordine di calcolo dei predicati che sono stati cruciali per i fondamenti teorici dell'informatica. | 1670~ |
| Ramon Llull | Progettato più macchine simboliche rappresentazioni, e pioniere nozioni di rappresentazione simbolica e la manipolazione di produrre conoscenza, sia dei quali sono stati influenze principali su Leibniz. | 1300~ |
| J. C. R. Licklider | Ha iniziato l'indagine dell'interazione uomo-computer, portando a molti progressi nelle interfacce del computer così come in cibernetica e intelligenza artificiale. | 1960 |
| Ada Lovelace | Ha iniziato lo studio del calcolo scientifico, analizzando il lavoro di Babbage nel suo Disegno della macchina analitica, Ed è stata la omonimo per la Ada linguaggio di programmazione. | 1843 |
| John Mauchly | Con J. Presper Eckert, Progettato e costruito la ENIAC, Il moderno, di prima (tutte elettronico, Turing-completo) computer, e il UNIVAC I, Il primo computer disponibile in commercio. | 1943 1951 |
| John McCarthy | Inventato LISP, Un linguaggio di programmazione funzionale. | 1955 |
| Marvin Minsky | Co-fondatore di Artificial Intelligence Lab a Massachusetts Institute of Technology , Autore di numerosi testi su AI e la filosofia. | 1963 |
| Max Newman | Istigato la produzione del Colosso computer a Bletchley Park. Dopo la guerra fondò la Macchina Laboratorio di Informatica presso il Università di Manchester dove il primo al mondo A programma memorizzato computer, Il Manchester Machine Small-Scale Experimental è stato inventato. | 1943 |
| John von Neumann | Ha ideato il architettura di von Neumann su cui i computer più moderni sono basati. | 1945 |
| Kristen Nygaard | Con Ole-Johan Dahl, Ha inventato il proto-oggetto linguaggio orientato SIMULA. | 1962 |
| Emil L. Post | Sviluppato il Post macchina come un modello di calcolo, indipendentemente da Turing. Conosciuto anche per lo sviluppo verità tabelle, Il Post corrispondenza problema utilizzati nella teoria della ricorsione e dimostrare ciò che è noto come teorema di Post. | 1936 |
| Gerard Salton | Un pioniere di automatica Information Retrieval, Che ha proposto la vettore nello spazio modello e il invertita indice. | 1975 |
| Dennis Ritchie e Ken Thompson | Ha aperto la strada C linguaggio di programmazione e il UNIX computer il sistema operativo dei Bell Labs. | 1967 |
| Claude Shannon | Fondata teoria dell'informazione e pratico progettazione di circuiti digitali. | 1937 1948 |
| Herbert Simon | Uno scienziato politico ed economista che per primo intelligenza artificiale. Co-ideatore del Logic Theory Machine e il General Problem Solver programmi. | 1956 1957 |
| Ivan Sutherland | Autore di Album per schizzi, L'antenato del moderno computer-aided redazione (CAD) programmi e uno dei primi esempi di programmazione orientata agli oggetti. | 1963 |
| John W. Tukey | Con James Cooley, Ha creato il Fast Fourier Transform. | 1965 |
| Alan Turing | Dato un contributo alla scienza fondazione diversi computer, compreso il Macchina di Turing computazionale del modello, e ACE design. | 1936 |
| Maurice Wilkes | Costruito il primo pratico programma registrato computer (EDSAC) Da completare e per essere accreditato con le idee di diversi linguaggi di programmazione ad alto livello costrutti. | 1949 |
| Niklaus Wirth | Progettato il Pascal, Modula-2 e Oberon linguaggi di programmazione. | 1970 1978 |
| Konrad Zuse | Costruì il primo computer funzionante nastro a programma memorizzato-controllato, il Z3. La Z3 è stato dimostrato di essere alla completezza di Turing nel 1998. | 1941 |
Iscriviti a:
Post (Atom)
Bookmarklet chicche: Gmail e Respelt