Re: [libreoffice-users] Re: 64 bit

2013-11-11 Thread Marcello Romani

Il 08/11/2013 21:35, Gabriel Risterucci ha scritto:

2013/11/8 Pedro pedl...@gmail.com


jmadero wrote

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


So, having a 64bit Linux version is Ok, creating a 64bit version for MacOS
(starting in LO 4.2) is Ok, but asking for a 64bit Windows build is
selfish...

Interesting. Us Windows users should be ashamed of ourselves...



Having 64bits binary in linux/macos is natural, as everything around is
64bit, and the toolchain is quite easy to handle.
On windows, there is two issues regarding this:
- 64bit software is not as common as one would expect. Some Java
installation are still 32bit, which would break LibreOffice64bit instantly.
- Building 64bit binary is somewhat tricky on windows; mingw64 is a way,
but when you end up having dependencies that need to be built as 64bit too,
and they don't build easily, it gets tedious, to say the least... assuming
the code would build at all by just switching compiler target. Not sure of
the current state of other open solutions like cygwin regarding this. And
using MSVC would be more challenging than anything, as it introduce it's
own set of surprise when going from 32bit build to 64bit build.

And all that just to have a 64bit binary that would only give more work and
no immediate benefit...



After this reply I hope anyone whining about Windows users being let 
down because there's no 64 bit version of OpenOffice/LibreOffice shut 
the hell up and start complaining to Microsoft. :)


--
Marcello Romani

--
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-users] Re: 64 bit

2013-11-11 Thread Tanstaafl

On 2013-11-11 7:40 AM, Pedro pedl...@gmail.com wrote:

Marcello Romani wrote

And all that just to have a 64bit binary that would only give more work
and no immediate benefit...



After this reply I hope anyone whining about Windows users being let
down because there's no 64 bit version of OpenOffice/LibreOffice shut
the hell up and start complaining to Microsoft. :)



Right...

Because all FLOSS projects that have 64bit Windows versions (mentioned in
this email
http://nabble.documentfoundation.org/64-bit-tp4081444p4082245.html that some
users choose to ignore) are all run by stupid people who choose to have a
lot of work for no reason...


sigh

What is so hard to understand about:

1. Libreoffice is a *huge* project

Yes, some of those projects mentioned are not so small (ie, postgresql), 
but...


2. There would be *very little* benefit for a 64bit port of Libreoffice 
for 99.9% of its userbase


Again, as example, Postgresql benefits *greatly* from having a 64bit 
version, as large (4GB+) databases are extremely commonplace.


4GB+ Writer, or Calc, or Impress, or Base documents are *extremely* 
rare, and when they are encountered, there is a very large likelihood 
that it is an extremely poor and even *improper* usage in the first place.


Bottom line: The benefit (none to negligible) of a 64bit version of 
Libreoffice simply is not justified by the cost (work required to make 
it happen).


But by all means, feel free to organize a group of developers capable of 
rearchitecting the massive codebase to make it happen...


--
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted



Re: [libreoffice-users] Re: 64 bit

2013-11-11 Thread Gabriel Risterucci
2013/11/11 Pedro pedl...@gmail.com

 Marcello Romani wrote
  And all that just to have a 64bit binary that would only give more work
  and
  no immediate benefit...
 
  After this reply I hope anyone whining about Windows users being let
  down because there's no 64 bit version of OpenOffice/LibreOffice shut
  the hell up and start complaining to Microsoft. :)

 Right...

 Because all FLOSS projects that have 64bit Windows versions (mentioned in
 this email
 http://nabble.documentfoundation.org/64-bit-tp4081444p4082245.html that
 some
 users choose to ignore) are all run by stupid people who choose to have a
 lot of work for no reason...


