Unless the software has been specifically designed with GPU processing power in mind, GPU accelerated instances will be about the same performance as regular commodity server instances, only at a higher price.
I'm willing to gamble and say that the bottleneck of any algorithm, medical or not, imaging or not is the rate at which you can throw data at the CPU, and the number of cores, and the clock rate.
Get some fast CPUs, Insanely fast RAM, blindingly fast striped/mirrored storage, and do it that way.
I suspect that you'll probably find that running on "the cloud" is actually counter-intuitive, or at least counterproductive, as many cloud service providers don't tune their storage backends to cater for high performance computing, but more to providing a little bit of IO to the masses.
I think you'd be better off with owned dedicated hardware, that way, you can spend more time and money in efficiently tuning the hardware stack to match your software stack. Any cloud service provider (including Amazon) will give you some trade offs and compromises.
Oh, and don't forget about not putting all your eggs in one basket. What happens when Amazon goes offline, and nobody can examine any X-Rays, or the poor schmuck who put a heart monitoring application on Amazon Cloud instances, and Amazon went offline in a massive outage.
Aside from the compromises of cloud hosting, the problems of being redundant and resilient to provider outages, not putting critical infrastructure on the cloud, there's other questions surrounding the architecture of your application itself.. Will it scale linearly?
By benching a GPU-like implementation against Cloud Server instances, you can see huge FPS differences [1, 2] for operations on large (e.g., CR) images. However, on the other hand, the GPU can be occupied with a lot of memory and therefore delaying and giving continuously dropouts. Therefore, a Cloud Server solution could be more stable with not as many dropouts and a smoother feeling but with lower FPS.
[1] Zhang, Lequan, et al. "A high-frequency, high frame rate duplex ultrasound linear array imaging system for small animal imaging." IEEE transactions on ultrasonics, ferroelectrics, and frequency control 57.7 (2010).
[2] Miguez, D., et al. "A technical note on variable inter-frame interval as a cause of non-physiological experimental artefacts in ultrasound." Royal Society open science 4.5 (2017): 170245.
发布评论
评论（2）
除非软件专门设计时考虑了 GPU 处理能力，否则 GPU 加速实例的性能将与常规商品服务器实例大致相同，只是价格更高。
我愿意打赌，任何算法的瓶颈，无论是否是医学的，无论是否成像，都是你向 CPU 发送数据的速率、核心数量和时钟频率。
获取一些快速的 CPU、快得惊人的 RAM、快得令人眼花缭乱的条带/镜像存储，然后就这样做。
我怀疑您可能会发现在“云”上运行实际上是违反直觉的，或者至少是适得其反的，因为许多云服务提供商不会调整其存储后端来满足高性能计算的需求，而更多的是提供向大众提供一点点IO。
我认为您最好拥有自己的专用硬件，这样您就可以花费更多的时间和金钱来有效地调整硬件堆栈以匹配您的软件堆栈。任何云服务提供商（包括亚马逊）都会给你一些权衡和妥协。
哦，别忘了不要把所有鸡蛋放在一个篮子里。< /a> 当亚马逊离线时会发生什么，没有人可以检查任何 X 射线，或者可怜的笨蛋放了 心脏监测应用程序位于亚马逊云实例上，亚马逊在大规模中断中离线。
除了云托管的妥协、冗余和对提供商中断的恢复能力、不将关键基础设施放在云上的问题之外，还有围绕应用程序本身架构的其他问题。它会线性扩展吗？
我打赌不会。
Unless the software has been specifically designed with GPU processing power in mind, GPU accelerated instances will be about the same performance as regular commodity server instances, only at a higher price.
I'm willing to gamble and say that the bottleneck of any algorithm, medical or not, imaging or not is the rate at which you can throw data at the CPU, and the number of cores, and the clock rate.
Get some fast CPUs, Insanely fast RAM, blindingly fast striped/mirrored storage, and do it that way.
I suspect that you'll probably find that running on "the cloud" is actually counter-intuitive, or at least counterproductive, as many cloud service providers don't tune their storage backends to cater for high performance computing, but more to providing a little bit of IO to the masses.
I think you'd be better off with owned dedicated hardware, that way, you can spend more time and money in efficiently tuning the hardware stack to match your software stack. Any cloud service provider (including Amazon) will give you some trade offs and compromises.
Oh, and don't forget about not putting all your eggs in one basket. What happens when Amazon goes offline, and nobody can examine any X-Rays, or the poor schmuck who put a heart monitoring application on Amazon Cloud instances, and Amazon went offline in a massive outage.
Aside from the compromises of cloud hosting, the problems of being redundant and resilient to provider outages, not putting critical infrastructure on the cloud, there's other questions surrounding the architecture of your application itself.. Will it scale linearly?
I bet it won't.
通过针对云服务器实例对类似 GPU 的实现进行基准测试，您可以看到巨大的 对于大图像（例如、CR）操作的 FPS 差异 [1, 2]。然而，另一方面，GPU 可能会占用大量内存，从而导致延迟并导致连续丢失。因此，云服务器解决方案可能会更稳定，掉线次数更少，感觉更流畅，但 FPS 较低。
[1] 张乐泉，等． “一种用于小动物成像的高频、高帧率双工超声线性阵列成像系统。” IEEE 关于超声波、铁电体和频率控制的交易 57.7 (2010)。
[2] 米格斯，D.，等人。 “关于可变帧间间隔作为超声中非生理实验伪影的原因的技术说明。”英国皇家学会开放科学 4.5（2017）：170245。
By benching a GPU-like implementation against Cloud Server instances, you can see huge FPS differences [1, 2] for operations on large (e.g., CR) images. However, on the other hand, the GPU can be occupied with a lot of memory and therefore delaying and giving continuously dropouts. Therefore, a Cloud Server solution could be more stable with not as many dropouts and a smoother feeling but with lower FPS.
[1] Zhang, Lequan, et al. "A high-frequency, high frame rate duplex ultrasound linear array imaging system for small animal imaging." IEEE transactions on ultrasonics, ferroelectrics, and frequency control 57.7 (2010).
[2] Miguez, D., et al. "A technical note on variable inter-frame interval as a cause of non-physiological experimental artefacts in ultrasound." Royal Society open science 4.5 (2017): 170245.