[math-fun] Intel to incorporate FPGA in new Xeon processor
FYI -- Lots of potential math applications... https://communities.intel.com/community/itpeernetwork/datastack/blog/2014/06... Disrupting the Data Center to Create the Digital Services Economy Posted by Diane Bryant in The Data Stack on Jun 18, 2014 12:56:03 PM .... But what we find even more exciting is our next innovation in processor design that can dramatically increase application performance through fully custom accelerators. **** We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings.**** Why are we excited by this announcement? The FPGA provides our customers a programmable, high performance coherent acceleration capability to turbo-charge their critical algorithms. And with down-the-wire reprogramability, the algorithms can be changed as new workloads emerge and compute demands fluctuate. Based on industry benchmarks FPGA-based accelerators can deliver >10X performance gains. By integrating the FPGA with the Xeon processor, we estimate that customers will see an additional 2X in performance thanks to the low latency, coherent interface. Our new Xeon+FPGA solution provides yet another customized option, one more tool for customers to use to improve their critical data center metric of Performance/TCO. It highlights our commitment to delivering the very best solutions across all data center workloads and our passion to lead in the transformation of the industry to cloud services. ....
We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings.
In the late sixties there was an announcement by DEC of a PDP-6 with programmable firmware. At least, I think that is what it must have been because what I recall is Gosper's response: if you had that, why would you want it to be a PDP-6. My response to this is the same. If you have a CPU with an FPGA, why do you need anything more than a primitive processor to manage the programming of the FPGA. Could you not get rid of much of the legacy processor which, I assume, is most of the Xeon. Whit
Maybe you'd like to run preexisting software rather than build everything from scratch. --ms On 2014-06-23 10:33, Whitfield Diffie wrote:
We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings. In the late sixties there was an announcement by DEC of a PDP-6 with programmable firmware. At least, I think that is what it must have been because what I recall is Gosper's response: if you had that, why would you want it to be a PDP-6. My response to this is the same.
If you have a CPU with an FPGA, why do you need anything more than a primitive processor to manage the programming of the FPGA. Could you not get rid of much of the legacy processor which, I assume, is most of the Xeon.
Whit
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
Maybe you'd like to run preexisting software rather than build everything from scratch.
I assume for that it would be sufficient to have a Pentium programmed in your FPGA as the default. However, some things like floating point that need to be very fast may also be a good fraction of the legacy processor so that once you have those, there is no reason not to include the whole thing. Whit
FPGAs tend not to run as fast as dedicated logic. They can be very wide, but depending on what you are doing the clock speed is usually two to ten times slower and sometimes more. Of course, FPGAs can do custom workloads in many cases without the overhead of instruction fetch and decode, etc., so even with the clock rate penalty some serial code is faster in an FPGA. It will be interesting to see how they clock the FPGA portion and what sort of clock rates are possible. On Mon, Jun 23, 2014 at 7:51 AM, Whitfield Diffie <whitfield.diffie@gmail.com> wrote:
Maybe you'd like to run preexisting software rather than build everything from scratch.
I assume for that it would be sufficient to have a Pentium programmed in your FPGA as the default. However, some things like floating point that need to be very fast may also be a good fraction of the legacy processor so that once you have those, there is no reason not to include the whole thing.
Whit
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
-- -- http://cube20.org/ -- http://golly.sf.net/ --
Hard wired processors do a lot of things more efficiently with special purpose logic. A simple example is the carry-chain of adders, which are special-cased for long carry propagates that happen very rapidly. Another, probably more important optimization, is the availability of many-port register files, with 1-2 write ports and 3-6 read ports being common on modern processors. Also, the achievable clock speed of a modern micro is 3-10x faster than a similar architecture done in FPGAs. I do think one could design FPGAs that competed with processor speeds, but they would include higher level blocks with greater functionality than simple gate level logic. One approach that is worth knowing about is this one, which defines a matrix of ALU/Register file units which can be pipelined or operated in parallel. Reconfiguration at a high level, special high performance logic at the low level: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=564808&url=http%3A%2F%... On Jun 23, 2014, at 10:39 AM, Mike Speciner <ms@alum.mit.edu> wrote:
Maybe you'd like to run preexisting software rather than build everything from scratch.
--ms
On 2014-06-23 10:33, Whitfield Diffie wrote:
We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings. In the late sixties there was an announcement by DEC of a PDP-6 with programmable firmware. At least, I think that is what it must have been because what I recall is Gosper's response: if you had that, why would you want it to be a PDP-6. My response to this is the same.
If you have a CPU with an FPGA, why do you need anything more than a primitive processor to manage the programming of the FPGA. Could you not get rid of much of the legacy processor which, I assume, is most of the Xeon.
Whit
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
One difficulty with a large-state gadget inside a modern operating system is: How to handle sharing of the resource among different processes. The FPGA might have 100K bits of state to preserve. Do you let one process own it? Do you save the gadget state when doing a process switch? This problem occurred in miniature back when there were separate floating-point units with a modest stack of data. I think the solution then was that processes declared when they used the FPU, and state swapping was done whenever two FPU-using processes shared it. Rich ---- Quoting Tom Knight <tk@ginkgobioworks.com>:
Hard wired processors do a lot of things more efficiently with special purpose logic. A simple example is the carry-chain of adders, which are special-cased for long carry propagates that happen very rapidly. Another, probably more important optimization, is the availability of many-port register files, with 1-2 write ports and 3-6 read ports being common on modern processors.
Also, the achievable clock speed of a modern micro is 3-10x faster than a similar architecture done in FPGAs. I do think one could design FPGAs that competed with processor speeds, but they would include higher level blocks with greater functionality than simple gate level logic.
One approach that is worth knowing about is this one, which defines a matrix of ALU/Register file units which can be pipelined or operated in parallel. Reconfiguration at a high level, special high performance logic at the low level: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=564808&url=http%3A%2F%...
On Jun 23, 2014, at 10:39 AM, Mike Speciner <ms@alum.mit.edu> wrote:
Maybe you'd like to run preexisting software rather than build everything from scratch.
--ms
On 2014-06-23 10:33, Whitfield Diffie wrote:
We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings. In the late sixties there was an announcement by DEC of a PDP-6 with programmable firmware. At least, I think that is what it must have been because what I recall is Gosper's response: if you had that, why would you want it to be a PDP-6. My response to this is the same.
If you have a CPU with an FPGA, why do you need anything more than a primitive processor to manage the programming of the FPGA. Could you not get rid of much of the legacy processor which, I assume, is most of the Xeon.
Whit
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
I'm not 100% up to speed on the most modern versions, but it was my impression that you don't reprogram FPGA's every time you switch tasks. Besides taking a very long time, some of these devices have an upper limit on how many times you can reprogram them. The size of the state may be the least of your problems if you're trying to share such a unit among different tasks. At 09:47 AM 6/23/2014, rcs@xmission.com wrote:
One difficulty with a large-state gadget inside a modern operating system is: How to handle sharing of the resource among different processes. The FPGA might have 100K bits of state to preserve. Do you let one process own it? Do you save the gadget state when doing a process switch? This problem occurred in miniature back when there were separate floating-point units with a modest stack of data. I think the solution then was that processes declared when they used the FPU, and state swapping was done whenever two FPU-using processes shared it.
Rich
---- Quoting Tom Knight <tk@ginkgobioworks.com>:
Hard wired processors do a lot of things more efficiently with special purpose logic. A simple example is the carry-chain of adders, which are special-cased for long carry propagates that happen very rapidly. Another, probably more important optimization, is the availability of many-port register files, with 1-2 write ports and 3-6 read ports being common on modern processors.
Also, the achievable clock speed of a modern micro is 3-10x faster than a similar architecture done in FPGAs. I do think one could design FPGAs that competed with processor speeds, but they would include higher level blocks with greater functionality than simple gate level logic.
One approach that is worth knowing about is this one, which defines a matrix of ALU/Register file units which can be pipelined or operated in parallel. Reconfiguration at a high level, special high performance logic at the low level: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=564808&url=http%3A%2F%...
On Jun 23, 2014, at 10:39 AM, Mike Speciner <ms@alum.mit.edu> wrote:
Maybe you'd like to run preexisting software rather than build everything from scratch.
--ms
On 2014-06-23 10:33, Whitfield Diffie wrote:
We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings. In the late sixties there was an announcement by DEC of a PDP-6 with programmable firmware. At least, I think that is what it must have been because what I recall is Gosper's response: if you had that, why would you want it to be a PDP-6. My response to this is the same.
If you have a CPU with an FPGA, why do you need anything more than a primitive processor to manage the programming of the FPGA. Could you not get rid of much of the legacy processor which, I assume, is most of the Xeon.
Whit
We looked at what it would take to switch configurations quickly in an FPGA. There are some nice things you can do with it, other than multiple processes. For example, you can build larger “circuits” than you have silicon for, and multiplex the wiring (the most costly part). Wires typically don’t change state all that often, so you can often time-multiplex signals on costly wires to improve performance. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCcQFjAB... On Jun 23, 2014, at 1:10 PM, Henry Baker <hbaker1@pipeline.com> wrote:
I'm not 100% up to speed on the most modern versions, but it was my impression that you don't reprogram FPGA's every time you switch tasks. Besides taking a very long time, some of these devices have an upper limit on how many times you can reprogram them.
The size of the state may be the least of your problems if you're trying to share such a unit among different tasks.
At 09:47 AM 6/23/2014, rcs@xmission.com wrote:
One difficulty with a large-state gadget inside a modern operating system is: How to handle sharing of the resource among different processes. The FPGA might have 100K bits of state to preserve. Do you let one process own it? Do you save the gadget state when doing a process switch? This problem occurred in miniature back when there were separate floating-point units with a modest stack of data. I think the solution then was that processes declared when they used the FPU, and state swapping was done whenever two FPU-using processes shared it.
Rich
---- Quoting Tom Knight <tk@ginkgobioworks.com>:
Hard wired processors do a lot of things more efficiently with special purpose logic. A simple example is the carry-chain of adders, which are special-cased for long carry propagates that happen very rapidly. Another, probably more important optimization, is the availability of many-port register files, with 1-2 write ports and 3-6 read ports being common on modern processors.
Also, the achievable clock speed of a modern micro is 3-10x faster than a similar architecture done in FPGAs. I do think one could design FPGAs that competed with processor speeds, but they would include higher level blocks with greater functionality than simple gate level logic.
One approach that is worth knowing about is this one, which defines a matrix of ALU/Register file units which can be pipelined or operated in parallel. Reconfiguration at a high level, special high performance logic at the low level: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=564808&url=http%3A%2F%...
On Jun 23, 2014, at 10:39 AM, Mike Speciner <ms@alum.mit.edu> wrote:
Maybe you'd like to run preexisting software rather than build everything from scratch.
--ms
On 2014-06-23 10:33, Whitfield Diffie wrote:
We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings. In the late sixties there was an announcement by DEC of a PDP-6 with programmable firmware. At least, I think that is what it must have been because what I recall is Gosper's response: if you had that, why would you want it to be a PDP-6. My response to this is the same.
If you have a CPU with an FPGA, why do you need anything more than a primitive processor to manage the programming of the FPGA. Could you not get rid of much of the legacy processor which, I assume, is most of the Xeon.
Whit
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
On 2014-06-23 07:07, Henry Baker wrote:
FYI -- Lots of potential math applications...
https://communities.intel.com/community/itpeernetwork/datastack/blog/2014/06...
I'm curious whether you (or anyone here) thinks this is really so different than programmable micro-code -- e.g. writable control store? [I know that Lisp Machines (well, Symbolics' machines until the XL- series) had this capability, and so did some vaxen (-WCS versions). I've heard that early IBM 360's or 370's had this, too, but I have no direct experience with modifying the microcode on those]. So I wonder how revolutionary will this Intel move really be? My impression (no hard data, though) is that users are often really excited by the idea, but very, very, few actually use this capability in practice.
Disrupting the Data Center to Create the Digital Services Economy Posted by Diane Bryant in The Data Stack on Jun 18, 2014 12:56:03 PM
.... But what we find even more exciting is our next innovation in processor design that can dramatically increase application performance through fully custom accelerators. **** We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings.****
Why are we excited by this announcement? The FPGA provides our customers a programmable, high performance coherent acceleration capability to turbo-charge their critical algorithms. And with down-the-wire reprogramability, the algorithms can be changed as new workloads emerge and compute demands fluctuate. Based on industry benchmarks FPGA-based accelerators can deliver >10X performance gains. By integrating the FPGA with the Xeon processor, we estimate that customers will see an additional 2X in performance thanks to the low latency, coherent interface.
Our new Xeon+FPGA solution provides yet another customized option, one more tool for customers to use to improve their critical data center metric of “Performance/TCO”. It highlights our commitment to delivering the very best solutions across all data center workloads and our passion to lead in the transformation of the industry to cloud services. ....
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
On 2014-06-23 10:34, Michael Greenwald wrote:
On 2014-06-23 07:07, Henry Baker wrote:
FYI -- Lots of potential math applications...
https://communities.intel.com/community/itpeernetwork/datastack/blog/2014/06...
I'm curious whether you (or anyone here) thinks this is really so different than programmable micro-code -- e.g. writable control store?
To clarify: I meant "different" in terms of impact or use by customers.
[I know that Lisp Machines (well, Symbolics' machines until the XL- series) had this capability, and so did some vaxen (-WCS versions). I've heard that early IBM 360's or 370's had this, too, but I have no direct experience with modifying the microcode on those].
So I wonder how revolutionary will this Intel move really be? My impression (no hard data, though) is that users are often really excited by the idea, but very, very, few actually use this capability in practice.
And, I could just have the wrong impression: maybe writable control store *was* used a lot more than I believe.
Disrupting the Data Center to Create the Digital Services Economy Posted by Diane Bryant in The Data Stack on Jun 18, 2014 12:56:03 PM
.... But what we find even more exciting is our next innovation in processor design that can dramatically increase application performance through fully custom accelerators. **** We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings.****
Why are we excited by this announcement? The FPGA provides our customers a programmable, high performance coherent acceleration capability to turbo-charge their critical algorithms. And with down-the-wire reprogramability, the algorithms can be changed as new workloads emerge and compute demands fluctuate. Based on industry benchmarks FPGA-based accelerators can deliver >10X performance gains. By integrating the FPGA with the Xeon processor, we estimate that customers will see an additional 2X in performance thanks to the low latency, coherent interface.
Our new Xeon+FPGA solution provides yet another customized option, one more tool for customers to use to improve their critical data center metric of “Performance/TCO”. It highlights our commitment to delivering the very best solutions across all data center workloads and our passion to lead in the transformation of the industry to cloud services. ....
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
Almost all of the writable control store microprocessors were very poorly programmable. Most used the feature to allow bug repair of the microcode, and could barely do that. When I designed the initial Lisp machine, there was, to my knowledge, just the Alto and a modified PDP-11/45 at CMU with WCS. Neither machine had general shifter/maskers or a way to do multi-way branches on a register field. I do agree with you, however, that the general capabilities were poorly used. We could, for example, have defined instructions on the PDP-10 which used the UUO traps. They would have been slow, but quite capable. In some sense, the ITS system calls behaved very much like “instructions” of this form. On Jun 23, 2014, at 1:38 PM, Michael Greenwald <mbgreen@seas.upenn.edu> wrote:
On 2014-06-23 10:34, Michael Greenwald wrote:
On 2014-06-23 07:07, Henry Baker wrote:
FYI -- Lots of potential math applications... https://communities.intel.com/community/itpeernetwork/datastack/blog/2014/06... I'm curious whether you (or anyone here) thinks this is really so different than programmable micro-code -- e.g. writable control store?
To clarify: I meant "different" in terms of impact or use by customers.
[I know that Lisp Machines (well, Symbolics' machines until the XL- series) had this capability, and so did some vaxen (-WCS versions). I've heard that early IBM 360's or 370's had this, too, but I have no direct experience with modifying the microcode on those]. So I wonder how revolutionary will this Intel move really be? My impression (no hard data, though) is that users are often really excited by the idea, but very, very, few actually use this capability in practice.
And, I could just have the wrong impression: maybe writable control store *was* used a lot more than I believe.
Disrupting the Data Center to Create the Digital Services Economy Posted by Diane Bryant in The Data Stack on Jun 18, 2014 12:56:03 PM .... But what we find even more exciting is our next innovation in processor design that can dramatically increase application performance through fully custom accelerators. **** We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings.**** Why are we excited by this announcement? The FPGA provides our customers a programmable, high performance coherent acceleration capability to turbo-charge their critical algorithms. And with down-the-wire reprogramability, the algorithms can be changed as new workloads emerge and compute demands fluctuate. Based on industry benchmarks FPGA-based accelerators can deliver >10X performance gains. By integrating the FPGA with the Xeon processor, we estimate that customers will see an additional 2X in performance thanks to the low latency, coherent interface. Our new Xeon+FPGA solution provides yet another customized option, one more tool for customers to use to improve their critical data center metric of “Performance/TCO”. It highlights our commitment to delivering the very best solutions across all data center workloads and our passion to lead in the transformation of the industry to cloud services. .... _______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
Clinton Parker & I developed a microcode compiler for the Xerox Alto microcode at the University of Rochester. The biggest part of the speed up was eliminating the slow instruction fetch for the usual non-microcode op codes. Now, modern _instruction caches_ already eliminate instruction fetch as a bottleneck, so this particular advantage of microcode has been eliminated. Clinton then utilized this microcode compiler to do an on-the-fly text compression/decompression scheme which allowed the entire text for his "FLASH" text editor to live in main memory. Since the ASCII texts for most computer program files were quite small, FLASH could edit his program code in amazingly fast time, probably 10X (??) faster than the heavyweight WYSIWYG multi-font standard text editor for the Alto. http://home.pipeline.com/~hbaker1/Micro-SPL.txt home.pipeline.com/~hbaker1/MicroSPL.ps.gz The development of a diode matrix ROM as a uniform scheme for representing random logic, and the subsequent development of branching capabilities were truly a revolution in computer design. It was then a small step to allowing the reprogramming of the microcode ROM with various schemes, including the extremely cool "writable" control store of the IBM System 360 Model 30, whose ROM was made out of specially designed _punch cards_ in which a standard IBM card punch was used to "program" the control store. Unfortunately, one then had to take each card by hand and install it into the control "memory". The high level language EULER was implemented in microcode for the Model 30 using this technique. https://en.wikipedia.org/wiki/Microcode https://research.microsoft.com/en-us/um/people/gbell/Computer_Structures__Re... https://en.wikipedia.org/wiki/Euler_%28programming_language%29 I believe that FPGA's are programmed by a serial link which performs sort of a Hamiltonian path through all of the logic. Shifting the programming bits through this long path isn't a fast process; Since FPGA's aren't expected to be reprogrammed very often, the FPGA is optimized for high performance once the program is installed, and the speed of getting the program installed isn't a major goal. At 10:50 AM 6/23/2014, Tom Knight wrote:
Almost all of the writable control store microprocessors were very poorly programmable. Most used the feature to allow bug repair of the microcode, and could barely do that. When I designed the initial Lisp machine, there was, to my knowledge, just the Alto and a modified PDP-11/45 at CMU with WCS. Neither machine had general shifter/maskers or a way to do multi-way branches on a register field.
I do agree with you, however, that the general capabilities were poorly used. We could, for example, have defined instructions on the PDP-10 which used the UUO traps. They would have been slow, but quite capable. In some sense, the ITS system calls behaved very much like instructions of this form.
On Jun 23, 2014, at 1:38 PM, Michael Greenwald <mbgreen@seas.upenn.edu> wrote:
On 2014-06-23 10:34, Michael Greenwald wrote:
On 2014-06-23 07:07, Henry Baker wrote:
FYI -- Lots of potential math applications... https://communities.intel.com/community/itpeernetwork/datastack/blog/2014/06... I'm curious whether you (or anyone here) thinks this is really so different than programmable micro-code -- e.g. writable control store?
To clarify: I meant "different" in terms of impact or use by customers.
[I know that Lisp Machines (well, Symbolics' machines until the XL- series) had this capability, and so did some vaxen (-WCS versions). I've heard that early IBM 360's or 370's had this, too, but I have no direct experience with modifying the microcode on those]. So I wonder how revolutionary will this Intel move really be? My impression (no hard data, though) is that users are often really excited by the idea, but very, very, few actually use this capability in practice.
And, I could just have the wrong impression: maybe writable control store *was* used a lot more than I believe.
Disrupting the Data Center to Create the Digital Services Economy Posted by Diane Bryant in The Data Stack on Jun 18, 2014 12:56:03 PM .... But what we find even more exciting is our next innovation in processor design that can dramatically increase application performance through fully custom accelerators. **** We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings.**** Why are we excited by this announcement? The FPGA provides our customers a programmable, high performance coherent acceleration capability to turbo-charge their critical algorithms. And with down-the-wire reprogramability, the algorithms can be changed as new workloads emerge and compute demands fluctuate. Based on industry benchmarks FPGA-based accelerators can deliver >10X performance gains. By integrating the FPGA with the Xeon processor, we estimate that customers will see an additional 2X in performance thanks to the low latency, coherent interface. Our new Xeon+FPGA solution provides yet another customized option, one more tool for customers to use to improve their critical data center metric of Performance/TCO. It highlights our commitment to delivering the very best solutions across all data center workloads and our passion to lead in the transformation of the industry to cloud services. ....
participants (7)
-
Henry Baker -
Michael Greenwald -
Mike Speciner -
rcs＠xmission.com -
Tom Knight -
Tom Rokicki -
Whitfield Diffie