Read your own post: a lot of work for no reason.
First, some of these projects *have* reasons to have a 64bit build. GIMP
can handle large and complicated images, and need to break the 4GB limit
(2GB really on default build). Other needs to handle large quantity of data
and might take advantage of new vectorizations instructions, etc...
Second, it *is* a lot of work. Even in the post you mention, there is at
least two project that kinda struggle with 64bit windows build: firefox,
where they are not really supported, and FreeCAD, which seems to have
dropped support for 64bit windows. It's costly to maintain program that
build for many targets, and cost is an issue with some open source projects.
And last, building a piece of software from the ground up and
maintaining/evolving a (rather large) project for that long are very
different. Here, we're not talking about writting code from scratch, but
you have to make sure that every piece clicks. Going back through *all* the
code to make sure that there isn't a pointer somewhere or an int there that
would suddenly break because some OS API expect another type of value is
indeed a lot of work, way more than just writing from scratch.
LibreOffice might be a fairly recent project, but it's codebase goes way
back.
And again, all of the work needed to barely have a stable working build
would yield very little benefit. The code don't magically take advantage of
64bit code by just changing the compiler's target.

So, no, other projects didn't decide to have a lot of work for no reason.
*Some* decided to have 64bit builds from the start, *some* decided to
revamp their code, *some* decided not to, *some* gave up on it. But in
every cases, ressources for such projects are limited, and focusing on
bugfixes and enhancement seems more useful than having a 64bit build for
what is, regarding LibreOffice, no reason.

-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-users] Re: 64 bit

2013-11-09 Thread Tanstaafl

On 2013-11-08 5:28 PM, Pedro pedl...@gmail.com wrote:

I know and I agree, Miguel. I just don't agree with the logic don't ask for
a 64bit version because it's very time consuming and expensive and you don't
need it anyway.

Why do Linux and Mac people need it more than Windows people?


They don't. If you had bothered to actually read the responses in this 
thread, you would understand that compiling 64bit versions on Linux is 
*trivial*, and on OSX *much* easier than on Windows.


The reason there is none is because it is *hard* to do - *very* hard - 
and because the benefit is so little, it isn't a high priority.


Yes, you are within your rights to *ask* for it... but when you start 
demanding someone else do the heavy lifting for FREE, you begin to sound 
like little children banging on the table that 'I want what I want when 
I want it!'...



Do they work with files larger than 4Gb? Isn't the cost per developer
hour the same? If there is no advantage why do developers bother at
all?


READ THE DAMNED RESPONSES AND STOP WASTING EVERYONES TIME

--
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted



Re: [libreoffice-users] Re: 64 bit

2013-11-09 Thread Carlo Strata

Hi Kind People! :-)

I have already written in the past about win64 builds. And now, after 
reading this interesting entire thread I think:


- I completely agree that it is a first priority to complete the Calc 
(LibreOffice?) code rewrite and modernization;


- but (!!!) just after this further rewrite (and not after the next 
infinite ones!), I think (!) it will be useful to organize well the code 
so that all Microsoft Windows 32 and 64 bit codes build automatically 
and without any trouble (in my head this may be a big goal that may also 
have positive effects in later time... like deprecated Windows API 
cleaning, ...);


- I am 44 years old and I am in computer science since I was 16, I am 
a computer science engineer since 1999, I have lived the 16 to 32 bit 
Windows migration in the half 90s and I remember similar talks about the 
priority to convert code or not (at the time not so much open source 
(floss) one at least on Windows...) from win16 to win32s (does someone 
remember these APIs?) or win32 (full);


- in that case, in 90s, the migration doesn't complain only the API bit 
size, but a more fluid multithreading implementation, a native flat 
memory addressing and so on...;


- now I suppose or try to guess (!), in particular on Windows systems, 
we are in front of a similar API improvement/modernization that go 
beyond the only bit size, data addressing size, memory address code 
allocation (i..e. over the firsts 4 Gbyte), data size computation, 
multicore suitable code, ...:

http://en.wikipedia.org/wiki/Windows_API#Versions

- I think that making intra-project experiences exchange (!!!) in win64 
porting (and not only in this...) may put down time and money costs: The 
Document Foundation are a XXI century Office Suite Management 
innovation, why don't continuing to innovate the floss deploy also 
formally exchanging experience without suffer to discover again (!) the 
same things???!!! It is better to pay for the discover of the very new 
things or ideas, isn't it?


