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."

Comments

If you need it you are doing it wrong.

[140Mandak262Jamuna]

If your spreadsheet needs a gpu to speed up calculations, you are probably misusing spreadsheets. I know most accountants love the spreadsheet and they make insanely complicated things using spreadsheets pushing it far beyond what these are designed to do. But if you have a spreadsheet that needs this much of cpu time to recompute, you should probably be using a full fledged data base with multiple precomputed indexing.

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

[Russ1642]

Custom database applications are expensive and inflexible. Stop trying to tell people what they can't do with a spreadsheet.

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.

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

[Anonymous Coward]

Spreadsheets are all rectangular. That's pretty inflexible. Show me a triangular spreadsheet and then we'll talk.

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

[Kenja]

Pivot Tables can have three or more axis.

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:If you need it you are doing it wrong.

[symbolset]

So you haven't heard of Microsoft Excel for supercomputers then? What about the Excel RPG?

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

[geminidomino]

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.

Indeed. You really shouldn't need to have to get a gaming GPU to run a spreadsheet. Hopefully

"and the supposedly awful object oriented code is being rewritten with a "modern performance oriented approach".

means they intend to address that part, too, and the crappy headline is just being whiz-bang. If they're dumb enough that they think throwing inappropriate hardware at the problem is a solution... well, they're too far from the vicinity of the US Pacific coast...

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

[gstoddart]

you should probably be using a full fledged data base with multiple precomputed indexing

Well, you can put together a spreadsheet in a few hours.

What you're describing is likely months of custom development and design, and a whole new thing to maintain.

Spreadsheets are popular because they're easily deployed, don't require any extra licensing, and the people who know how to use them can likely do things with them that some of us would be astounded at.

I know people who use spreadsheets for pretty much everything, because it's available to them readily, and they've been using them for a long time.

It's all well and good to suggest that they use a full-fledged database -- but in reality, they can probably get something useful in a few days for a fraction of the cost.

It sounds like in this instance, the code was just horribly inefficient.

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

[robthebloke]

I agree. Also, if you rewrite structured code into a "performance oriented approach", you are doing it wrong.

Nonsense. One of the joys of C++, is the lack of reflection. This tends to lead apps down the route of wrapping everything into an 'Attribute' class of some description, and wiring those attributes together using a dependency graph. The problem with this (very clean OOP) approach, is that it simply doesn't scale. Before too long, this constant plucking of individual data values from your graph, ends up becomming a really grim bottleneck. If you then run the code through a profiler, rather than seeing any noticeable spikes, you end up looking at an app that's warm all over. If you're in this situation, no amount of refactoring is going to save the product. You're only option is to restructure the

The "performance oriented approach" is the only approach you can take these days. Instead of having a fine OOP granularity on all of your data, you batch data into arrays, and then dispatch the computation on the SIMD units of the CPU, or on the GPU.

Then compilers should understand how to make it fast.

Uhm, nope. Sure, if you happen to have 4 additions right next to each other, the compiler might replace that with an ADDPS. In the case in point however, you'll probably expect a generic node to perform the addition on single items in the table. As such, your "addTwoTableElementsTogether" node isn't going to have 4 floating point ops next to each other, it will only have one. Compilers cannot optimise your data structures. If you want to stand a chance of having the compiler do most of the gruntwork for you, you actually have to spend time re-factoring your data structures to better align them with the SIMD/AVX data types. Some people call this a "performance oriented approach".

This can only come from people who think code is for machines. Code is for humans to read and modify.

Bullshit. This can only come from experienced software developers who understand that the only approach to improving performance of a large scale app, is to restructure the data layout to better align it with modern CPUs. There is *NOTHING* about this approach that makes the code harder to read or follow - that's just your lack of software engineering experience clouding your judgement.

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

[gstoddart]

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.

Except code can end up going through so many layers of abstraction, with some of those layers doing things in the most inefficient manner possible because terrible assumptions were made.

Sometimes, you need to plan for both performance and well structured code -- or you can end up writing garbage which makes heavy use of code which does extremely stupid things.

