Seems the Firestorm Development Team is thinking about a 64-bit version of the viewer. Jessica Lyon has placed a post on the Firestorm Viewer blog about a 64-bit viewer. See: Firestorm 64bit Viewer o.O.
There is a link to the explanation of what 64-bit software is and how it differs from 32-bit software. Unfortunately, the link leads to a Microsoft site. My experience is you need to be a graduate of some geek college to understand what they’re saying. So, I’ll give you the short version… well… at least a version with, I hope, understandable language.
Computers have CPU’s and memory. Those two things need to be connected. The connection is called the bus. Everything in a computer is coordinated by clock ticks. When we say a computer has a 3 GHz speed or CPU we mean that it works with a clock the ticks 3 billion times a second. Each time the clock ticks the CPU can do something. It moves data from memory into the CPU to work on. It then moves data back to memory or to the video card. Or possibly sends data to the hard disk or retrieves it from the hard disk. Sometimes data is sent to and taken from the Internet or local network too.
You probably already know, all data is just ones and zeros. But, how much data can be moved is dependent upon how many ones and zeros can be moved at one time. In 32-bit systems only 32 ones and zeros can be moved with each clock tic. 64-bit systems use 64 ones and zeros. So, obviously 64-bit systems can run faster because they move more data in a single clock tick.
The CPU has to be built to hold 64-bit chunks of information. It has to have data in an data out paths that are 64-bit wide. Memory has to be designed to handle 64-bit chunks of data. The bus that connects things has to be 64 bits wide. So, your CPU, memory, and motherboard all have to be designed to handle 64-bit chunks of data.
The largest number a CPU can deal with is dependent on whether its hardware handles 32-bit or 64-bit numbers. The largest number that can be represented in 32 bits is about 4 billion. For 64-bit numbers the max is: 18,446,744,073,709,551,616 or 18 quintillion. This number matters in computers because CPUs have to number every single memory location. To send data to and retrieve data from memory they have to use that number or as it is generally called an address. So, 64-bit systems can address way more memory.
When a computer needs to use more memory than it has, it does a thing we call paging or faulting. All this means is that data is being taken from memory and written to the hard disk. Of course, later when it’s needed it’s read from the hard disk and used. The problem with doing this is writing to and reading from the hard disk is far slower than writing to or reading from memory. The new SSD drives are an attempt to improve on that speed. Those drives do not have to wait for physically spinning disks to move into position to have data written or read from the disk. Still, writing and reading directly to memory in the computer is way faster.
So, there are advantages to having a 64-bit system. Game consoles went to 64-bit a long time ago. Some video cards run 128-bits within the video card. Apple’s new A7 CPU is a 64-bit processor running at 1.2 GHz. Samsung has some versions of the A7 that they have pushed to 1.7 GHz. My old Core2 Quad is a 64-bit processor running at 2.4 GHz. But, there are versions running 3.1 GHz. The world is going to 64-bit. And in some places moving to 128-bit.
While 64-bit is great for software in general, there are some problems for 64-bit viewers. I’ll get into those.
The first problem we run into his old hardware. The first 64-bit CPUs went into production in 2003. Intel started releasing 64-bit CPUs in 2004. The Pentium 4 was the first 64-bit Intel CPU in the retail market. So, if your computer is pre-2004 it is likely built on 32-bit technology. It is physically incapable of running 64-bit software.
The Apple and Microsoft operating systems have come in 32-bit and 64-bit flavors for some time. By far the majority of Windows XP systems are 32-bit but there is a 64-bit version. The operating system has to be 64-bit in order to know how to run 64-bit software. So, a Linden Lab 64-bit viewer or anybody’s 64-bit viewer is not going to run on the majority of older Windows XP systems.
I need to go into some techie background to explain the next problem. Hang in there.
Most software relies on software libraries to accomplish common tasks. A software library would contain things like the routines for opening a file. With word processors your open files. With Photoshop you open files. With Excel you open files. The SL viewer opens a whole bunch of files, which we never have to see. It is that VFS thing we see at startup.
Programmers rather than write code for all these common tasks use a software library with the code already written. There are numerous libraries. You may remember Kakado as the JPEG 2000 proprietary software library. The Lab and Firestorm use this library. It is proprietary and it costs money to use it. Also, Havok, the physics engine used by Linden Lab, is another proprietary software library. None of the third party viewers have licensed Havok, AFAIK.
These other proprietary software libraries are written by third parties. Those wanting to use them license them. They pay money. This allows experts to specialize in their field and make a living publishing their library. They save other companies, like Linden Lab, enough time that it’s worth it to purchase the libraries. In general, we get better software because of software libraries.
For viewers the problem with libraries is that one cannot usually mixed 32-bit and 64-bit libraries in a 64-bit software program. So, so this is not just a matter of writing a new viewer it’s also a matter of coming up with replacements for 32-bit software libraries that have no 64-bit counterpart. To a large extent this is the reason Linden Lab has not written a 64-bit viewer.
There is a thing known as Large Address Aware (LAA). This is a process that some software uses to get around 32-bit memory limits. Some third party viewers use this technique to make what they have called 64-bit viewers.
I am not that familiar with LLA or its limits. My understanding is that it allows a mix of 32-bit and 64-bit software in 32-bit operating systems. Still, it requires 64-bit hardware.
I’m not sure if this is the type of viewer that the Firestorm team is thinking of releasing or if they’re going with a real full on 64-bit viewer. I think they mean the latter.
To me Jessica’s post is unclear about what it is they’re going to be releasing when. From all I have heard the Firestorm Viewer that will include things like; Material System, Interest List, Collada Export, and some other new Linden code is not going to be released until early 2014.
So, the ‘new shiny’ to be released at the end of the month would be their 64-bit viewer, but without the new features they expect release in early 2014.
I keep hearing that the Firestorm Team will catch their viewer up to the Linden Lab viewer. But, the way the Lab releases code the team seems to be falling further behind. So, I am left wondering how the Firestorm Team is going to support multiple viewer versions; SL Firestorm Viewer, OpenSim Firestorm Viewer, and the 64-bit Firestorm Viewer for both SL and OpenSim.
There is also the issue of the Mesh Deformer. In the OpenSim world this feature is moving ahead. Most third party viewers have an experimental version with the Mesh Deformer built-in. In my thinking this adds another version.
Of course, manpower in volunteer organizations is not necessarily assigned to projects. Often volunteers choose their projects. So, it is not a matter of whether someone is going to work on a 64-bit viewer or not. But, it is going to be a matter of who’s available to work on the main Firestorm Viewer. The fewer people working on the Firestorm Viewer the further it may fall behind.
Only time will tell if the Firestorm Team will be able to catch up as they say. Or if they’ll keep missing the curveballs that Linden Lab throws them. I’d say we’re on strike two now.
There seems to be a degree of ego, or maybe its paranoia, in this latest announcement. The Firestorm Team has done work on the 64-bit Firestorm Viewer and released the code. They deserve their props for this. Their work is awesome. Thanks.
While some other developers may or may not jump on the code and push a viewer out and some developers have already released LAA versions of their viewers, prior to this code release, the warning seems a little odd. It also seems to be a bit of claim staking for 64-bit glory, to which I think they are entitled. Whatever, new viewers with lots of changes should always be tried with some measure of caution and trepidation. Going from 32-bit to 64-bit is LOTS OF CHANGES.
I am looking forward to trying a 64-bit viewer.
Pingback: Firestorm 64bit for Windows | Wurfi's Second Life
Thanks for a clearer explanation.
I think you misunderstand the Firestorm release schedule. “We really want to get Materials, DAE Export and other things we’ve been working on out to you before 2014, so we’ve decided to release a public beta.” Says to me that we will be seeing that release in addition to a 64 bit Experimental release (perhaps just for self compilers?) by the end of October.
At any rate, the FS team is moving forward, hopefully closing in on the latest from LL.
You may be right.
I wish there was a 64 Bit Viewer. I am using a 64 Bit Linux and was not able to run SL at first, because I was unaware that I need to install 32 Bit Libraries. Now it works, but I am not able to see Youtube Videos via Shared Media in SL, because the installed Flash is 64 Bit. So that sucks, because I was trying to show SL machinima at my place inworld.
Maybe I missed something Nalates, what advantage is 64 bit over 32. I use windows 7 now but other than improvements in the interface, I see no differences in speed, etc.
Whether you see a speedup depends on what tasks you do. Text processing and net surfing see little difference. Video processing (not watching) is a data intense task helped by 64-bit. I see improvements in some Photoshop tasks, especially with for print images. In SL I see less page faulting.
As always, you handled the topic perfectly, just enough information simply presented to make it easy to understand.
Thanks for the kind words.
You can try already a Alpha build of Singularity viewer for Windows 64 Bit. You can find the download link here:
A different implementation of the one you will find from firestorm.
Been using it for a couple days already and so far am impressed by its stability.
Thx for the tip. Good to hear you are finding it stable.
Best explanation for non-geeks on the subject i’ve yet seen… very well written and clear. 🙂
The only benefit of a 64bits viewer over a 32bits one is the virtual address space: even when ran on a 64bits system, the virtual address space usable by a 32bits viewer is limited: 4Gb when ran on a 64bits system, 3Gb when ran on a 32bits system configured to reclaim only 1Gb for the OS, 2Gb on 32bits system that are not properly configured: e.g. the default 32bits Windows (XP,Vista,7 at least, not sure for 8/8.1).
As most of you already noticed, the mesh viewers and now, the materials viewers have been consuming more and more memory… There’s also the new “interest list” code on SL servers that sends too much data (or at least much more than what it did in the past) and causes all objects and avatars in the sim to be sent to the viewer (only textures loading is delayed till the said objects/avatars are in your FOV).
For example, with materials, each face of any object may now bear up to three textures (instead of 1) at resolutions up to 1024×1024 with 4 channels (RGB + alpha), i.e. up to 4Mb for each texture.
The net result is that the virtual address space fills up quickly, and even measures such as texture discard level (basically, increasing the discard level for a texture means reducing the texture resolution) have limits, especially since the virtual address space gets more and more fragmented as the session lasts longer and as avatars and objects come and go in/out your camera FOV.
At some point, the memory allocator will simply not be able to find a chunk of memory large enough to fit the next texture or vertex buffer, and with most viewers, this will cause a crash (the Cool VL Viewer can catch some of these memory failures, but only for some types of allocations (textures, vertex buffers…), not for all “automatic” allocations handled by the default C++ allocator). In fact, most of the crashes encountered with today’s viewers are due to virtual memory space exhaustion/fragmentation.
With a 64bits viewer, you lift almost completely the virtual address space constraint, because you can address up to 1677216 Tb (Terra bytes), and there will always be enough virtual address space to map your physical memory (and also your swap space if needed). You therefore avoid all the crashes and can use more memory (on a 8Gb system, your viewer will be able to use more than 4Gb).
Thanks for explanation.