- in the Document Foundation Wiki I have seen something about this 
discuss, particularly about GSoC:

https://wiki.documentfoundation.org/Development/GSoC/Ideas#Porting_LibreOffice_to_x64_Windows

- below I build a little, absolutely not comprehensive, lists of already 
win64 and only win32 floss Windows applications: are these first list 
projects experiences useful to the GSoC student to reach our goal? I 
think at least for most! ;-)


Already win64 floss application (All developers are genius? All projects 
are petroleum or gold or energy rich? I don't think so...):

- Scribus (!!!);
- GIMP (already said in this thread);
- AviDemux (and developers have success over multi external library 
porting; it depends on many famous multimedia libraries!!!);
- VideoLAN (and developers have success over multi external library 
porting; it depends on many famous multimedia libraries!!!);

- Blender;
- Paint.NET (I suppose a simple .NET capability inheritance);
- FreeCAD (but there are some trouble in the building structure because 
win64 builds are somewhat abandoned since a lot of months... It is a 
very pity! It may be interesting ask them because and share experiences 
so that we continue never reinventing the wheel!!! This possible 
dialogue may be useful for both them and us...!!! And this approach may 
push down develop costs...);

- BRL-CAD (recently!);
- RawTherapee;
- Ghostscript;
- Mozilla Firefox (but only in the nightly builds, as already said in 
this thread, even though flash and java plugin win64 build are stable 
and running since at least one/two years);

- PostgreSQL database;
- MySQL/MariaDB databases;
- Python;
- Java;
- PHP (experimental, interesting read here: 
http://marc.info/?l=php-internalsm=137002754604365w=2 or from Apache 
Lounge http://www.apachelounge.com/viewtopic.php?p=22259)

- Apache HTTPD;
- ...

Not yet win64 (still win32) floss application:
- LibreOffice (!!!) (and AOO, I suppose);
- FileZilla (!!!);
- Notepad++;
- InkScape (!!!);
- Merkaartor;
- OpenCPN;
- GPSBabel;
- Mozilla Thunderbird (some win64 builds in the past were done..., do 
you remember http://www.mozilla-x86-64.com/? Recently a Customer of mine 
reaches the 4 Gbyte mail folder file limit I suppose due to SQLite 
limit, surely for bad mail management (I make him to archive mail per 
year), many mails with big attached files, ...);

- pgadmin (PostgreSQL GUI admin client);
- GNU Utils (I recently use gawk in windows environment to extract data 
from a digital marine echo sounder/fishfinder datalog file and create a 
.gpx xml GPS track file);

- SQLite;
- ...

*I think we, all together, could do API upgrade.*
*This is, of course (!), not in conflict with TDF donations, TDF project 
financing and other marketing or future growing things...*


Have All a sunny weekend!

Carlo

--
ing. Carlo Strata
-
via Botticelli 1/4
30031 Dolo - VE
Italia - Italy
-
tel./fax +39.041.822.0665
cell. +39.347.85.69.824
Skype carlo.strata
Google 

Re: [libreoffice-users] Re: 64 bit

2013-11-08 Thread Jay Lozier
On Fri, 2013-11-08 at 12:27 -0800, Pedro wrote: 
 jmadero wrote
  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.001 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.
 
 So, having a 64bit Linux version is Ok, creating a 64bit version for MacOS
 (starting in LO 4.2) is Ok, but asking for a 64bit Windows build is
 selfish... 
 
 Interesting. Us Windows users should be ashamed of ourselves...
 
Does MS provide a 64 bit version of MSO office? The last time I checked,
MSO did come in separate 32/64 bit versions. One of the major benefits
of 64 bit is the database size. But I think Access limits one to 2GB
which is the limit for a 32 bit version. 

Often MS is more fanatic about backwards compatibility so their software
is often limited by still supported Windows version. For years the base
version of Windows was 32 bit XP.

-- 
Jay Lozier
jsloz...@gmail.com


-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-users] Re: 64 bit

2013-11-08 Thread Gabriel Risterucci
2013/11/8 Pedro pedl...@gmail.com

 jmadero wrote
  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.001 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.

 So, having a 64bit Linux version is Ok, creating a 64bit version for MacOS
 (starting in LO 4.2) is Ok, but asking for a 64bit Windows build is
 selfish...

 Interesting. Us Windows users should be ashamed of ourselves...


Having 64bits binary in linux/macos is natural, as everything around is
64bit, and the toolchain is quite easy to handle.
On windows, there is two issues regarding this:
- 64bit software is not as common as one would expect. Some Java
installation are still 32bit, which would break LibreOffice64bit instantly.
- Building 64bit binary is somewhat tricky on windows; mingw64 is a way,
but when you end up having dependencies that need to be built as 64bit too,
and they don't build easily, it gets tedious, to say the least... assuming
the code would build at all by just switching compiler target. Not sure of
the current state of other open solutions like cygwin regarding this. And
using MSVC would be more challenging than anything, as it introduce it's
own set of surprise when going from 32bit build to 64bit build.

And all that just to have a 64bit binary that would only give more work and
no immediate benefit...

-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-users] Re: 64 bit