Most people nowadays are so far removed from knowing what's happening close to the metal that they don't often realize you're essentially running thousands of lines of code to do something trivial as heavyweight libraries wrap everything up.

At a certain point, someone needs to be able to determine if the code is the reason your stuff is so damned slow, and if the bloat has gotten out of hand. Sometimes, you really do need to look at your own optimizing.

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

[jellomizer]

Spreadsheets are good for "throwaway applications" you need to do these calculations fast or gather data, and after a few weeks you don't need it anymore.
If you are going to be following a process with a fairly rigid data sets. You are going to be better off spending the time and money to make a real application with a real database with it. That way the rigidness is to your favor to prevent incompatible creep, and allow for future data gathering abilities.

Using Spreadsheets for your application needs works but it is very flimsy and over the long run you will be spending a lot more time fixing your mistakes (say a bad sort) Or a mistime change and save, or just the wrong click of your mouse you messed up a lot of data.

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

[tibit]

Probably they had some developer mobility betwen Star Division and SAP :/ /me ducks and runs

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

[squiggleslash]

If the tool you're using isn't an exact fit for the application you need it to do - though only because of speed, but it does it anyway, you should use another tool even though...

1. You're not familiar with it
2. It's not your area of expertise
3. The lack of suitability means you're wasting whole minutes a day. However, you'll need to hire a programmer or else take a course likely lasting months to get the skills needed to use the alternative tool.
4. Your tool, the one that was designed to be easy for someone in your profession to make use of, does, ultimately, do the job you need it to do.

No.

No, no, no, no and again no. You're a developer. Good for you. Good for me too. But our jobs are not to make patronising unrealistic suggestions to smart people who don't have our particular skillset. Our job is to make it easier for other people to do their jobs. Telling them to hire programmers or run off and learn our skills isn't "making it easier".

If the only thing wrong with the way they're doing is that their computer runs slow when doing it, the solutions we should be presenting are the easiest. Upgrades and better underlying office suite code. Good for the LibreOffice people that that is what they're doing.

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

[Chelloveck]

Example: which way do you iterate through an array to apply an operation to each element? Well, _if_ you happen to have iterated through it recently, doing it backwards might be lot faster then doing it forwards due to cache locality. I'd love to see a compiler managing to take advantage of that.

I'd trust the compiler to do it a whole lot more than I'd trust the programmer. Things like cache locality are going to be very dependent on machine architecture. You should not be optimizing for machine architecture on anything that's intended to be the least bit portable. Yeah, you made it faster on your machine, but what about your user's? Will it have the same cache size? The same line size? Hell, will it even have the same word size and endedness? To the extent that any of this should be optimized, it's the compiler's job to do it.

Be sure to pick your algorithms carefully. Know the complexity, and don't choose an O(n^2) algorithm when there's an equivalent one that's O(n). But optimizing hardware-level stuff? Unless you get to pick the hardware, don't do it. Every optimization you make on your machine is likely to be a pessimization on someone else's. The compiler knows the architecture it's compiling for (well, usually...) and is in a much better position to make such performance decisions.

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

[gstoddart]

You're a developer. Good for you. Good for me too. But our jobs are not to make patronising unrealistic suggestions to smart people who don't have our particular skillset. Our job is to make it easier for other people to do their jobs. Telling them to hire programmers or run off and learn our skills isn't "making it easier".

This. A thousand times this.

Somewhere along the way, our industry has developed a collective mentality "we're smarter than you, and we will give you what we want even if we have no idea of what you need".

Once you get a little further removed and realize that the stuff we're writing/supporting is intended to help the people who do the real, bread and butter parts of the business -- you start to realize if we're an impediment to them, it's worse than if we weren't there at all.

They're not interested in some smug little bastard looking down his nose at them because they couldn't possibly do what he does. They're interested in getting their stuff done as quickly as possible.

I can tell you there is nothing more frustrating and counterproductive than some kid straight out of school who thinks the world needs to bow at his feet and stand aside to allow him to tell them how they should do things. Sadly, I've also met developers who have been in the industry a long time who still act like that.

