LibreOffice Calc Set To Get GPU Powered Boost From AMD

darthcamaro writes "We all know that the open source LibreOffice Calc has been slow — forever and a day. That's soon going to change thanks to a major investment made by AMD into the Document Foundation. AMD is helping LibreOffice developers to re-factor Calc to be more performance and to be able to leverage the full power of GPUs and APUs. From the article: '"The reality has been that Calc has not been the fastest spreadsheet in the world," Suse Engineer Michael Meeks admitted. "Quite a large chunk of this refactoring is long overdue, so it's great to have the resources to do the work so that Calc will be a compelling spreadsheet in its own right."'" Math operations will be accelerated using OpenCL, unit tests are being added for the first time, and the supposedly awful object oriented code is being rewritten with a "modern performance oriented approach."

Re:Clarification

[Trepidity]

Yeah, and it sounds like the GPU angle is really just a hook to get AMD funding. The more important improvements will be refactoring the representation so it doesn't suck in the first place.

Re:If you need it you are doing it wrong.

[buchner.johannes]

I agree. Also, if you rewrite structured code into a "performance oriented approach", you are doing it wrong.
Write code so it is easy to understand. Then compilers should understand how to make it fast.
This can only come from people who think code is for machines. Code is for humans to read and modify.

Refactor? APU?

[JBMcB]

If the refactor is done properly I don't think the OpenCL acceleration would be necessary. Heck, 1-2-3 running on a 486 was pretty speedy.

Re:If you need it you are doing it wrong.

[BitZtream]

Thats not the issue. If your spreadsheet is SO larger that on a MODERN CPU, its slow ... you're doing it wrong.

You can make insanely complex, application like spreadsheets, without noticing 'recalc' time. By the time you get to noticing 'recalc' time, you've fucked up.

Caveat: OO.org is known to have some of the crappiest code in existence, so with the case of Calc, you don't have to make ridiculous spreadsheets to notice recalc time. GPU support won't fix the problem however as its not the math thats the issue, its the shitty logic code filled with stupid crap written by clueless devs that cause Calc to be so slow.

Re:How is it?

[MightyYar]

I don't think most people say Calc is just as good as Excel - they say that it is good enough for most people. And that is probably true. I think my boss uses excel for simple formulas and for lists. I use Excel for anything not quite worthy of a Matlab script, so OpenOffice doesn't quite measure up for me but should work fine for my boss.

Re:Clarification

[should_be_linear]

Cell should be an object even today. Their problem is probably, that Cell object contains something like string object, so creating 1 million of cells meeds million pointers and allocations to million of strings, which is performance killer. What they need to do is: instead of string, put int handler of string into cell, and have all strings in single huge allocated blob (like: StringBlobMap object). Going away from objects to improve performance is rarely good idea.

Appropriate tool use

[sjbe]

Thats not the issue. If your spreadsheet is SO larger that on a MODERN CPU, its slow ... you're doing it wrong.

It is a relatively trivial matter to make calculations on a dataset slow regardless of the tool used. I work with datasets and related calculations all the time that would make for slow calculations if you hand coded them in assembler. The mere fact that it is slow in a spreadsheet as well has nothing inherently to do with it being worked on in a spreadsheet. Now if the spreadsheet can't handle 65K rows by 65K columns then it shouldn't offer that size table as an option. But most can handle datasets that size and larger without too much trouble. For rapid data modeling and ad-hoc analysis a spreadsheet can be pretty hard to beat.

When people go wrong using spreadsheets it's usually one of a few ways. The one I see the most is when they take what should be a prototype analysis and turn it into a production tool. If you need to put a bunch of buttons and other interface tools on a spreadsheet THEN you are doing it wrong. The second is when they try to take analyzed data involving more than 3 dimensions. While it can be done it rarely is a good idea. Another I see is if they try to have more than one person working on the spreadsheet. If the dataset is truly huge or you require multi-user access or you need to interface with other applications then by all means use something other than a spreadsheet.