![]() ![]() Throwing random code onto any accelerator, Alveo or otherwise, does not generally give you optimal results. It’s important to approach acceleration with a firm understanding of how and when to apply external acceleration to a software algorithm. In general, Alveo cards are useful for accelerating algorithms with lots of “number crunching” on large data sets - things like video transcoding, financial analysis, genomics, machine learning, and other applications with large blocks of data that can be processed in parallel. Both approaches have mathematical limitations, but both also benefit from more resources (although to different degrees). Through parallelization we are attempting to either process more data in the same amount of time, or the same amount of data in less time. Rather than more compute resources speeding up the execution of a single task, more compute resources allow more computation in the same amount of time.īoth of the laws frame the same thing in different ways: to accelerate an application, we are going to parallelize it. Gustafson’s Law re-frames the question raised by Amdahl’s Law. So, let’s abandon metaphor and roll up our sleeves.Īgain, S_latency represents the theoretical speedup of a task, s is the speedup in latency of the task benefiting from parallelism, and p is the percentage of the overall task latency of the part benefiting from improvement (prior to the application of the improvement). FPGAs combine the parallelism of a GPU with the low-latency streaming of a domain-specific architecture for unparalleled performance.īut, as the joke goes, even a Ferrari isn’t fast enough if you never learn to change gears. But for you, this is the model for Alveo™ acceleration. For the tour guide in our increasingly tortured metaphor, this is fantasy. Train after train, each one full, making all the stops along the way (and with full flexibility to bulldoze and change the route as needed). On their dollar, with the permits pre-approved. If only the city would allow you to build a monorail. It scales very well - until, that is, your fuel bills start to add up, there’s a traffic jam in front of the fountain, and wouldn’t you know it, the World Cup is coming to town! Over time, your fleet of buses can expand and you can get more and more people through the tour. The answer is a tour bus! It might have a lower top speed and take much longer to load and unload than your earlier sports car idea, but you can transport many more people - much more data- through your algorithm. There’s a limit to how fast your car can go (even the sports model), so how can you scale? This is the problem with CPU acceleration. But, as your popularity grew, more and more people started to sign up for the tours. Given your application space and your algorithm, you started small: your tours fit into one car, and every year you would buy a new one that was a bit bigger, a bit faster, and so on. This set of things you must do is your algorithm. Along the way, you are tasked with teaching your wards a specific set of facts about your city, and you must hit a particular set of sights (and shops - you have to get paid, after all). Your city may be large or small, dense or sparse, and may have specific traffic rules that you must follow. Imagine that you have been given the job of giving tours of your city. Rather than dive immediately into the API, especially if you don’t have much experience with acceleration, let’s start with a simplified metaphor to help explain what must happen in an acceleration system. Full source for the examples in this article can be found here: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |