Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 22:14:42



Reply to topic  [ 5 posts ] 
Viewer builds and optimization 
Author Message

Joined: 2010-07-03 16:08:02
Posts: 3
Reply with quote
With regard to the 1.19 codebase, I was wondering a few things.

I have done a study on the CPU usage of the official viewers with some addons (SL 1.19.0.5 + CoolViewer, SL 1.23.5 + Coolviewer, SL 1.23.5 + RLV 1.22.1 & SL 2.0) and the results warrant further examination into the build of all viewers.

Certain factors came to mind which could have attributed to the results, but I am unsure where to share them as the problem lies more with the official SL viewers than with Cool Viewer.
Considering this forum deals solely with the Cool Viewer, and not with the SL Official viewers, and there's no part of me who wants to attempt to run into the brick walls LL put up around itself when dealing with this kind of a subject, I was wondering whether I could still post my findings in a part of this forum and ask the question related to the CoolViewer codebase on top of the SL Official ones instead of solely focusing on the SL Official viewer?

If so, please fill me in on the proper location to post a question dealing mainly with the codebase and presumably further investigation and development into this?

I'm afraid I lack the insight into these things and I do apologize if I posted this question in the wrong location as well. Please correct me, because that is the only way I will find knowledge where uncertainty is ever-present at this moment.

With thanks,
Maki


2010-07-03 16:21:42
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
The speed difference between the Cool SL Viewer and the official viewer is mainly due to more aggressive compiler optimization options being used for the former (you can see what optimizations are used for the Cool VL Viewer by looking inside the build scripts (for Linux) and the Windows specific patch for VS2005 builds).

The speed difference between the Cool SL Viewer and other third parties viewers (which is almost always in favour of the former), is mainly due to the better coding of the additional features (the radar, for example, which can make other third parties viewer lag with up to 30% FPS decrease in worst case scenarios, when the Cool VL Viewer will only suffer from a 5% decrease in the same conditions and stay faster than the official viewer even with the radar active and open...). Just have a look at the patch list and see how many I had to modify to prevent such slow downs...

PS: I moved your post outside of the Roadmap discussion since it was not related to the roadmap.


2010-07-03 20:28:49
Profile WWW

Joined: 2010-07-03 16:08:02
Posts: 3
Reply with quote
My wife, Locke, who is a much better coder than me, dared take the snowglobe code apart.
Considering we both use Gentoo Linux and update regularly to keep our system security in order, it was a bit of a surprise to find the Snowglobe 2.0 trunk still uses libraries that are as old as 2008 in some cases.

I'm thinking that the slowdown of the program in itself may have to do with those old libraries as most people, or at least my wife, myself and those in our direct circle of friends and (extended) family, attempt to update our system regularly. Thusly, the old libraries might attempt to use functions our system can barely comprehend anymore since those commands have been obsoleted.
While attempting to rectify this by pulling all local libs and forcing Snowglobe 2.0 to compile against the system libs, which are in some cases several versions ahead of LL's libs, the Snowglobe viewer completely disregarded protocol and attempted to pull in the old LL libs anyway.

I must commend you, Henri, for being able to make any sense of this while writing your Cool VL Viewer.

The worst case of bad coding we've seen is that Snowglobe attempts to store the downloads in /var/tmp/{USER}/install.cache/ which is used by Portage as well and causes more errors than should be necessary.

Among the problems we've found is that it attempts to bundle a small OS within the viewer trunk 2.0 build, which really shouldn't be necessary on any system.
Windows as well as Linux are quite capable of pulling in dependencies to programs while keeping these deps seperate from the actual program and since MacOSX is built on UNIX/Linux, I see no problems there (I just have no knowledge of it).

Bundling mesa-7.0 with Snowglobe is bad.. libsdl? Bad.. Especially this old.
The Snowglobe cmake setup decides to build within the same folder tree as the source, which is completely contrary to the standard practice of building in a separate folder from the source tree so as not to accidentally overwrite things that may be needed later on. This cmake setup causes the cmake-utils eclass to choke, since it does out-of-source-tree building by default.

