Stai usando un browser non aggiornato. Potresti non visualizzare correttamente questo o altri siti web. Dovreste aggiornare o usare un browser alternativo.
Beh, possono sempre accelerare. Che poi, come non è detto che facciano una build ogni giorno, non è detto nemmeno si faccia una sola build al giorno, tu consideri il solo ramo winmain. Nei vari fbl se ne possono fare anche di più, ognuno è indipendente dall'altro. Senza contare le eventuali ricompilazioni in caso di errore. Poi, ancora al momento il lavoro vero e proprio su 8 non è iniziato, la 7700 non si distingueva da una normale copia di 7. Credo piuttosto stiano portando avanti il ramo winmain in maniera sincronizzata con 7 SP1 in modo da tenersi pronti per quando inizieranno i lavori veri e propri. Una volta dato il via, la sincronia con 7 SP1 si concluderà e ognuno per la propria strada.
Beh, possono sempre accelerare. Che poi, come non è detto che facciano una build ogni giorno, non è detto nemmeno si faccia una sola build al giorno, tu consideri il solo ramo winmain. Nei vari fbl se ne possono fare anche di più, ognuno è indipendente dall'altro. Senza contare le eventuali ricompilazioni in caso di errore. Poi, ancora al momento il lavoro vero e proprio su 8 non è iniziato, la 7700 non si distingueva da una normale copia di 7. Credo piuttosto stiano portando avanti il ramo winmain in maniera sincronizzata con 7 SP1 in modo da tenersi pronti per quando inizieranno i lavori veri e propri. Una volta dato il via, la sincronia con 7 SP1 si concluderà e ognuno per la propria strada.
Beh gervi non è mai stato posticipato perchè non si sa se fossero veri quei rumours ad ogni modo il fatto è questo: Windows 7 è ottimo e sarà ulteriormente ottimizzato con gli aggiornamenti,sempre più aziende passano al nuovo sistema. Se uscisse 8 così presto che fanno,rifanno un upgrade? Capisco la necessità di accelerare i tempi dato che Apple sta preparando il 10.7 (e senz'altro per il 2011 esce xD) però è anche vero che stiamo parlando di Microsoft.
Office 2010 sembra sia andato in RTM e sarà disponibile su msdn e technet dal 22 aprile,credete che ci sia anche la versione italiana? :)
Nella fase alpha non si fanno spesso build del ramo principale, si lavora sulle build dei lab satellite (che non so bene quanti siano adesso ma al tempo di Windows 7 mi pare fossero 6 o 7).
Sara' solo con la beta che iniziera' l'integrazione del codice dai lab satelliti a winmain, il motivo per cui fin tanto che si e' all'inzio non si fanno le build in winmain e' che mancano i test da far girare.
Le build quotidiane servono per misurare lo stato di avanzamento dei lavori tramite i test automatizzati.
Ma nella fase alpha gli stessi tester sono al lavoro per preparare il materiale quindi tutto il processo e' ancora agli albori.
Quindi non prenderei il numero di build come parametro di valutazione della velocita' con cui stanno procedendo allo sviluppo di Windows 8.
Da quel che sapevo, il codice dei vari laboratori viene integrato nella winmain solo dopo essere stato sottoposto ad approvazione e ai test, e me lo confermi. Pensavo però che già dalle Alpha ci fosse qualche integrazione. Mi ricordo che la 6519 di 7, nonostante fosse molto simile a Vista, qualche novità ce l'aveva ed era una winmain.
Certo che fanno "qualche" build in winmain gia' durante le alpha, ma di certo non e' ancora un processo a regime come quando si arriva alla beta, per questo dicevo di non prendere in considerazione il numero di build come indice della velocita' dei lavori ;)
Come ho detto, durante le prime milestone della beta (di solito sono 3) il lavoro del test team e' anch'esso in corso, quindi e' un problema di uovo e gallina... se non inizi a integrare non puoi neppure testare, ma pure i test a loro volta hanno bisogno di essere messi a punto e per farlo devi avere i bit sui quali verificare se il test sta operando correttamente, e' un problema di uovo e gallina da risolvere passo passo ;)
Parlando del futuro... oggi sto studiando VS 2010 e prima ancora C# 4.0... grandissimo lavoro da parte di MS, ma la cosa che mi preme dire e' che sul fronte del supporto per i multicore l'evoluzione procede mooolto bene.
Gervi e' sempre stato molto preoccupato che MS non fosse all'altezza della concorrenza su questo aspetto :D Beh non solo non e' indietro, e' decisamente avanti. C# 4.0 e il .Net framework 4.0 sono davvero maturi al punto che stanno riscrivendo il compilatore C# in... C# :)
Fino ad oggi il compilatore C# era scritto in C++, ma il C++ non si adatta molto bene per scrivere codice che sfrutti al meglio il sempre maggior numero di core delle moderne CPU, anche perche' andrebbe modificato presantemente, a quel punto e' meglio riscriverlo da capo in un linguaggio piu' moderno. Cosi' sono gia' al lavoro (hanno gia' mostrato delle demo funzionanti) per il nuovo compilatore che strutta tutti i core a disposizione... anche 128 (*), tanto per fare un esempio.
Ora forse non a tutti e' chiaro l'impatto di questa notizia: di fatto C# inizia a rimpiazzare il C++ anche in aeree che fino a ieri erano "intoccabili".
Questo implica che la maturita' di C# 4.0 e' tale che molto probabilmente vedremo molte parti di Windows 8 scritte non piu' in C++ :chupachup
(*) Per altro in effetti nei lab di MS stanno usando macchine a 128 core per vari utilizzi.
Certo che fanno "qualche" build in winmain gia' durante le alpha, ma di certo non e' ancora un processo a regime come quando si arriva alla beta, per questo dicevo di non prendere in considerazione il numero di build come indice della velocita' dei lavori ;)
Come ho detto, durante le prime milestone della beta (di solito sono 3) il lavoro del test team e' anch'esso in corso, quindi e' un problema di uovo e gallina... se non inizi a integrare non puoi neppure testare, ma pure i test a loro volta hanno bisogno di essere messi a punto e per farlo devi avere i bit sui quali verificare se il test sta operando correttamente, e' un problema di uovo e gallina da risolvere passo passo ;)
Parlando del futuro... oggi sto studiando VS 2010 e prima ancora C# 4.0... grandissimo lavoro da parte di MS, ma la cosa che mi preme dire e' che sul fronte del supporto per i multicore l'evoluzione procede mooolto bene.
Gervi e' sempre stato molto preoccupato che MS non fosse all'altezza della concorrenza su questo aspetto :D Beh non solo non e' indietro, e' decisamente avanti. C# 4.0 e il .Net framework 4.0 sono davvero maturi al punto che stanno riscrivendo il compilatore C# in... C# :)
Fino ad oggi il compilatore C# era scritto in C++, ma il C++ non si adatta molto bene per scrivere codice che sfrutti al meglio il sempre maggior numero di core delle moderne CPU, anche perche' andrebbe modificato presantemente, a quel punto e' meglio riscriverlo da capo in un linguaggio piu' moderno. Cosi' sono gia' al lavoro (hanno gia' mostrato delle demo funzionanti) per il nuovo compilatore che strutta tutti i core a disposizione... anche 128 (*), tanto per fare un esempio.
Ora forse non a tutti e' chiaro l'impatto di questa notizia: di fatto C# inizia a rimpiazzare il C++ anche in aeree che fino a ieri erano "intoccabili".
Questo implica che la maturita' di C# 4.0 e' tale che molto probabilmente vedremo molte parti di Windows 8 scritte non piu' in C++ :chupachup
(*) Per altro in effetti nei lab di MS stanno usando macchine a 128 core per vari utilizzi.
Sai , io non avevo dubbi sul lavoro Ms riguardo visual studio 2010 ed il relativo supporto alle cpu multicore, rispetto alla concorrenza.
Ma il mio dubbio è relativo al SISTEMA OPERATIVO windows 7 e successivi.
quindi se mi vai un ottimo tool di sviluppo multicore , ma l'OS non ha un kernel all'altezza , non si va da nessuna parte, qui il mio dubbio.
Tra l'altro proprio uno dei padri del kernel di windows 7 (Dave Probert , in una sua dichiarazione messa su tom's ) , diceva che:
Windows 7 ancora oggi non è efficiente x le CPU multicore ( quindi non VS) e la strada intrapresa da MS anche x i successivi os,
vedi windows 8 sembra ancora quella di avre un kernel identico a 7 ( detto da probert eh non da mè)
ed inoltre impossibile che riscrivano soprattutto il kernel in .NET poichè MS ha esperienza in C++ a scrivere kernel , ultra decennale.
Quindi se un giorno riscriveranno il kernel in C# , passeranno almeno 10 anni.
Ripeto queste sono tutte parole fatte trapelare da addetti ai lavori su windows , non da me.
In definitiva dunque ancora adesso , non ho ben capito ( tools a parte) se windows 7 è ottimizzato x le cpu multicore ( dubbi esperessi dal padre fondatore di windows 7) ,
e non mi è chiaro nemmeno uno schema logico-concettuale-funzionale di come windows 7 sia stato organizzato x le cpu multicore fino al kernel!!!!
Che qualcuno avesse fatto uno screen anche artigianale o disegnato a mano di questa ottimizzazione di 7 , sarebbe stato + chiaro.
Ma ho ancora seri dubbi che windows 7 in sè come OS è la solita minestra di windows xp ( perlo di kernel) , solo che è a 64 bit x usare + RAM se necessario.
Ma da quanto ho capito a livello di ottimizzazioni core è uguale al vetusto XP.
Gervi, Windows Server + SQL Server hanno il record mondiale di transazioni al minuto su macchine multicore perche' Windows oggi ha un ottimo supporto per il multicore, il problema e' che in generale le applicazioni non sfruttano il multicore a dovere (non tutte si chiamano SQL Server!).
Quindi il primo passo e' fornire agli sviluppatori degli strumenti semplici ma efficaci per sfruttare il multicore, e C# 4.0 li offre.
Poi siamo d'accordo che guardando al futuro il kernel di Windows puo' e deve essere riprogettato per le architetture hardware a venire, ma oggi per fare un paragone e' come se avessimo un gran motore (il kernel) ma dei pneumatici (le applicazioni) non all'altezza della potenza del motore.
Quindi per ora si deve equilibrare l'attuale architettura ponendo delle basi nei linguaggi di programmazione per il futuro. E poi lavorare per migliorare ulteriormente il motore.
Ma negli utlimi 25 anni i linguaggi di programmazione avevano avuto un'evoluzione unicamente rivolta al core singolo (che andava aumentando di frequenza ma restava appunto singolo), solo di recente abbiamo visto le CPU acquisire sempre piu' core, e adesso la crescita di core e threads sta esplodendo, ma mentre il kernel si e' adattato bene o male alla nuova architettura, i linguaggi di programmazione e di conseguenza le applicazioni sono rimasti legati al passato.
Quindi e' chiaro che e' quasi inutile al momento migliorare il kernel se prima non si ha la possibilita' neppure di sfruttare a dovere quello esistente.
Per questo C# 4.0 e relativo framework segnano oggi una svolta che definirei epocale: introducono la concorrenzialita' e quindi lo sfruttamente del multicore ad un livello che non ha eguali nella concorrenza.
Se guardi come viene implementata la concorrenzialita' in C# e in Grand Central (di Apple)... beh la differenza e' imbarazzante.
Cosa? Gervi Windows 7 non è Windows XP,l'architettura è diversa in tanti aspetti ovviamente; Superfetch,minwin sono solo alcune delle differenze. Se Vista/7 fossero stati uguali ad XP credi che Vista sarebbe stato un disastro all'inizio per quanto riguardava la compatibilità ecc.? Ce ne passaaa ;)
Gervi, Windows Server + SQL Server hanno il record mondiale di transazioni al minuto su macchine multicore perche' Windows oggi ha un ottimo supporto per il multicore, il problema e' che in generale le applicazioni non sfruttano il multicore a dovere (non tutte si chiamano SQL Server!).
Quindi il primo passo e' fornire agli sviluppatori degli strumenti semplici ma efficaci per sfruttare il multicore, e C# 4.0 li offre.
Poi siamo d'accordo che guardando al futuro il kernel di Windows puo' e deve essere riprogettato per le architetture hardware a venire, ma oggi per fare un paragone e' come se avessimo un gran motore (il kernel) ma dei pneumatici (le applicazioni) non all'altezza della potenza del motore.
Quindi per ora si deve equilibrare l'attuale architettura ponendo delle basi nei linguaggi di programmazione per il futuro. E poi lavorare per migliorare ulteriormente il motore.
Ma negli utlimi 25 anni i linguaggi di programmazione avevano avuto un'evoluzione unicamente rivolta al core singolo (che andava aumentando di frequenza ma restava appunto singolo), solo di recente abbiamo visto le CPU acquisire sempre piu' core, e adesso la crescita di core e threads sta esplodendo, ma mentre il kernel si e' adattato bene o male alla nuova architettura, i linguaggi di programmazione e di conseguenza le applicazioni sono rimasti legati al passato.
Quindi e' chiaro che e' quasi inutile al momento migliorare il kernel se prima non si ha la possibilita' neppure di sfruttare a dovere quello esistente.
Per questo C# 4.0 e relativo framework segnano oggi una svolta che definirei epocale: introducono la concorrenzialita' e quindi lo sfruttamente del multicore ad un livello che non ha eguali nella concorrenza.
Se guardi come viene implementata la concorrenzialita' in C# e in Grand Central (di Apple)... beh la differenza e' imbarazzante.
1) Ma questo tools è limitato solo al .NET o no???
Ovvero , non ancora capito , come una applicazione scritta x esempio in c# 4.0 ed otimizzata x il multi.. come poi si Interfaccia a BASSO LIVELLO con il kernel di windows 7 per esempio.
I threads della applicazione a chi vengonbo passati in windows 7???
Solo allo UMS ??? ma sarebbe limitato solo a questo??? e bisogna invocarlo , non esiste l'invocazione automatica ????
Oppure se passano nel kernel diretto di 7 come è ottimizzato quest'ultimo??
Insomma i miei dubbi riguardano il funzionamento concettualedi come avviene o avverrà il passaggion dei threads in windows 7 !!!
:boh:
1) Ma questo tools è limitato solo al .NET o no???
Ovvero , non ancora capito , come una applicazione scritta x esempio in c# 4.0 ed otimizzata x il multi.. come poi si Interfaccia a BASSO LIVELLO con il kernel di windows 7 per esempio.
E' il CLR di .Net che comunica con il kernel e ovviamente il kernel offre tutta una serie di cose tra cui UMS.
Tu scrivi il tuo bel codice C# o F#, il compilatore prende la descrizione ad alto livello e la traduce in un linguaggio intermedio che e' quello che poi viene preso dal CLR che e' "la persona" che poi manda i comandi al kernel, e che si prende cura di gestire tutti gli aspetti di "coordinazione" del lavoro necessario a portare a termine il programma che hai scritto.
Il kernel e' una lavoratore che prende ordini, non entra nel merito della semantica di quello che fa... esegue a testa bassa e senza fare storie ;)
Chiaramente la linea di separazione tra kernel e CLR e' una linea che viene definita in base a quali API il kernel espone e puo' cambiare con l'evoluzione del kernel e del CLR.
Da XP a Windows 7 sono cambiate molte cose, e a dire il vero non ho idea di come si comporti .Net 4.0 su XP dato che alcune API non sono disponibili. Puo' essere che molte ottimizzazioni presenti su Windows 7 semplicemente non siano presenti quando si esegue lo stesso codice su XP, pero' questa e' una mia supposizione, non ho fatto alcuna prova.
E' il CLR di .Net che comunica con il kernel e ovviamente il kernel offre tutta una serie di cose tra cui UMS.
Tu scrivi il tuo bel codice C# o F#, il compilatore prende la descrizione ad alto livello e la traduce in un linguaggio intermedio che e' quello che poi viene preso dal CLR che e' "la persona" che poi manda i comandi al kernel, e che si prende cura di gestire tutti gli aspetti di "coordinazione" del lavoro necessario a portare a termine il programma che hai scritto.
Il kernel e' una lavoratore che prende ordini, non entra nel merito della semantica di quello che fa... esegue a testa bassa e senza fare storie ;)
Chiaramente la linea di separazione tra kernel e CLR e' una linea che viene definita in base a quali API il kernel espone e puo' cambiare con l'evoluzione del kernel e del CLR.
Da XP a Windows 7 sono cambiate molte cose, e a dire il vero non ho idea di come si comporti .Net 4.0 su XP dato che alcune API non sono disponibili. Puo' essere che molte ottimizzazioni presenti su Windows 7 semplicemente non siano presenti quando si esegue lo stesso codice su XP, pero' questa e' una mia supposizione, non ho fatto alcuna prova.
Quello che ci si aspetta in Windows 8 e' che il CLR sia sempre piu' "integrato" col kernel, in modo che si abbiano prestazioni migliori.
Al contempo non si vuole spostare troppe cose dal CLR al kernel per non rischiare di avere un sistema che poi non puoi aggiornare troppo spesso: se tutto il CLR entrasse nel kernel allora si finirebbe per non poterlo sviluppare indipendentemente dal sistema operativo.
Quindi e' un lavoro delicato di divisione dei ruoli tra quello che va messo nel kernel e quello che va lasciato nel CLR.
Ad oggi il kernel di Windows e' ancora fortemente condizionato dal subsystem Win32 (il kernel di NT originariamente supportava anche altri subsystem come OS/2 e Posix) ma presumo che con Windows 8 vedremo una allegerimento dalle dipendenze legate a Win32, perche' Win32 prima o poi sara' gestito in maniera completamente virtuale senza dover avere supporto diretto nel kernel.
Ovviamente questa e' una evoluzione che non e' facile fare in un colpo solo, ad esempio il gia' citato SQL Server (che e' una delle principali fonti di guadagno per MS) e' basato su Win32, per cui non e' certo pensabile che Windows 8 possa avere un impatto negativo per le performance di SQL Server.
Come vedi non e' facile per un sistema operativo che e' pensato sia per i server che per i client rivoluzionare la propria architettura.
Per Linux e per OS X e' tutto piu' semplice perche' Linux e' principalmente un sistema lato server e OS X e' principalmente un sistema usato sui client quindi il loro sviluppo si puo' concentrare su alcuni aspetti trascurandone altri, cosa che Windows non puo' permettersi di fare.
Ad oggi il kernel di Windows e' ancora fortemente condizionato dal subsystem Win32 (il kernel di NT originariamente supportava anche altri subsystem come OS/2 e Posix) ma presumo che con Windows 8 vedremo una allegerimento dalle dipendenze legate a Win32, perche' Win32 prima o poi sara' gestito in maniera completamente virtuale senza dover avere supporto diretto nel kernel.
Win32 e in generale le Windows API sono una pietra miliare della storia dell'informatica... direi che quel giorno si festeggera' l'entrata in un nuova era ma ci sara' da riconoscere il ruolo fondamentale che Win32 ha avuto... se oggi possiamo usare PC iper prestazionali che costano cifre irrisorie e' soprattutto merito delle Windows API, e devono essergliene grati anche gli utenti Linux e Mac ;)
