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.
I wonder if a spreadsheet is really the right tool for computations that take several dozens of seconds on modern hardware, even without GPU acceleration. I am inclined to think it is not.
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.
I like to play with orbital mechanics - "hard science fiction" scenarios such as orbital catapults and the like, and spreadsheets are a decent way to quickly run the numbers for a large range of parameters. For example, a few hundred mile tumbling-cable space elevator around the moon could grab payloads directly off the surface and launch them on Hoffman transfer orbits to Mars or Venus, without ever exceeding a fraction of a g acceleration.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
You can use them for about anything where you need to keep track of some data and a database is overkill. Back in the day, I had a teacher using spreadsheet software for a grade book that could automatically sum the scores and apply a curve instead of having to do it all by hand. My brother would keep track of online auction data in a spreadsheet. I've seen a few people use them to make a quick and easy chore list for their kids. They're also useful for kids who want to make some simple graphs or charts for a school report. There are probably dozens of other ways that people use them on a regular basis that I might never imagine myself.
They also told me how much I should be offering for junk components in Eve if I was still to turn a profit on reprocessing. I've not played the game for years, but spreadsheets are a pretty important tool. They also tell you which ore is most profitable to mine.
Any place where you have to take a number of observations and perform statistical analysys on the data. A lot of yield analysis in agriculture is done this way; remember, agriculture was the mother of statistics. Then you branch out to the other hard sciences and a spreadsheet is the right tool for the job. Once you learn the limitations of the tool (precision, range, accuracy) it can slash effort to a fraction of other methods.
Modern GPUs can be hundreds and even thousands of times faster than CPUs at highly parallelizible simple math. That's why things like bitcoin mining, which are exactly that were done on GPUs before they moved to even more specialized hardware.
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.
AMD engineers have contributed OpenCL code which is an open standard that can run on many different accelerators (some not even GPUs). this is distinctly different from CUDA which only works with Nvidia stuff.
Anons need not reply. Questions end with a question mark.
GPUs are optimized for massive parallelism and can be much faster than CPUs that aren't for tasks fitting them. They can also be much slower if the task doesn't fit them. 500x faster than a normal processor is well within a reasonable speedup range.
But I also agree partially with you - the reason we see such a huge speedup in this case is probably because the CPU comparison point is running badly optimized code. With a few exceptions reports of huge speedups for GPU computing is because the CPU is feed with severely suboptimal code.
Evilly forced. They're going against the natural order, as defined by Intel's compiler.
Intel has gone to great lengths to keep AMD as slow and uncompetitive as possible. Obviously there must be some greater good reason, like demonic invasion or zombie apocalypse.
I don't suffer from insanity, I enjoy every minute of it!
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
I once wrote a spreadsheet to calculate and graph the collision rates on various hash table algorithms over various use cases. Don't dis spreadsheets.
Depends on what you mean by "faster." If you mean clock frequency, then perhaps. Also perhaps if you mean an individual core of a CPU vs a core of a GPU.
In this sense, it's the time to perform massively parallel instructions. GPUs are generally hundreds of times faster than CPUs for such calculations. Part of this is because a CPU can have a few cores, but a GPU generally has thousands of floating point units. The other part is that CPUs are general purpose central processors while GPUs are very specialized to optimize them for specific kinds of tasks.
Think of it like a CPU is 4 guys with Swiss Army Knives while a GPU is a team of 1,600 guys each with a battery powered, professional screwdriver. Guess which one's faster at screwing 1,600 wood screws into 400 posts for a building. Now guess which is faster at cutting a traced outline on a single piece of paper.
http://www.nvidia.com/object/w...
I'm not sure where you are getting this. For repetitive math a CPU will be doing something like 4 instructions per clock cycle while a GPU will be in the low thousands. Also AMD tends to have more parallelism running slower than NVidia so for the right kinds of computations it is even better.
My opinion of Apple and Apple products has changed. Not that I'd ever buy an Apple product, but I went with a non-technical friend to an Apple store; she wanted me to go along when she bought a new Macbook. I was amazed at the high level of service and the extent of the support structure. She paid twice as much total for her Macbook as I paid for my Asus Zenbook (she bought the training and extended support which added $400 to the total), but she has a level of comfort that is rather high for a non-technical user.
I was pretty impressed, and I can see why people might want to buy the Apple brand. They don't care about the closed design and complete control by Apple. They want to have a place to go to get help and support, of a type and level that they can understand and feel good about. This particular Apple store was packed with people and always is. There's a reason, and I learned what it is that day.
There are entire branches of computing and computing hardware dedicated to this idea. Before Linux Journal gave up on the idea of dead tree publication, you could always see the ads for multi-GPU compute machines (usually on the back cover).
3D rendering is all about heavy duty math.
Then there's PureVideo/VDPAU and VAAPI. The idea that dedicated silicon can do things better than a general purpose CPU is a pretty old (and obvious) one.
A Pirate and a Puritan look the same on a balance sheet.
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?
I may be completely wrong but no features have been added in ages, no code updates etc. etc.
Does anyone know what's going on?
Also, would Base benefit from this GPU enhancement?
*** Don't be dull.***
...the reason we see such a huge speedup in this case is probably because the CPU comparison point is running badly optimized code...
Actually, it's because spreadsheet problems tend to be "embarrassingly parallellizable".
When all you have is a hammer, every problem starts to look like a thumb.
While the intended workflow for data crunching on the desktop is typically served by R/Python/Julia among others, there are times you have to do some processing for a huge amount of data for a spreadsheet you have open in front of you. This is where AMD/LibreOffice will shine and this is a good motive to buy AMD and LibreOffice.
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 .
No it really doesn't. Just because NVIDIA's marketing department calls something a core does not make it comparable to a CPU core - notice that even AMD's marketing is being more up front about this by talking about an APU having some number of "Compute units" which is the sum of the CPU cores and the GPU CUs.
Even if the GPU did have thousands of cores, though, that does not affect the numbers I discussed. Instead of having 32 cores with 64 ops per cycle you just get 32*64 cores with 1 op per cycle. You still only have a factor of 10 on ALU throughput.
You make a good and valid point, but the people who are buying Apple for comfort will buy a new one every few years because that maintains their comfort level.
I learned, with my visit to the Apple store, that buying Apple for most people is not about
1) Being able to tweak and customize (in general; yes, you can do that if you know how)
2) Worrying about cost[1]
It is much more about
1) Comfort and assurance
2) Style
3) Relative ease of use, and lots of hand-holding.
As technical people we tend to forget how hard things can be for non-technical people. (And no, this is not because we're in any way "better" than they are, we just are good at different things.)
[1] It's true that many Apple buyers have plenty of cash. But I'm active in the local writers' community and it's amazing how many really poor writers (poverty is chronic for most writers) will scrape together every last cent to buy a Macbook.
It's almost a no-brainer, but for people who are on the fence on putting data in spreadsheets or a database: Start with spreadsheets, but organize them in a database table-like form (as opposed to an interface-like form with little mini-tables scattered around one subsheet, which is what most people tend to start out with).
1. Use only one header row per subsheet
2. Make as many rows as possible just straight data rows, with every cell conforming to what is dictated by the header for that column.
3. Create an id column with unique 'primary keys' for the data rows. Simple incremental integers obviously suffice in most cases. This also brings along the many advantages a stable identifier brings with it, such as being able to reliably refer to the rows pretty much everywhere.
4. Logic across data rows is best kept in separate subsheets or in the frozen section with the header row (see Google Spreadsheets), although this is mainly to allow for easy (re)sorting and filtering. Logic confined to each data row (i.e. derived columns) can be implemented as columns, although I do like to use background coloring to easily see the difference between the source and the derived columns.
If the step to a database ever needs to be made, migrating the data sheets is obviously trivial. Converting the logic to a different platform is also easier, as the separation advised above enforces that it is built around database table-like input.
If you knew anything about computer history you'd know that the GUI was inevitable. Steve & Bill may have popularized GUI interfaces through their positions but they weren't the only people thinking about computer graphics. In the same year the Macintosh was released 1984, Digital Research announced GEM & MIT announced X, Xerox was already developing their own graphics system.
In 1985 we got GEOS, AmigaOS, and the first shaky Windows.
The world could have gotten along fine without Apple or Microsoft. I personally would have been happy with an Amiga dominated PC industry. Hell, people were quite happy with VisiCalc before Excel ever appeared, and IBM did most of the work of killing off VisiCalc with Lotus-1-2-3, the first graphical spreadsheet program.
Speaking of myopic, most Apple fans would believe Apple not only invented fire, but made fire more stylish and desirable if Apple told them so.
Interesting hypothesis.
I'll make it simple. please show me a bitcoin miner that can produce numbers you suggest on CPU in comparison to numbers produced on GPU while staying on approximately same cost levels.
You say you "worked" in HPC. Are you sure your knowledge is still even remotely current? Are you sure your focus on CPU optimisation didn't leave you blind to what everyone else was doing?
In my experience, a good multi-core CPU is good for more like 125 GFLOP/s, and that varies highly from program to program thanks to the highly variable quality of code & compilers. You may be able to eke out better performance than that with skilful optimisation, but the vast majority of commercially available CPU-only software will never be that well optimised, even if it's brand new or rewritten from scratch.
A good GPU can sustain upwards of 5 TFLOP/s at single-precision with very little effort from the developer, and for the vast majority of applications, single precision is more than sufficient. It's not hard at all to fully utilise all that speed. I've ported carefully-optimised, thoroughly-parallelised CFD code from C++ to OpenCL and seen 50x speed gains on the first successful test run. After a little further optimisation it's usually around 100x, and that's not even with a particularly high-end GPU. This sort of thing no longer surprises me. I don't even consider an OpenCL port to be working properly until it's 100x faster than the CPU version.
So the reason you're seeing people making "outlandish" claims of 200x speed-ups thanks to GPUs must be that 200x speed-ups are not unusual, and you just haven't been paying attention. This seems far more likely than everyone else being clueless but still seeing massive speed-ups while you're the one in the know and seeing nothing special at all.