Slashdot Mirror
AMD Forces a LibreOffice Speed Boost With GPU Acceleration
New submitter samtuke writes: AMD processors get rated and reviewed based on performance. It is in our self-interest to make things work really, really fast on AMD hardware. AMD engineers contribute to LibreOffice, for good reason. Think about what happens behind a spreadsheet calculation. There can be a huge amount of math. Writing software to take advantage of a Graphics Processing Unit (GPU) for general purpose computing is non-trivial. We know how to do it. AMD engineers wrote OpenCL kernels, and contributed them to the open source code base. Turning on the OpenCL option to enable GPU Compute resulted in a 500X+ speedup, about ¼ second vs. 2minutes, 21 seconds. Those measurements specifically come from the ground-water use sample from this set of Libre Office spreadsheets.
As someone who has never found a use for spreadsheets anyway, I wonder whether there is anyone who uses LibreOffice spreadsheets? For what is this used, accounting?
Just wondering...
Spreadsheets are tremendously useful for a number of things. Accounting is a perfect & common use. Doing cost estimates or comparisons, doing sensitivity analysis (what happens to the answer if I change one parameter?), anything where you have a table of data and you want to analyze it, sum it, average it, etc.
This is good of course, however, whenever I see a spreadsheet program used for any serious computation, I cringe. There are far better tools out there if you require real number crunching. Think Python + Panda for instance, or R, or Matlab if you are really into commercial programs, otherwise a nice interactive web page will usually do the trick. For accounting use a real accounting program, there are plenty out there. Spreadsheet programs are the lowest common denominator that allow the sharing of table-like information, but almost universally they are the wrong tool for the job. Just in the last week, I have seen spreadsheets used for a program logic workflow, a timetable, a university course schedule, to compute an FFT, to exchange student marks, to discuss a budget (with lots of deletions and remarks), and even for a presentation. In each and every case a more suitable, open-source, freely available, multi-platform application exists.
Of course this is software that people know, so usually we have to deal with it. As a rule I accept to work with other people's spreadsheets, but I usually refuse to create one ex-nihilo, unless there is a compelling reason to. For instance I teach a course on optimisation, and I do show how the solver in Excel / {Libre,Open}Office works. I have also on occasion shown people how to use a pivot table (never use those if you can help it).
The most severe problem I see with spreadsheet is that they have their use but they are fragile. It is too easy to load an extensive table into them and inadvertently modify just one cell, potentially undoing a lot of work. This is easy to detect if your spreadsheet is small, but if it span multiple tabs and an ungodly number of rows, you will not detect your error. Of course the format of these spreadsheet is obscure, and version control is typically not supported.
Personally the worst I have seen was one spreadsheet used for the accounting of 90+ separate research projects, spanning 30,000 cells. The accountant in charge of it was the person most attentive to detail I have ever seen. She was careful and the only person using it, which made her indispensable. We put in place a year-long plan for her retirement, involving scrapping her spreadsheet, entirely replacing it with a direct interface with SAP via a php-based web page. It was many months in the making, of course this was not a trivial project but we've pulled it off. In the process we discovered a huge number of accounting errors thanks to it, typically invoices that were never billed, to the tunes of nearly one million dollars. It took us several months to correct them.
The morals of this is never, ever use spreadsheets program for non-trivial work.
"A GPU is not 500 times faster than a CPU, more like 2 or 3 times"
Just on FLOPs alone you're dead wrong. The latest and greatest E-series Xeons (V3) have barely enough power to match the 9800GTX+ - about 800 GigaFLOPs. The 980 GTX Ti is roughly 5.6 TeraFLOPs.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
http://nevernote.sourceforge.net/
here are my answers. Spreadsheets are used in several cases:
1) When you have a small-to-medium-sized dataset (100m data points) and want to do a particular set of calculations or draw a particular set of conclusions from it just once or twice—so that the time invested in writing code in R or something similar is less than the time needed just to bung a few formulas into a spreadsheet and get your results. Once you get into analyses or processes that will be repeated many times, it makes more sense to write code.
2) Similar case, when you need to work with essentially tabular database data, but the operations you're performing (basic filtering, extracting records based on one or two criteria, just handing data from one person to the next) are either so simple or will be repeated so rarely that a MySQL database is overkill and just emailing a file back and forth is easier.
3) When you are working with data as a part of a team, and certain members of the team that are specialists in some areas related to the data, or (for example) members of the team that are doing your data collections, aren't particularly computationally expert. Spreadsheets are hard for laymen, but it's doable—a dozen or two hours of training and people can get a general, flexible grasp of spreadsheets and formulae. It takes a lot longer for someone to become basically proficient with R, MATLAB, MySQL, Python, etc., and you really want those specialists to just be able to do what they do to or with the data, rather than focusing their time and effort on learning computational tools. Spreadsheets are general purpose and have a relatively shallow learning curve relative to lots of other technologies, but they enable fairly sophisticated computation to take place—if inefficiently at times. They're like a lowest-common-denominator of data science.
We use Spreadsheets all the time in what we do, mostly as a transient form. The "heavy hitting" and "production" data takes place largely in MySQL and R, but there are constant temporary/intermediate moments in which data is dumped out as a CSV, touches a bunch of hands that are really not MySQL or R capable, and then is returned in updated form to where in normally lives.
STOP . AMERICA . NOW
That's funny because spreadsheets actually came from accounting. The first spreadsheet wasn't created by a geek or a programmer, it was created by an accountant. It's simply the electronic form of something that was already being done on paper.
Spreadsheets not suitable for finance or accounting?
That's where they came from.
A Pirate and a Puritan look the same on a balance sheet.
"Or fewer"
Does the name Pavlov ring a bell?
Ok, it's fantastic that LibreOffice spreadsheet calculations are faster now. But what good is that when the rest of it is so goddamn bloated?
Because speeding up spreadsheet calculations matters a lot to some users?
"So goddamn bloated" is a subjective term. I use LibreOffice regularly and it works for me. Pretty damn impressed in fact. Sure, faster is already better but your exaggeration is wild.
When all you have is a hammer, every problem starts to look like a thumb.
I just ran the test on both MS Office and LibreOffice. MS Office was 5.6x faster than LibreOffice with OpenCL turned off. MSOffice score 9705.51206654159, LibreOffice score 54296.0680468936. LibreOffice scored 218.087068492849 with OpenCL turned on. Hardware Core i3 2100, 8GB RAM, nVidia GTX 770 .
I honestly thought that we'd got away from this 500x nonsense a few years ago. I would suggest that AMD is one source for the information that 2-3 is more reasonable. AMD, Qualcomm, Khronos, any of the members of the OpenCL committee you talk to as well as NVIDIA insiders if you catch them at a conference. I gave multiple public talks countering any factors over about 10 when I worked at AMD, which were approved by management.
Just think the raw numbers through. The GPU has, say, 32 cores. The CPU ALSO has multiple cores. Don't count them, then you're cheating. So let's say we have 8 CPU cores there. Each CPU core has two SSE units or one AVX unit, to be conservative. That core is doing 8 ALU ops per cycle per core. So you have 64 ops per cycle. The clock rate is 3x the GPU so let's call it 196 ops per GPU cycle. The GPU had 32 cores. Each GPU core can do 64 ops/cycle (fair number for GCN). So you have 2048 ops/cycle on the GPU. 2048/196 is roughly 10. That's your peak - now you add in divergence costs on the wide GPU SIMD units (which statistically will hit you much earlier than with the CPU's narrow SIMD units), count the tiny GPU caches leading to more cache misses than the CPU and you can see why that factor of 10 invariably drops to 2 or 3x.
More honestly you're looking at a factor of 10 or so for ALU throughput, and 10 or so for memory throughput - and those are not multiplicative. In real use cases 2-3 is about right when comparing against well-optimised CPU code.
If there is a 500x speedup appearing with Libreoffice here, and the likelihood is that that is somewhat cherrypicked anyway, then what we are seeing is the difference between someone optimizing code and someone else not doing so. There is every reason to think the original code was only lightly optimized, not parallel, not vectorized or some set of the above.