Bundled with Snowglobe, as we found so far;
zlib
elfio (a version from 2008)
jsoncpp (taken from svn and snapshotted at r69)
libxml (from 2008)
llqtwebkit (as taken from qtwebkit from 2008, modified by ll and then never updated anymore..)
gstreamer (Again from 2008...)
libsdl (taken from 2008)
mesa-7.0 (flash from the past: 2008)
freetype (And yes, 2008 as well..)

Most of these programs have been updated numerous times to fix security issues, memory leaks, etc. Why LL hasn't caught up to this yet is anyone's guess.
Locke and me aren't capable of seeing any kind of rationality in this. @_@;


2010-07-04 10:18:47
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
If you are using Gentoo or another distro with "better than usual" optimizations (most Intel compatible distros are still built for compatibility with i386 processors, which is a non-sense and precludes the use of more efficient addressing modes in newer CPUs), such as Mandriva (compiled for i586), then you can indeed squeeze a few more percents in speed gain by recompiling the viewer and linking it against your distro's libraries instead of LL's provided ones.

The problem for LL, is to be able to provide a binary that works on all distros, and this is done by compiling the viewer against the old glibc v2.4 (which has been around since 2006 or so): among the other libraries the viewer is linked against, quite a few indeed got newer, faster, bug/security fixed versions, but some may be impossible to recompile on an old glibc v2.4 system short of practically bootstrapping it (something your wife might be able to do with Gentoo: i.e. rebuilding Gentoo but with gcc v4.1 and glibc v2.4 as the base...).
Thus why extremely outdated libraries are provided by LL...

Worst, some of the LL provided libraries got proprietary patches and when you don't use them, the viewer behaves differently (see the comments in the (c)make-SL scripts: it's the case for freetype, for example).

As for rebuilding the viewer yourself, you will find it extremely difficult (and even "painful") to do so with your distro packaging tool (dkpg, rpm, ebuild, etc), thus why I wrote the (c)make-SL scripts: I highly recommend you to use these scripts.


2010-07-04 15:33:25
Profile WWW

Joined: 2010-07-03 16:08:02
Posts: 3
Reply with quote
Henri Beauchamp wrote:
If you are using Gentoo or another distro with "better than usual" optimizations (most Intel compatible distros are still built for compatibility with i386 processors, which is a non-sense and precludes the use of more efficient addressing modes in newer CPUs), such as Mandriva (compiled for i586), then you can indeed squeeze a few more percents in speed gain by recompiling the viewer and linking it against your distro's libraries instead of LL's provided ones.

The problem for LL, is to be able to provide a binary that works on all distros, and this is done by compiling the viewer against the old glibc v2.4 (which has been around since 2006 or so): among the other libraries the viewer is linked against, quite a few indeed got newer, faster, bug/security fixed versions, but some may be impossible to recompile on an old glibc v2.4 system short of practically bootstrapping it (something your wife might be able to do with Gentoo: i.e. rebuilding Gentoo but with gcc v4.1 and glibc v2.4 as the base...).
Thus why extremely outdated libraries are provided by LL...

Worst, some of the LL provided libraries got proprietary patches and when you don't use them, the viewer behaves differently (see the comments in the (c)make-SL scripts: it's the case for freetype, for example).

As for rebuilding the viewer yourself, you will find it extremely difficult (and even "painful") to do so with your distro packaging tool (dkpg, rpm, ebuild, etc), thus why I wrote the (c)make-SL scripts: I highly recommend you to use these scripts.

I'll pass on the information to my wife and we'll have a look-see how we can help improve the general security and speed of the SL client while maintaining our sanity. ;)

Considering I've come to see the Cool VL Viewer as (one of) the best 3rd party viewer, it makes sense to pass on further information to you. Will be using this thread to pass on updates unless a different method is preferable.


2010-07-04 17:25:40
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 5 posts ] 

Who is online

Users browsing this forum: No registered users and 41 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.