To 64 or not to 64?



  • I would like to run Vivaldi on a daily basis, and use it as much as I can. I installed the 64 bit version just because it was there. I really do not know what the implications of "64 bit software" are or why software developers seem to have to write two versions of every program they make these days. Doesn't it just allow bigger numbers with which to address the memory, thus also permitting larger spaces of memory to be address if necessary? Since the 32 bit version of Vivaldi seems to be regarded as "more developed", why would I bother with the 64 bit version? On the other side, why would developers bother starting with 32 bit when, in the long run, 64 bit will be standard? Is it just because there are more and better developed third party libraries which currently only support 32 bit programs? Suppose I switch to the 32 bit version because, currently, support is better. On what basis would I make the decision ever to "switch" to 64 bit?! Believe it or not, I am a techy - a developer, even (although with high level languages). The whole 64 bit 32 bit thing seems like nearly as much of a mess as the TV industry was in when someone thought it would be "better" for all home TVs to have a 16:9 aspect ratio rather than 4:3. The only difference is that I do agree that it has become necessary to address a much larger memory space!



  • Clue: software changes that require hardware upgrades are very popular with hardware sellers.



  • since I saw that IE is 32 bits I changed my vivaldi to 32 bits too in a 64 bits PC then I use the same downloaded vivladi for 2 PC and 32 bit netbook.


  • Moderator

    With browsers, which do not perform high-level equations or render complex 3D objects or color spaces as a rule, 64-bit mostly only confers the benefit of allowing the program to gobble up more RAM. In theory, the 64-bit version should run a teeny bit faster. In practice, owing to resource constraints, it often runs a little bit slower.



  • I use 64 bits mainly because I can and for the sake of helping them bugtest it, and sure enough it is slightly more buggy than the 32-bit I run on my tablet.



  • @Terryphi:

    Clue: software changes that require hardware upgrades are very popular with hardware sellers.

    True, but, in general, there is a need to be able to address a larger memory space - even if the vast majority if applications don't require such vast quantities of memory individually. I don't think conspiracy is to blame for 64-bit architecture.

    @Ayespy:

    With browsers, which do not perform high-level equations or render complex 3D objects or color spaces as a rule, 64-bit mostly only confers the benefit of allowing the program to gobble up more RAM. In theory, the 64-bit version should run a teeny bit faster. In practice, owing to resource constraints, it often runs a little bit slower.

    Why, in theory, should it run a bit faster? Why, in practice, does it often run slower?

    @terzaerian:

    I use 64 bits mainly because I can and for the sake of helping them bugtest it, and
    sure enough it is slightly more buggy than the 32-bit I run on my tablet.

    That was also partly my thinking. If 32-bit runs through an "emulation layer" in order to work on 64-bit hardware, then I am in favour of supporting the native 64-bit version to help push through the change. Is this flawed logic?


  • Vivaldi Team

    http://peacekeeper.futuremark.com/ nice site for testing different bits and browsers if you are interested. (although it doesn't cover the browser 100% I belive it displays a good image of the differences)



  • Well, that was certainly fun:

    http://peacekeeper.futuremark.com/results?key=AfgL&resultId=5914692

    The top result - Chrome 40 - is actually the 64 bit Vivaldi. Opera 12 holds its own, although the result makes no hint that the html5 video poster image failed to animate. That said, Opera 12 outperformed them all on the large ripple test. Not bad for an obsolete, niche rendering engine!

    Anyway, it's a little off topic from my original concern. Rather late in the discussion, I decided to see what Wikipedia had to say and, as far as I can tell:

    [ul]

      • 32 bit stuff runs in emulated mode on modern Windows installations
      • creating 32 bit programs is sometimes easier because they are still (slightly) better supported by libraries and drivers
      • 64 bit memory addressing not only allows for more memory, but can also improve the way that memory is managed (hence the possible speed advantages
      • there is some motivation to create 32 bit programs in order not to limit your user base to the most recent platforms
        [/ul]

    I think I'll stick with trialing Vivaldi 64-bit, as a sort of "vote" for that version. To be honest, if I'm running a Raspberry PI, or an old XP netbook, or some other "specialist" or "resource limited" kit, then I want a browser dedicated to the limitations of those platforms. With Vivaldi, I'm looking for a power-user's browser to run on a modern PC. As far as I'm concerned, they can ignore obsolete architectures!



  • Then again, while it's certainly true that 64bit apps can technically access more memory, it's really a non-issue with Chromium-based browsers as they spawn a new process for each opened tab, therefore allowing every single tab access to the full 4GB of memory even on 32bit systems (so it's gonna be a while before we run into a memory limit with them), and then there's also the fact that while 64bit browsers allow the use of more memory, they also consume more of it with the same content. In case of Vivaldi, it's about 20-25 % more, according to my experience.



  • 20-25%?! That must surely be caused by the early stage of development rather than the 64-bitness per se.



  • Well, not really. 64bit app is expected to need more memory than its 32bit version. It might not, but it usually does, and it can be quite significant sometimes (and much worse than 20 percent). I'm not a programmer at all, so I can't really explain to you why and how exactly does that happen, and it certainly depends on the given app and data it works with, but one of the reasons is precisely "the 64-bitness" - don't forget that by going from 32bit to 64bit you need to use 8 bytes of memory instead of 4 bytes to store any memory address your app needs to work with at that moment.

    And if you look at other browsers, you'll see that their 64bit versions always use more memory than their 32bit versions, it's most certainly not limited to Vivaldi. 20-25 percent is more or less the average value.



  • I know from experience that for math intensive programs,,64 bits will be faster than 32 bit. For a pure math program (Floating point double precision) our 32 bit compilers produced executables which ran exactly twice as fast as the previous 16 bit compiler produced. And I would expect 32 vs 64 would be the same.
    For normal multipurpose use, I can see no observable difference between the 32 bit win 7 and the 64 bit version, although I haven't accurately benchmarked them. I bet for heavy duty rendering of video and the like 64 bit would be faster.



  • @terzaerian:

    I use 64 bits mainly because I can and for the sake of helping them bugtest it, and sure enough it is slightly more buggy than the 32-bit I run on my tablet.

    Indeed that's is the only real meaning of using the 64 bit version. ;)



  • 64 bit code should (in theory) run faster due to being able to support more memory, being able to support larger-sized numbers and having twice as many CPU registers. In practice the differences are a lot more subtle, and in order to understand it you really need to get your head around both how compilers work and the role of libraries in software development.

    Let me take libraries. When you write a program the chances are that you will be using a library. The most common example is when you want to display text onscreen. Either your chosen language packages the library you need or you have to manually include it (eg: #include <stdio.h>in C). Very rarely would a developer be writing code themselves that carries out the nuts and bolts of this. At present the state of libraries available is, shall we say, quite variable. Some have been optimised for 64bit support, some have token support and some are still the same 32bit versions. IF (and it's a big if) all libraries of your code were 64bit optimised you would get a speed boost, but such optimisation just isn't here yet.

    Another subtlety, which also involve compilers, is the increased number of registers. In theory, with more registers any compiled code (which would include libraries for memory management) would have less data shifting between the registers. The SSE2 instruction set which comes with 64bit CPUs are faster (eg: allowing for some parallel calculations which under 32bit would have to be done in series).

    What I have written here is a gross GROSS oversimplification of what is a fairly complex field. Not all the theoretical benefits of 64bit are currently realised due to the presence non-64bit-supporting libraries and a host of other compiler/library oddities. But I hope it gives a little insight.</stdio.h>



  • Is unlikely to be a problem of memory limitations. For each open tab is allocated a separate process (feature engine). At present, a 64 bit version of perhaps the aesthetic moment, rather than a useful practical.



  • @Case:

    Then again, while it's certainly true that 64bit apps can technically access more memory, it's really a non-issue with Chromium-based browsers as they spawn a new process for each opened tab

    True, but the multiprocess architecture is a drawback IMO, rather than an advantage. It's a pain when my Chropera is not responding and making my system lag, I press Ctrl+Alt+Del and I see 80 "opera.exe *32" processes and have no idea which one to kill. I'd rather have a single process as in the old Opera.



  • @Al-Khwarizmi:

    It's a pain when my Chropera is not responding and making my system lag, I press Ctrl+Alt+Del and I see 80 "opera.exe *32" processes and have no idea which one to kill. I'd rather have a single process as in the old Opera.

    using process explorer… it is sometimes possible to tell which of the processes is down/unresponsive - procexp displays different states of the process using different colours



  • @aga-mp:

    @Al-Khwarizmi:

    It's a pain when my Chropera is not responding and making my system lag, I press Ctrl+Alt+Del and I see 80 "opera.exe *32" processes and have no idea which one to kill. I'd rather have a single process as in the old Opera.

    using process explorer… it is sometimes possible to tell which of the processes is down/unresponsive - procexp displays different states of the process using different colours

    I hadn't noticed different colors for different states of the same process in Process Explorer (are you sure about that? …is it a new feature? ...or is there a setting that activates the feature?). However, you can definitely monitor CPU and memory usage for each process if you set up Process Explorer to display the relevant columns. Then you can kill the process that is hogging resources. However, AFAIK, you can't know in advance which of your open Chropera tabs/windows that will kill. (I haven't been following Chropera 15+ development closely enough to know if there is a way to determine which tab is associated with which process.)

    So I was tickled to discover that vivaldi://memory-redirect provides memory info and process ID (PID) for each Vivaldi process, including the web page title for each process that is a tab. This (combined with CPU usage info from Task Manager or Process Explorer) makes it easy to identify and close the correct tab if one of them is misbehaving, without having to close the whole Vivaldi browser.



  • @gdveggie:

    I hadn't noticed different colors for different states of the same process in Process Explorer (are you sure about that? …is it a new feature? ...or is there a setting that activates the feature?). However, you can definitely monitor CPU and memory usage for each process if you set up Process Explorer to display the relevant columns. Then you can kill the process that is hogging resources.

    as far as i can remember… i used it several times - even to kill some tabs in opera dev when they froze...
    but, it is possible, that i changed some settings somewhere in the procexp - i usually play with settings of apps... but now i really cannot remember what i have or havent done...

    edit:
    okay, now i am not able to reproduce it... i am not really sure how to quickly force an opera tab to hang up...
    and looking at the procexp settings, it is possible that i used a technic similar to what you described (with the cpu and memory usage) and not the process highlight colour... not really sure now, and i do not have time currently to find out - perhaps in the evening
    thus... sorry, mea culpa


  • Moderator

    If you have CPU Usage column, found in Process Performance, it will show as a text saying "Not responding" rather than the CPU usage.


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.