![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Dear Everyone,
are we working forward to LibreOffice-win64?
Taking a look if there were new Scribus releases I give a look to next branch svn 1.4.2
http://sourceforge.net/projects/scribus/files/scribus-svn/1.4.2svn/
and I see that... there are an x64 windows build (!!!) that I suppose it use the Win64 GhostScript build too
http://www.ghostscript.com/download/
Any new in this walk?
Have a sunny day,
Carlo
May I ask why our devs should work on a win64 version while we are having still a "few" bugs in the 3.6 branch (and also in 3.5.7).
How many LibO user are having wn64 machines? Or better what is the percentage of win64 users in the LibO community?
Most of the system on the market are 64bit . since 32bit can run in a
64bit environment I dont see the rush to change the application code to run
under 64bit. keep in mind i am not saying Libreoffice should not or will
not.
there is a high amount of user running Libreoffice under Windows.
rost52 wrote:
How many LibO user are having wn64 machines? Or better what is the percentage of win64 users in the LibO community?
I'm a Linux user, 64 bits of course, but I have one, 1, count 'em, one computer that has 64 bit Windows 7 on it. Then again, there have been 64 bit versions of Linux going back 17 - 18 years and I was running 64 bit Linux for over 5 years, before I had 64 bit Windows.
Okay, I'll betray my ignorance. What would be the difference or advantage of running a 64 bit LibO vs. a 32 bit LibO?
Virgil
Okay, I'll betray my ignorance. What would be the difference or advantage of running a 64 bit LibO vs. a 32 bit LibO?
Virgil
IMHO, the practical difference is nil for a typical office use. Some large databases will require 64 bit because 32 bit is limited to 4 GB.
Since Libreoffice is a Office product . I don't believe you will see a big
differential in performance as a user . From a programmer view , you can
take advantage of the cpu cycles and memory usage with a 64bit system.
Hi 
Are Cpu cycles to do with multi-core/multi-cpu? If so it's presumably possible for 32bit apps to take advantage. I think it's just a fluke that most of us think that 64bit machines tend to have more than 1 cpu/core and 32bit ones don't. Both technologies became well known around the same time.
Apparently the 4Gb Ram limit is a limit of the OS, not the apps. If the OS can read/write to more ram then i don't think the apps would be restricted. Apparently OSes that are 32bit could read more Ram with a different kernel module. With Gnu&Linux it's possible to swap-in the different module and i kept being told that "it's really easy". Something like the pae-something module.
Ram is used more efficiently by OpenSource programs, especially when using quite a few at the same time. My whole system is OpenSource apart from a few fonts and a couple of codecs and i seldom need even 1Gb. Movies and even fairly hefty games seem quite happy. I figure that if bits of my ram detiorate over time then i could always swap the sticks around to use the ones that aren't getting used at the moment.
If it feels like LO/OO are bumping into ram issues then it's more likely to be the limits you set (or the default ones) in
Tools - Options - Memory
If you imagine wires or cables as lanes on a motorway then double the number of lanes can carry double the number of cars. It's just that you don't always need to have that many cars on a section of motorway.
Regards from
Tom
CPU Cycles is the process the processor takes to complete a command.
Multiple cores came about due to the current CPU overheating above 4GHZ .
So they started adding more cores to the existing processors to give you
more cpu threads to process commands. So in theory you can have a 3GHZ CPU
with dual cores (2 central processing units) to get the result of a 6ghz
processor.
You are correct, the 4GB limit was imposed by the operating system . 64bit
has been around for years, I believe someone else mention this on the
thread, its not new and unix/linux has been using it.
"If you imagine wires or cables as lanes on a motorway then double the
number of lanes can carry double the number of cars. It's just that you
don't always need to have that many cars on a section of motorway. "
I like that ,
Tom Davies wrote:
Apparently the 4Gb Ram limit is a limit of the OS, not the apps. If the OS can read/write to more ram then i don't think the apps would be restricted. Apparently OSes that are 32bit could read more Ram with a different kernel module. With Gnu&Linux it's possible to swap-in the different module and i kept being told that "it's really easy". Something like the pae-something module.
With PAE, the 32 bit CPU can access more that 4 GB, but Microsoft still limits Windows to 4 GB. With Linux, no there is no such artificial limitation. IIRC, applications are still limited to 4 GB, as they don't know how to access more, but the OS can use the greater space and make it available to the apps. With Linux, recently used stuff is retained in memory, so that accessing it again is quick. It will eventually be moved to swap, if not recently used. So, with Linux, the more memory available, including beyond 4 GB, the faster the system in general runs.
Mas wrote:
I believe someone else mention this on the
thread, its not new and unix/linux has been using it.
Yes, there was a 64 bit version of Linux running on the DEC Alpha, followed shortly by the IBM PowerPC around 1994 - 1995.
The 64-bit R4000 by MIPS technologies came out in 1992 and was first used in Silicon Graphics machines, running IRIX the SGI flavour of UNIX. This processor was 64-bit internally but 32-bit externally so only a 32-bit wide memory-path could be used.Later versions, notably the R8000 (1994) and the R1000 (1996) were 64-bit internally and externally. In 1994 SGI licensed the memory architecture, developed by Cray (which it bought a few years later) and licensed it, I thought in 2002 to AMD for its 64-bit processors. This NUMA architecture is much faster than the standard architecture used in other processors and is much more suitable for multiprocessor systems.
Joep