In many industries, the people who do the real work of the company have highly specialized knowledge, and software is just a tool. And that tool is either helping them get stuff done, or frustrating the hell out of them.

Acting like we know better than they do (when we in fact know nothing at all about their domain expertise) is at best condescending, and at worst an impediment and a liability.

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

[orlanz]

For many of the situations that the parent is talking about, this is not true. Spreadsheets with massive business logic are extremely expensive and very inflexible, more so than DB apps. Just no central group/organization reviews, audits, and tallies these costs like they do for developed applications. Therefore, people assume the spreadsheet is cheaper. Do actual IT audits where these things fall into scope... and you quickly realize just how ridiculously risky the entire deck-of-cards-business is running.

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

[garyebickford]

Lotus had a cool object-based spreadsheet system on the Next computer, called Improv. Improv attempted to redefine what spreadsheets were and how they worked, and once you got used to it, it was great. The basic principle was separation of data, views, and formulas (was this pre-figuring MVC?), and individual sheets could be any size - I'm not sure about 'triangular' per se though.

But alas, Improv never sold well on either NextStep (although it was very popular amongst financial modeling folks, and sold a lot of Nexts) or Windows 3.1 (W31 was probably way underpowered for the job). According to the Wiki article above, there are some descendants still in use.

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

[gstoddart]

I still don't see what kind of an easy-to-do-in-a-spreadsheet kind of a business "application" would take months or years to do data storage/management in SQL...

Who said "easy to do"? I've seen stuff done in spreadsheets which evolved over years, and I know people who do stuff in Excel that leaves my head spinning.

You'd be amazed at the wacky stuff people can do in Excel. Many of the things I've seen done with it over the years probably evolved over a long time, but the end result is something which isn't trivial to replace without some pretty major investment.

It's just that you can start working in it and incrementally improve it to the point that it's almost a full on application in its own right.

Don't make the mistake of thinking everything people do in Excel is easy to do and you could quickly knock together a replacement. There's a lot of functionality in Excel, and those who have been using it a long time can do some pretty sophisticated things.

You make not like Excel, but don't go around thinking everything which can be (and is) done in Excel is trivial stuff. There's surprising amount of logic and conditional stuff you can build into it that most of us don't even know is there.

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

[K. S. Kyosuke]

Spreadsheets are all rectangular.

That's not necessarily correct. In its core, a spreadsheet is a DAG of computation-performing nodes. The presentation style is merely a historical happenstance.

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

[jeremyp]

It really bugs me when people conflate OO with anti-pattern x. In what world does OO mean the same as "use lots of threads"?

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

[Mr Z]

I'd like to see you implement an AND gate with just XORs and NOTs. Use as many as you like... ;-)

In all seriousness, you can build all other gates from NANDs. Or from NORs. In fact, that's how the Cray 1 was built, apparently. Tons and tons of ECL NAND gates.

Clarification

[UnknowingFool]

From the article:

Calc is based on object oriented design from 20 years ago when developers thought that a cell should be an object and that creates a huge number of problems around doing things efficiently.

The problem isn't that Calc is object-oriented but was designed such that many things depended on the spreadsheet cell.

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: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.

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:Refactor? APU?

[Capt.DrumkenBum]

486, Bah humbug.
I ran Lotus Symphony on a 286. It was the job that convinced me to go back to school for a career in IT.
Also, get off my lawn.

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:the problem with OpenOffice

[Bert64]

And despite all this, and the fact they target far fewer platforms, MS still puts out an extremely buggy application, with poor forwards/backwards compatibility, virtually no intentional interoperability with anything else, and major inconsistencies between the 2 platforms that they do support.

The only difference with MS bugs is that users have come to expect them and know the workarounds. Ask anyone who uses ms applications heavily and they will have all kinds of kludgy hacks memorised to get around functionality which doesn't work correctly.

Why not Javelin?

[jabberw0k]

Spreadsheets lead the inexperienced, down the garden path of "Oh, this looks easy..."