2013-11-08 Thread Joel Madero
Clearly the point didn't come across as I hoped. What I'm saying is that 
our resources are stretched incredibly thin and IMHO this is a waste of 
time expending so much energy discussing the potential benefits when we 
have 5,000 or so open bugs that need addressed, probably at least a 
couple thousand of which are much more important than a 64 bit version 
on Windows. That being said, if you want to continue listing all the 
reasons why we need one to anyone who will listen - feel free to do so, 
I just personally don't think it's very productive or conducive to the 
best LibreOffice experience. I would hope that some people who have 
taken so long listing all the great benefits of 64 bit would spend an 
equal amount of time triaging the 1,200 bugs that are currently 
UNCONFIRMED and need testers - the # of Windows bugs in particular in 
that state is disturbing as most users are Windows users.



All the best,
Joel

On 11/08/2013 12:27 PM, Pedro wrote:

jmadero wrote

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

So, having a 64bit Linux version is Ok, creating a 64bit version for MacOS
(starting in LO 4.2) is Ok, but asking for a 64bit Windows build is
selfish...

Interesting. Us Windows users should be ashamed of ourselves...



--
View this message in context: 
http://nabble.documentfoundation.org/64-bit-tp4081444p4082136.html
Sent from the Users mailing list archive at Nabble.com.




--
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted



Re: [libreoffice-users] Re: 64 bit

2013-11-08 Thread John Meyer
And there's also the Open Source Answer:  if users think that such a 
project would be worthwhile they can band together, take the code, and 
try to port it themselves.


On 11/8/2013 1:41 PM, Joel Madero wrote:
Clearly the point didn't come across as I hoped. What I'm saying is 
that our resources are stretched incredibly thin and IMHO this is a 
waste of time expending so much energy discussing the potential 
benefits when we have 5,000 or so open bugs that need addressed, 
probably at least a couple thousand of which are much more important 
than a 64 bit version on Windows. That being said, if you want to 
continue listing all the reasons why we need one to anyone who will 
listen - feel free to do so, I just personally don't think it's very 
productive or conducive to the best LibreOffice experience. I would 
hope that some people who have taken so long listing all the great 
benefits of 64 bit would spend an equal amount of time triaging the 
1,200 bugs that are currently UNCONFIRMED and need testers - the # of 
Windows bugs in particular in that state is disturbing as most users 
are Windows users.



All the best,
Joel

On 11/08/2013 12:27 PM, Pedro wrote:

jmadero wrote
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.001 
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.
So, having a 64bit Linux version is Ok, creating a 64bit version for 
MacOS

(starting in LO 4.2) is Ok, but asking for a 64bit Windows build is
selfish...

Interesting. Us Windows users should be ashamed of ourselves...



--
View this message in context: 
http://nabble.documentfoundation.org/64-bit-tp4081444p4082136.html

Sent from the Users mailing list archive at Nabble.com.







--
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted



Re: [libreoffice-users] Re: 64 bit

