![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Hi. From where download 64 bit version libreoffice for windows 8.1. 64 bit.
? Link or manual tutorial for download 64 bit version..
You can just download the 32bit version.
http://www.libreoffice.org/download/?type=win-x86&version=4.1.3
Why do you think you need a 64bit version?
Do you have any documents that are larger than 4GB? If so, then you need to rethink how you are using Office Applications...
Because one is running a 64 bit operating system.
jonathon
Yes, I am running several 64-bit Windows systems, but do you really need
to run a 64-bit office package? If I was going to do a lot of "number
crunching" I would look into a 64-bit package. But just because you
have a 64-bit Windows OS does not mean you need to have all your
packages be 64-bit - i.e. compiled to 64-bit and can only run on 64-bit.
I had a guy give me a 64-bit XP OS. He originally wanted to have his
system all run 64-bit Windows OSs if the processors were 64-bit. Have
you ever tried to run a 64-bit XP system? Worse than Vista.
So just because you have 64-bit, does not mean you need a 64-bit package
for all your computing needs.
The next thing people will insist on is LO being designed to run on all
2, 4, 6, or even 8 cores of the CPU at the same time to make it even
faster. Or a version that is compiled to work best on Win7 vs. XP or
Vista. It is bad enough that some packages I have will run on Win7
Professional and not Win7 Home Pre..
Seriously though, I bet if you looked at all of the software that you
install on your 64-bit Windows system, there maybe a lot of them that
are only 32-bit. Many of the drivers may even be 32-bit. That is the
good thing about OSs. They should be able to run both 32-bit and 64-bit
packages on their 64-bit versions of the OS.
What are you doing with LO that requires the heavier processing power of
a dedicated 64-bit package over a "standard" 32-bit package? I do not
know of anything I would need it for.
krackedpress wrote
The next thing people will insist on is LO being designed to run on all
2, 4, 6, or even 8 cores of the CPU at the same time to make it even
faster.
Do you really think it makes sense that Calc and Base are not prepared to
use all the computing power available?
Why do you think TDF and AMD are trying to bring GPU calculation to LO?
Because Calc (I haven't even tried Base...) is absurdly slow!
A heavy calculation spreadsheet I have takes 50 "seconds" to open in Excel
2010 and takes more than 10 *minutes* to open in Calc! (both 32bit versions)
No wonder Kohei Yoshida (one of, if not *the* main Calc developer) said
recently (August 2013): " You can’t compare Calc with Excel yet. They are
still miles ahead of us."
When Calc is able to use all cores and threads and eventually 64bit
operations then it might be on par...
Why do you assume the OP isn't doing number crunching?
Out of curiosity, I've checked if my LibO is 64bit (I'm running Ubuntu x64 12.04):
/usr/lib/libreoffice/program/soffice.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
Never quite understood why LibO/OOo is compiled in 64bit mode under Linux is the Linux OS is 64bit but never had a 64bit release for Windows (at least not that I'm aware of)...
I guess you're right in that one package for all Windows versions is probably better (i.e. less confiusing) than having to choose between "32 & 64 bit versions", a subject which I believe is quite obscure for most users anyway.
Hi 
Of course 32bit version can run on a 64bit OS. So it means the 1 version
is able to run on a wider range of machines. If there was to be a 64bit
version it would need the machine and the OS to also be 64bit but the 32bit
version can run on any combination.
OTH almost all newer machines are 64bit and running 64bit versions of
Windows. Almost all newer machines are 64bit and running 64bit versions of
Windows but i still find quite a few people running on 32bit. Part of the
advantage of LibreOffice is that it runs on older machines. Windows users
often get hopelessly confused by choice. They want to know which is best
rather than which is most appropriate for themselves and their own system.
Regards from
Tom
Then you don't understand how these things work...
Pretty much all 64bit Operating Systems can run 32bit programs just fine.
I only run 32bit version of Microsoft Office on all of our 64bit Windows 7 workstations - which in fact is exactly what Microsoft even recommends, unless you need to work with documents larger than 4GB... in which case you would be better off fixing the user problem (of why you seem to think you need to work with documents larger than 4GB)...
One corner case *might* be a database file, but even then you'd be better off using something like MySQL (or MariaDB, or even PostgreSQL) for the DB engine.
To be honest, number crunching on a GPU is better than a CPU, since GPUs
were designed to number crunch. Look at the newer CUDA and ATI GPU
cards. They have 32, 64, 128, 512, or more "cores" or "streams". There
is a movement to create systems that are GPU based instead of CPU
based. The gaming systems are almost all GPU based, since they do not
need to run traditional packages that a "home" or business computer
needs to work with.
Well, the Excel vs. Calc speed comparison on the same system [32-bit] is
a different "thing" than making a 64-bit version of LO or a GPU based LO
package. The difference between Calc and Excel may be the efficiency of
the coding. There are still a lot of old legacy code in LO that is
being worked on to make it work better and much more efficient. Just
saying we need to create a 64-bit version of LO to fix the "speed
issues" is not really solving that issue.
As for making LO work with a GPU card, well I would not be surprised
that not too long from now, both Windows and Linux will have a version
that is GPU based. That is one of the things that would make our
current systems faster without replacing the motherboard or CPU. Just
buy a newer, faster, GPU for the system. This is what the gamers do
currently. The price of these faster GPUs are going down. For $100, I
could buy a GPU 3 to 4 time faster than one I could buy 2 or 3 years
ago. The GPU speeds per price is a much better "ratio" than the CPU
speed per price. You just get more speed or number crunching power for
you money with a GPU card, compared to the CPU/motherboard costs.
Whoa, you're leaping way too fast here. GPU are better at number
crunching, but only at that, and litteraly at number crunching. Branching,
working with the rest of the hardware, interrupts, and even some kind of
float or integer operation are not exactly their shining part.
I agree that moving the *relevant* operations to GPU-based hardware can
(and actually do) provide a very large boost, but the kind of operation
that benefit from them is really limited. There is a reason we still have
those general-purpose CPU around you know. Talking about windows or linux
systems that are GPU based is a bit of a stretch.
Even for LO Calc, formulas that are more complicated than "add x and y",
for example using lookup functions, statistical functions and other funny
stuff would probably not run better on GPU. One of the key point of the GPU
(or GPGPU, general purpose GPU) performance boost is that you can handle
*arithmetic operations* that are *massively* parallel, not that you have a
lot of raw computing power.
The real thing needed is to make the LO "Calc coding" more efficient
than it is now. Just giving it a new place to do the number crunching
will not solve the "true issue" of why Calc is slower than Excel.
Once the developers clean up the legacy coding in the Calc "code
objects", and make as much as possible more efficient, then people
should be happier about how long it takes Calc to do it work.
To be strictly honest, the future will be a system that takes the best
of the CPU and GPU computing options and blend them into a system where
the OS can use the most efficient route to do the work, and then write
software packages to do the same.
Also, not too many OSs and packages can take advantage of a multi-core
system to bring all 2, 3, 4, 6, 8, or more cores, to do the processing
of the package running. There are a few though. I have 4 cores and I
see many times where one core is running at 90+% while the others are
running under 15 or 20% for the other packages I have open in the
background. As I type this, each core is running between 0% and 4 % at
1.15 GHz. So I am not taxing the CPu so I am not running at the 2.30
GHz max speed of the processor.
I won't insist on 64 bits, because I use machines that work on 32 bits, but the affirmation that Excel is more faster than Calc is true. I have been working the last six weeks with databases from a census, and can confirm the following:
-- Calc is really slow with lots of data. When the book requires more than 384 MB of memory, it slows down to an impractical speed. Days ago, I spent the whole day building a crosstab.
Open/Save is really slow and does not help a different file format to speed up things.
Another difficult thing, is with sorting and filtering. Is slow too.
Hi
2 possible ways to make it go faster
Toolos - Options - Memory
and just ramp everything up that looks vaguely relevant. I tend to take
things up to at least 20Mb but perhaps even higher like 200Mb might be
better.
Also which format are you using? If native Ods then that should be a lot
faster and better than MS's formats and especially better than the one with
X on the end, such as .XlsX
Third is to use a dedicated spreadsheet tool for hefty jobs like that.
Gnumeric knocks the spots off Excel and leaves it far behind in your
rear-view mirror. Again it's best if using it's native Ods format that is
also native to LibreOffice. However even if your file is in XlsX then
Gnumeric can still open it
https://projects.gnome.org/gnumeric/
It's not particularly unusual to have MS Office, LO (or AOO) and Gnumeric
all on the same machine, perhaps with Scribus or some other proper DTP in
addition. Office Suites are meant to be a "jack of all trades" but not
necessarily master of any. While Writer and Draw are more like DTPs than
Word they are still not dedicated to that sort of thing and getting a
proper tool such as Scribus or some LaTeX package takes it to the next
level. Similarly with Gnumeric. It doesn't have to worry about
side-issues so it can focus on purely spreadsheet functionality.
Non-OpenSource tries to make 1 monolithic program to do everything but in
OpenSource world we are more into the idea of having different specialist
programs co-operating with each other. LibreOffice is quite unusual in
that regard because it combines several different sorts of things but that
usually works out superbly in LOs case. However, there are times when it's
best to find the specialist tool instead
Regards from
Tom
H
I think the issue is, are there any technical issues that do not make it
easy to have 64-bit LibreOffice packages on Windows?
There are some technical issues, and Firefox is also distributed as a
32-bit package as well (Though you can look and find a 64-bit packages in
the nightly builds, so power users are happy),
http://thenextweb.com/apps/2012/12/22/mozilla-backpedals-on-firefox-64-bit-for-windows-will-keep-nightly-builds-coming-after-all/
As described at the link above, it's good to figure out with numbers
whether there are cases that a 64-bit LibreOffice has actual benefits (big
document, etc). Having a 64-bit LibreOffice for Windows will help retain
some power users.
Simos
I've been trying hard to avoid this conversation as it's probably the 1000th time I've seen something similar on the user list but coming from a developer/QA perspective, I think I can say something brief. The possible gains for these "power users" would probably be small and the amount of time to developer a true 64 bit version (on top of these requests to support 8 cores or whatever else that's requested) would be IMMENSE. We're talking about tens if not hundreds of thousands of dollars worth of developer and QA time. If you have a spreadsheet that is running that miserably I would recommend that any of these "power users" investigate if they are using spreadsheet correctly (vs. masking a database within spreadsheet, which is incorrect and in which case they should be learning how to use Database). I do have a few spreadsheets that are 40ish megs with quite a few charts and lots of formulas, but even these I could likely convert to a database if I took the time and probably see some gains in performance - but even these run "fast enough" and I would never ask developers to waste their time for these outlier cases of having insane spreadsheets.
At my old work my employer had made a 1 GB Spreadsheet and always complained about Excel's limitations - at which point I would quickly point out "no, although I'd love to pin this on Microsoft, this is in fact bad implementation on your part." I don't know the details of any of these Spreadsheets but from what I've seen in the past, these statements have rung true in most cases.
No offense at all, I encourage open conversation but I tend to see a one side conversation "THERE SHOULD BE A 64 BIT FLYING LIBREOFFICE THAT CAN BAKE ME A CAKE AND CALCULATE A QUADRILLION FORMULAS IN 0.0000001 SECONDS USING ALL 16 OF MY CORES!" - without the other side of the equation - "such a product would be incredibly costly and there are thousands of much more important things to get done that will benefit a lot more users."
All the best,
Joel
I think the real issue for this thread is not 32-bit or 64-bit, but the
performance of Calc.
Yes, it can be much slower than Excel, but not always.
Yes, our developers are working on making the code more "efficient" so
it will work faster.
Efficient 32-bit package can outperform a less efficient 64-bit
version. Just because the package is a 64-bit package does not mean it
will work better.
I have a single core 64-bit HP laptop [2005 era] running 32-bit XP/pro
that converts .mp4 videos to a DVD player movie format faster than the
dual core 64-bit DELL laptop [2007 era] running 32-bit Vista ever did.
I have a DELL dual core 64-bit desktop that ran 64-bit Ubuntu 10.04 and
it is slower than a 32-bit desktop that ran Ubuntu 10.04 32-bit.
In my experience, just because there is a 64-bit version out there, it
does not mean it is better and faster.
The worse OS I have ever used was a 64-bit XP that was used in an office
for number crunching on a dual core 64-bit Intel processor. It was much
worse than ME or Vista.
So, lets let our developers work on making Calc work more efficient.
Let them work on all of the legacy code that needs to be updated to make
it run better, faster, etc.. Over the past few years, it seems that
Calc is running a bit faster as Calc gets more code replaced, and as
Java is replaced by Python. [as I was told was being done].
They are working their best, and most of them are volunteers who work on
LO after they get done with their paid jobs. Of course it is nice that
there are businesses that are providing some help as well.
If we had hundreds of paid code developers, like MSO has, then it would
take less time to get things done. But then LO would no longer be FREE,
since LO had to sell their office suite to pay for all of the workers
and developers. That is a lot of money towards payroll we cannot get
from donations.
Well, to be fair, 64bit XP was ALWAYS buggy as hell, nothing to do with 64bit itself, it was just a really, really bad implementation on Microsofts part.
64bit Windows 7 rocks, as does 8 (if you can get past the god awful cartoonish tablet UI, which I can't)... even installing ClassicShell (which is a must on Windows 7 too) doesn't eliminate all of the warts (but it goes a very long way)...
Have not used any other 64 bit than WIN 8 and it does seem to be more
stable than vista 32 Bit that I had before. Had to change when the machine
HardWare died. However, using Stardock Start8 my 8.1 functions like my
wife's WIN 7.
I have tired some 64 bit programs but so far have not found any really
important reason to use them only, unless the program has been designed to
work with only 64 bit. The only programs that I would like to have as 64
bit are graphics programs and the one I use the most "GIMP" is 64 bit also
for Windows so far I am happy. Office stuff that would use more that 4 GB
ram for a file is not something would like to use.
The GIS program that I use QGis is 64 bit and it is probably the only one
that really benefits of 64 bit architcehture.
Heikki Jussila