At some point you think, Oh, let me just sort this column. And you fail to realize some formula on sheet 27 presumes a linkage between column C on sheet 5 and column F on sheet 13. So now your entire model is garbage.

In all these decades, hasn't anyone resuscitated Javelin with its time-oriented models, where what looked like a spreadsheet was just a view of the underlying model? "Javelin understands the arrow of time" -- 1985 slogan

Right (Re:If you need it you are doing it wrong.)

[WillAdams]

Actually, the UI for Lotus Improv was quite nice and won some awards.

Its (spiritual) successor, Quantrix Financial Modeler seems to be selling well enough, even w/ a $1,495 price point.

I wish that Flexisheet (an opensource take on this sort of thing) would get more traction.

Live a day in my shoes

[sjbe]

If your spreadsheet needs a gpu to speed up calculations, you are probably misusing spreadsheets.

Or it just means that you have some pretty complicated calculations. More computing horsepower never hurts.

I know most accountants love the spreadsheet and they make insanely complicated things using spreadsheets pushing it far beyond what these are designed to do.

I happen to be an accountant as well as an engineer. What pray tell do you think spreadsheets were designed to do? (hint - it involves rapid data modeling) They aren't much use if the only problems you solve are toy problems. Plus they require relatively little training to use effectively. Someone can be trained to solve real world problems MUCH easier than with most other tools. Most of the problems I'm asked to solve are ad-hoc investigations into specific questions. I shouldn't need a four year degree on Comp-Sci to accomplish a bit of data modeling.

But if you have a spreadsheet that needs this much of cpu time to recompute, you should probably be using a full fledged data base with multiple precomputed indexing.

I use some rather complicated spreadsheets. A database would be of no advantage whatsoever for 99.9% of what I use a spreadsheet for. Furthermore a database would be a lot slower to develop, harder to update, and require significant user interface development. If I'm crunching sales data or generating financial projections a spreadsheet is almost always the easiest and most useful tool for the job.

Databases come into the picture when: A) other applications need to interface with the data, B) the dataset becomes truly enormous, or C) the number of dimensions in the data exceeds 2 to 3. Sometimes I use databases. Most of the time they would be a waste of money, brains and time. Frequently when I actually need a database I'll create a mock up of the tables and calculations on a spreadsheet first which lets me work out the structure much more easily.

While it is certainly possible to use a spreadsheet inappropriately, a spreadsheet should be able to handle a rather large amount of data and calculations before it chokes.

Re:Live a day in my shoes

[tibit]

You should know basic programming upon exiting high school. Yeah, the sad state of K-12 curricula are something to lament another time.

So, what tool do you use to diff your spreadsheets? How do you ensure that there isn't a bug in a column of otherwise "identical" formulas? How do you ensure that whatever column you've filled with imported data still has this imported data in it? Where's your log that shows that you haven't unlocked some cells by mistake and messed them up "subtly"?

Spreadsheets provide a semblance of productivity and an illusion of efficiency. Once you go from fucking about with it to being serious, spreadsheets are a gift from hell. It takes very little to audit a couple pages of code. Good luck auditing a spreadsheet that has tens of thousands of cells filled with formulas.

Once you use spreadsheets in an auditable and professional way, you end up with a VBA script that starts with a blank slate and does everything you'd otherwise do by hand. At that point you may as well write it in Python and generate the xlsx, ods or maybe just pdf for printing/visualization.

Most people, evidently yourself included, use spreadsheets like if they were a magical object that's guaranteed to read your mind and do exactly what you want. It's all too easy to fuck up if you're not careful, and unfortunately Excel by default doesn't come with policies that prevent you from fucking up. How one earth can anyone be sure that your projections aren't just line noise? Excel promotes development with no process, where there's no assurance about anything. That's one little reason why our financial industry is so fucked up. People trust Excel results, no questions asked.

Re:Live a day in my shoes

[sjbe]

You should know basic programming upon exiting high school.,

Programming has been a significant part of my job in years past. You have no idea what my background is.

So, what tool do you use to diff your spreadsheets? How do you ensure that there isn't a bug in a column of otherwise "identical" formulas?... blah blah

There are a multitude of ways to error check spreadsheets. RTFM. There also are plenty of tools to replicate formulas (or formatting or numbers). Furthermore you are inappropriately applying data modeling techniques that typically do not apply to what people need out of a spreadsheet. Spreadsheets aren't the right tool for every job but they are a great tool for many.

Spreadsheets provide a semblance of productivity and an illusion of efficiency.

Spoken well and truly like someone who doesn't do my job but thinks they know how to do it better than me. Seriously, you have no idea what you are talking about here. For what I use a spreadsheet for there simply is not a better tool available. If there were I would use that instead.

It's all too easy to fuck up if you're not careful, and unfortunately Excel by default doesn't come with policies that prevent you from fucking up.

The specific problems are different but there is NO programming tool that prevents mistakes.

That's one little reason why our financial industry is so fucked up. People trust Excel results, no questions asked.

No they don't and if you actually knew anything about the financial industry you would know that. You seem to have little idea what it is they are modeling and even less idea what level of precision is required for their models. People in finance use spreadsheets because they are GOOD ENOUGH for modeling the data they need. Many of them are perfectly capable of creating a database or using Matlab should the need arise but for their specific needs a spreadsheet is the best available tool for the job. Spreadsheets are easy to use, can provide a perfectly satisfactory tool for ad-hoc analysis (most of what they do), and they cost a reasonable amount of money.

Re:the problem with OpenOffice

[Bert64]

It's well documented, you can find examples all over google, eg:

http://hints.macworld.com/article.php?story=20111230095628470

Infact there are many people who use libreoffice to open and convert corrupted (or very old) files which are making msoffice crash, libreoffice is far more tolerant of unexpected data in the input files as unexpected data is a given when attempting to reverse engineer undocumented formats.

And to give one personal example, msoffice 97 onwards had a bug in the macro function whereby the line counting function ignored lines with bullet points, so we had an extremely kludgy macro which counted the lines and then iterated through looking for bullet points and increased the line count accordingly... MS decided to fix this particular bug in a "security update" for office 2003, but then reintroduce the bug in 2007... Obviously this kludgy macro catastrophically broke the day that patch got rolled out.
I could understand if it broke going from 2003 to 2007, but not for what is supposed for be a security update to change something like that.

Also even moving files between the exact same patch release of msoffice on different machines can cause problems with formatting, as it reformats depending on available fonts and printer settings.

Re:Libre Office Calc isn't that good.

[gstoddart]

An unsuitable tool might do as a temporary substitute, but long term you really want to use an appropriate tool for the job.

Look at it this way ... the 40-ton truck in your metaphor (Excel or something like it) is provided to everyone in the company from day 1. From the receptionist to the CEO, everyone gets a 40-ton truck. You know that everyone can carry the same stuff in their 40-ton trucks because they are all pretty much the same.

Furthermore, before you even leave highschool, people tech you how to use that 40-ton truck.

Now, imagine that you need to solve a new problem, which is shockingly similar to problems you've already solved.

So you could go through 6 months to a year of fighting to get someone to help you build a station wagon with a baby seat and tinted windows, because the 40-ton truck is overkill. And you need to convince someone help pay for the station wagon since they didn't budget for one of those.

After you've gone through all of that process, the station wagon has never materialized, the cost overruns make it look like you're buying a gold-plated Rolls Royce, but the engine is still a cardboard mock-up, and the people building it for you have forgotten to include headlamps, windshield wipers, turn signals, seatbelts, and a speedometer. But if you will submit a change order to have them build those, you can wait another period of time (and even more money).

Or, you take the 40-ton truck to do what you need, take a little extra time to find a parking spot, and in the end you've got something which covered your needs in a shorter period of time and for no extra costs except your time. You can get to the grocery store and back in a few hours, and you're done.

That is why people use spreadsheets and don't always jump straight for the custom application.

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.