2013-11-08 Thread Virgil Arrington

On 11/07/2013 07:29 AM, Tom Davies wrote:

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



Reminds me of the good old days of DOS, when Lotus had 1-2-3, 
Ashton-Tate had dBase, and WordPerfect had, well, WordPerfect. Three 
different programs that each dominated their respective fields. Rather 
than office suites we had integrated programs like MS Works, or Claris 
Works and Perfect Works. They were truly the 
one-program-does-everything-but-not-necessarily-well. Serious users 
avoided the works programs and used the dedicated, but narrowly 
tailored program.


Thanks, Tom, for the Gnumeric tip. I just tried it today, and like it. 
But, then, my spreadsheets are extremely simple affairs.


Speaking of DOS, rather than clamoring for a 64-bit programs running on 
multi-core processors, I would prefer to go back the fastest computer I 
ever used... a 286 machine with a 20 meg. hard drive running DOS, 
PC-Write and As-Easy-As, a shareware 1-2-3 clone. Man, it blazed!


Virgil

--
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted



Re: [libreoffice-users] Re: 64 bit

2013-11-08 Thread RODRIGUEZ FONSECA JORGE ALBERTO
+ 1

- Mensaje original -
De: Pedro pedl...@gmail.com
Para: users@global.libreoffice.org
Enviados: Viernes, 8 de Noviembre 2013 16:28:51
Asunto: [libreoffice-users] Re: 64 bit

mariosv wrote
 I love to waste my time as I please. And as I know this is an open
 project, everyone is free to take their choice about this thread as he/she
 likes, so I would pleased not being told about what must be my choice.

+1


mariosv wrote
 On the last months there is in development a deep work in the calc core,
 to get a better performance and set up the basics for further
 improvements. What I think will bring more benefits on the performance
 than a 64 bits version.
 
 So maybe we should have some patience, leaving the steps going on their
 own time.

I know and I agree, Miguel. I just don't agree with the logic don't ask for
a 64bit version because it's very time consuming and expensive and you don't
need it anyway. 

Why do Linux and Mac people need it more than Windows people? Do they work
with files larger than 4Gb? Isn't the cost per developer hour the same? If
there is no advantage why do developers bother at all? 



--
View this message in context: 
http://nabble.documentfoundation.org/64-bit-tp4081444p4082156.html
Sent from the Users mailing list archive at Nabble.com.

-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-users] Re: 64 bit

2013-11-08 Thread Joel Madero

On 11/08/2013 02:16 PM, mariosv wrote:

I love to waste my time as I please. And as I know this is an open project,
everyone is free to take their choice about this thread as he/she likes, so
I would pleased not being told about what must be my choice.



+1, my apologies.


All the best,
Joel

--
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-users] Re: 64 bit

2013-11-07 Thread Tom Davies
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


On 7 November 2013 05:44, Denis Navas Vega denis.na...@gmail.com wrote:

 El 2013-11-05 05:51 p.m., Pedro escribió:

 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?



 --
 View this message in context: http://nabble.
 documentfoundation.org/64-bit-tp4081444p4081605.html
 Sent from the Users mailing list archive at Nabble.com.

  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.




 --
 To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
 Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-
 unsubscribe/
 Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
 List archive: http://listarchives.libreoffice.org/global/users/
 All messages sent to this list will be publicly archived and cannot be
 deleted


-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted



Re: [libreoffice-users] Re: 64 bit

2013-11-06 Thread Kracked_P_P---webmaster
On 11/05/2013 06:51 PM, Pedro wrote:
 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?


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.




-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-users] Re: 64 bit

2013-11-06 Thread Gabriel Risterucci
2013/11/6 Kracked_P_P---webmaster webmas...@krackedpress.com


 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.


-- 
Cley Faye
http://cleyfaye.net

-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-users] Re: 64 bit

2013-11-06 Thread Kracked_P_P---webmaster
On 11/06/2013 11:18 AM, Gabriel Risterucci wrote:
 2013/11/6 Kracked_P_P---webmaster webmas...@krackedpress.com

 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.





-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted