Microsoft: due core al prezzo di uno

Le licenze del gigante del software vedranno i processori dual-core come un solo processore. Una decisione importante che va incontro alle richieste di Intel e AMD

Redmond (USA) - Le licenze per il software destinato ai server, attualmente vincolate al numero di processori utilizzati, resteranno immutate anche in presenza di sistemi contenenti processori dual-core e multi-core, indipendentemente quindi dal numero dei core presenti. E' quanto ha annunciato negli scorsi giorni Microsoft, accogliendo così quelle che sono le raccomandazioni di Intel e AMD a favore dell'equiparazione dei processori multi-core ad una singola CPU.

"La strategia di licensing Microsoft agevolerà la diffusione della tecnologia server multi-core", ha affermato Brent Callinicos, corporate vice president of Worldwide Licensing and Pricing di Microsoft. "Le aziende potranno aggiornare i propri sistemi alle tecnologie multi-core senza dover pagare, per il software, alcun extra".

E' proprio ciò che volevano Intel e AMD, particolarmente preoccupate che un eventuale modello di licensing che prendesse in considerazione il numero di core anziché il numero di chip potesse frenare l'ascesa sul mercato dei loro imminenti processori dual-core.
"I processori multi-core rappresentano l'evoluzione logica lungo il percorso che conduce all'incremento delle prestazioni negli ambienti multitasking", ha affermato AMD in un comunicato.

Sebbene Microsoft sia la prima azienda di software al mondo, e dunque la sua scelta avrà un peso notevole su tutto il settore, vi sono altri big, come Oracle, che hanno preso decisioni opposte e trattano i processori dual-core come due distinte CPU. Le società dell'open source, tra cui Red Hat, sembrano invece solidali con Intel e AMD.
TAG: mercato
21 Commenti alla Notizia Microsoft: due core al prezzo di uno
Ordina
  • Il prob. è solo in parte del S.O.! Lo è anche di WOrd etc ... !

    Scrivendo un sw multicore non sono solo c@zzi del SO, non sempre tu fai la chiamata all'API e quello se la smazza su più processi: Devi fare attenzione e regolarti dividendo TU quello che devi fare su più processi paralleli, che poi (magari) il SO li assegna. Ti assicuro che non è assolutamente facile, anzi! Devi prevedere che il S.O. non ne abbia a disposizione, così come evitare il blocco critico etcetcetc.
    Non mi sembra tanto una stupidata far pagare un programmma di più solo (anche) perchè è multicore: aumenta il lavoro rispetto ad un sigle cpu. Se Microsoft fa queta mossa, ho paura che nonpotendo rimentterci (non è mica un SW Free!) farà pagare di più a tutti, compreso chi ha ancora un solo micro!

    Questa è la mia reale paura.

  • - Scritto da: The Raptus
    > Il prob. è solo in parte del S.O.! Lo
    > è anche di WOrd etc ... !
    >
    > Scrivendo un sw multicore non sono solo
    > c@zzi del SO, non sempre tu fai la chiamata
    > all'API e quello se la smazza su più
    > processi: Devi fare attenzione e regolarti
    > dividendo TU quello che devi fare su
    > più processi paralleli, che poi
    > (magari) il SO li assegna. Ti assicuro che
    > non è assolutamente facile, anzi!
    > Devi prevedere che il S.O. non ne abbia a
    > disposizione, così come evitare il
    > blocco critico etcetcetc.
    > Non mi sembra tanto una stupidata far pagare
    > un programmma di più solo (anche)
    > perchè è multicore: aumenta il
    > lavoro rispetto ad un sigle cpu. Se
    > Microsoft fa queta mossa, ho paura che
    > nonpotendo rimentterci (non è mica un
    > SW Free!) farà pagare di più a
    > tutti, compreso chi ha ancora un solo micro!
    >
    > Questa è la mia reale paura.


    Mica sei obbligato a usare fondi di magazzino, non esiste solo Redmond sul pianeta Terra.

    Fan Apple

    Smettete di avere paura (Giovanni Paolo II)
    non+autenticato
  • Di cose buone ne fa molto poche, e quando le fa qualche interesse dietro c'è sempre, comunque un BRAVA MICRO$OFT oggi non glie lo toglie nessuno.
    ;)
    non+autenticato

  • - Scritto da: Anonimo
    > Di cose buone ne fa molto poche, e quando le
    > fa qualche interesse dietro c'è
    > sempre, comunque un BRAVA MICRO$OFT oggi non
    > glie lo toglie nessuno.
    >Occhiolino

    Mi associo, facendo anche notare che comunque per la MS non sarebbe un gran momento per imporre limitazioni, visto che l'open source sta iniziando a dare fastidio (firefox e openoffice in testa)
  • "vedrà un solo core"... nel senso che sull'adesivo appiccicato sopra il bandone di latta ci sarà scritto dual core a caratteri cubitali per far abboccare il fessacchiotto... ma in realtà windows xp svilupperà la solita velocità da monocore senza nessun beneficio... A bocca aperta

    son geniali quelli di microsoft...
    non+autenticato
  • saranno anche geniali
    ma ci rimetteranno dei soldi
    cosa che ha deciso di non fare oracle e ibm

    ;)
    non+autenticato
  • C'e' scritto chiaramente che la licenza vedra' un solo core.

    Arturo
    non+autenticato
  • La regola del 'una licenza per ogni processore' è semplicemente indice della schizofrenia compulsiva del magna magna del software. E' semplicemente ridicolo e grottesco che si debba pagare una licenza per ogni processore... Si dovrebbe pagare una licenza per un sistema funzionante. Che abbia dentro 1 10 100 chip alla software house non dovrebbe fregarne alcunchè se poi la macchina si limita a far girare unicamente UN SISTEMA operativo...
  • E' una regola nata molto tempo ai tempi dei mainfframe fa e diffusa con Internet: più la macchina è potente e più paghi (tra l'altro non mi sembra così scandalosa).

    Quando è nata l'informatica personale il modello per utente o per pc si è diffuso. Con il boom di Internet non si è riuscito più a contare i client o gli utenti e si è (ri)cercato un modo di calcolare la potenza delle macchine. Il metodo più semplice è risultato essere il conto delle CPU.

    Anche oggi i canoni di noleggio dei mainframe cambiano in base alla potenza della macchina

    Da notare che esistono ancora adesso produttori che misurano la potenza in modo diverso. Anche la stessa IBM fino a poco tempo fa IBM per il suo prodotto MQ Series calcolava le capacity unit. Una macchina con un processore Intel costava 2 c.u. per CPU mentre una macchina Solaris costava 4 c.u. per CPU. Quindi chi aveva Solaris pagava di più. Adesso MQ Series va a processori (ma i client come prima non si pagano).

    Windows Server Standard può funzionare fino a 4 processori single-core o multi-core (superati questi si acquista la versione Enterprise) ma richiede il pagamento dei client attraverso una CAL.

    Più semplice di così...
    non+autenticato
  • - Scritto da: Anonimo

    > E' una regola nata molto tempo ai tempi dei
    > mainfframe fa e diffusa con Internet:
    > più la macchina è potente e
    > più paghi (tra l'altro non mi sembra
    > così scandalosa).

    Ma, è un modo molto opinabile di gestire la cosa. Non mi risulta, per esempio, di pagare la benzina in base ai cavalli della macchina...

    > semplice è risultato essere il conto
    > delle CPU.

    E' comunque errato considerare la 'potenza' della macchina come base di calcolo per il costo della licenza altrimenti dovremmo pagare anche in base ai Mhz.... E' di fatto un escamotage delle software house per giustificare maggiori introiti senza peraltro investire in ottimizzazione del software. In fin dei conti ti stanno vendendo LO STESSO PRODOTTO, e un S.O. ottimizzato per TUTTO non potrà, ovviamente dare il meglio di sè stesso... Pago in più ma non ho alcun valore aggiunto, o meglio il valore aggiunto è rappresentato dall'hardware peraltro già pagato.

    > Anche oggi i canoni di noleggio dei
    > mainframe cambiano in base alla potenza
    > della macchina

    Si, della macchina, mica del software!

    > Più semplice di così...

    O certo, per chi vende la licenza è semplice e soprattutto comodo.
  • Il motivo per cui una licenza software è legata al numero di processori è che il software deve essere progettato per essere multiprocessore.

    ;)
    non+autenticato

  • - Scritto da: Anonimo
    > Il motivo per cui una licenza software
    > è legata al numero di processori
    > è che il software deve essere
    > progettato per essere multiprocessore.

    Il software ? Dovrebbe essere compito del SO, non del soft !

    non+autenticato
  • Infatti! sta parlando del S.O. Server!!!
    Inoltre anche scrivendo un sw multicore non sono solo c@zzi del SO, non sempre tu fai la chiamata all'API e quello se la smazza su più processi: Devi fare attenzione e regolarti dividendo TU quello che devi fare su più processi paralleli, che poi (magari) il SO li assegna. Ti assicuro che non è assolutamente facile, anzi! Devi prevedere che il S.O. non ne abbia a disposizione, così come evitare il blocco critico etcetcetc.
    Non mi sembra tanto una stupidata far pagare un programmma di più solo (anche) perchè è multicore: aumenta il lavoro rispetto ad un sigle cpu. Se Microsoft fa queta mossa, ho paura che nonpotendo rimentterci (non è mica un SW Free!) farà pagare di più a tutti, compreso chi ha ancora un solo micro!

    Questa è la mia reale paura.

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > > Il motivo per cui una licenza software
    > > è legata al numero di processori
    > > è che il software deve essere
    > > progettato per essere multiprocessore.
    >
    > Il software ? Dovrebbe essere compito del
    > SO, non del soft !
    >

    Le problematiche dietro a quanto affermi sono tante e tali che nemmeno ti immagini quello che hai scritto. Il sistema operativo può ridirezionare i thread tra i vari processori, ma se hai un programma che usa un solo thread, quello girerà sempre e solo su un solo processore alla volta. Da quello che leggo, tu vorresti che un programma pensato come single threaded riesca a sfruttare due processori... beh, non ci sono ancora compilatori così fighi da generare quanto dici.
    Nonostante ciò, il sistema operativo in ambienti multiprocessore deve farsi un mazzo tanto per evitare che 2 processori usino le stesse aree di memoria, che la chace dei processori sia coerente con la memoria (due processori = 2 cache diverse da sincronizzare), deve usare algoritmi di scheduling diversi... e tanto altro ancora, tipo la gestione degli interrupt. Non pensare che passare da uno a 2 sia una baggianata, anzi...
    non+autenticato

  • - Scritto da: Anonimo

    > Le problematiche dietro a quanto affermi
    > sono tante e tali che nemmeno ti immagini
    > quello che hai scritto. Il sistema operativo
    > può ridirezionare i thread tra i vari
    > processori, ma se hai un programma che usa
    > un solo thread, quello girerà sempre
    > e solo su un solo processore alla volta.

    Amen, e' il prezzo da pagare per avere un soft "portabile".

    > Da
    > quello che leggo, tu vorresti che un
    > programma pensato come single threaded
    > riesca a sfruttare due processori... beh,
    > non ci sono ancora compilatori così
    > fighi da generare quanto dici.

    Non ancora, ma qualcosa si sta' facendo nella direzione giusta.
    Anche se, IMHO, in un sistema home penso sia piuttosto inutile, dato che la macchina solitamente fa' girare piu' processi (mp3 player e browser, oppure emule e word, oppure, ...) e non e' propriamente un number-cruncher con un solo processo che occupa il 100% delle risorse.

    > Nonostante ciò, il sistema operativo
    > in ambienti multiprocessore deve farsi un
    > mazzo tanto per evitare che 2 processori
    > usino le stesse aree di memoria, che la
    > chace dei processori sia coerente con la
    > memoria (due processori = 2 cache diverse da
    > sincronizzare), deve usare algoritmi di
    > scheduling diversi... e tanto altro ancora,
    > tipo la gestione degli interrupt.

    Hmmm, l'accesso alla cache non e' compito del processore stesso ? AFAIK, il SO non ha visione della cache.

    > Non
    > pensare che passare da uno a 2 sia una
    > baggianata, anzi...

    Indubbiamente no, pero' meglio sarebbe risolvere questi problemi a livello basso (Processore, OS) piuttosto che a livello di applicazione, no ?
    non+autenticato

  • - Scritto da: Anonimo

    > Da quello che leggo, tu vorresti che un
    > programma pensato come single threaded
    > riesca a sfruttare due processori... beh,
    > non ci sono ancora compilatori così
    > fighi da generare quanto dici.

    I compilatori Intel (io uso solo il compilatore Fortran sotto Linux, ma sono ragionevolmente sicuro che valga anche per gli altri) implementano due flag:
    -xW (e simili): cerca di vettorizzare automaticamente i loop (sfruttando MMX,SSE, SSE2,SSE3)
    -parallel: cerca di parallelizzare automaticamente i loop con OpenMP, che puo' comunque essere usata esplicitamente. OpenMP e' un insieme di direttive di parallelizzazione molto semplice (rispetto a mpi e librerie simili) che permette di inserire le direttive come commenti nel codice originale, che quindi vengono ignorati dai normali compilatori, ma che possono essere interpretati da compilatori che implementino il supporto a tali direttive.

    Le intenzioni sarebbero quelle di automatizzare la parallelizzazione/vettorizzazione per venire incontro a chi non ha il tepo/le risorse per farlo a mano, i risultati sono alterni ma credo siano sulla strada giusta (ovviamente Intel ha tutto l'interesse a sviluppare srumenti che facilitino lo sfruttamento di HT e dualcore). Naturalmente semplicita' e prestazioni estreme vanno d'accordo fino a un certo punto, ma il rapporto 'aumento di prestazioni/tempo di sviluppo' puo' essere molto vantaggioso.

    Arturo
    non+autenticato
  • si vede che non hai mai scritto una aplicazione multi-thread!
    non+autenticato
  • Engine wrote:
    > La regola del 'una licenza per ogni processore' è
    > semplicemente indice della schizofrenia compulsiva del
    > magna magna del software.

    Quoto in pieno.

    Quando ho letto l'occhiello mi ci son voluti 20 secondi buoni per capire di ke ca**o stesse parlando.
    E quando me ne sono reso conto mi ci son voluto 20 secondi buoni per crederci (o meglio: "per ricordarmi ke brevetti concedono in USA").
  • che fanno si sfidano a duello ?

    :D

    (Nel sottotitolo)
    non+autenticato
  • si, fanno a gara a chi fa crashare prima XPA bocca aperta

  • - Scritto da: TrollSpammer
    > si, fanno a gara a chi fa crashare prima XP
    >A bocca aperta
    Non bisogna fare gara a chi lo fa crashare prima.... al limite a chi lo fa resistere 15 secondi + dell'altro Con la lingua fuori
    non+autenticato