Clear-cut Explanation on why Recommend 32-bit Version?
-
It's known to (allegedly) cause issues more often than the 32-bit version. But I don't have any hard evidence to prove that. You should be fine going with the 64-bit version.
Also, point for you for making a research before asking the question. I just wish I had a better answer, but it's the only thing I know regarding this issue.
-
@pafflick @Ayespy @Vivaldi-Moderators
Thanks! Will I lose settings / bookmarks if I install x64, and is there anything specific I should do to prepare for the change (since we'll be installed in different directory etc)?
Also, is multi-threaded performance likely to be better? I'm currently using the settings recommended here, including the ramdisk configuration. Will this still help (not that I'm really positive it helps a ton anyway).
-
It definitely should not and there's not much reason to, but to stay on the safe side you should backup your profile. Just open vivaldi://about and one of the last lines tell you where your profile is located. I recommend deleting cache (not cookies, just cache) as this will make your profile smaller for backup and might remove some cache that may be sensitive of the architecture change.
The tips do have some impact. Especially when speaking about disabling features. Regardless, the additions by WillyYu and other changes by the team have enhanced the performance a lot since that post in ghacks.
As for your points about x64:
- x64 has advantages, it may work much better for high data actions, like media playback for example. For all the rest it may be the same. x64 though might use a bit more RAM, but this may only be a problem if you have few RAM.
- x64 only works on x64 OS, but x86 can run on both x86 & x64 OS. But then web browsers send the OS architecture to the website which can then use this information to point to the correct version.
- x64 are not more "buggy", they just might be because there are less people using it, so less bug reports for specific bugs that may exist only on the x64 version.
-
On the Windows platform, 64-bit Chrome/Chromium has been around for almost 3 years, so that codebase is now very mature. If you have a 64-bit OS on 64-bit hardware, it makes sense to run a 64-bit application -- most of the time -- since it's native to the platform. In the Mac world, 64-bit applications are the norm.
I only use Windows for work purposes, but from what I remember, the biggest issue that limited 64-bit Chrome's initial uptake was that it did not support 32-bit NPAPI plugins, which was a big showstopper at the time. Today, 64-bit systems are common and 32-bit systems are on their way out. Aside from office applications where data interchange with 32-bit apps can still be an issue, there are few (if any) compelling reasons to use legacy 32-bit versions of applications on 64-bit systems anymore.
-
@An_dz @Vivaldi-Moderators
Thanks, all. Backed up as per your instructions, but as you said, it wasn't needed. It just installed in the x86 folder (which I assume is ok?).
While we're on the topic... as you mentioned, disabling some features as per the ghacks post definitely helped. But any opinions on using a RAM disk for the cache--whether it has a palpable influence on performance? In my case, I have 8GB RAM but a relatively slow processor (i5200u 2.2ghz).
Love love LOVE Vivaldi, but it isn't the process (even when tinkering with flags etc.) so any feedback on RAM drive use/tips on optimization (or links to further tips) would be really appreciated.
I also just have to say that I am so impressed by the friendliness of these forums and also the quick responses from the moderators, that aren't your typical tech "attitude" toward those of us who are less knowledgeable (forgive me, but perhaps you know what I mean).
Thanks!
-
@onenil said in Clear cut explanation on why recommend 32 bit version?:
Thanks, all. Backed up as per your instructions, but as you said, it wasn't needed. It just installed in the x86 folder (which I assume is ok?).
The folder is just for users' organisation, it makes zero difference where the executable is.
While we're on the topic... as you mentioned, disabling some features as per the ghacks post definitely helped.
If the feature does not run, it does not compute, aka does not use CPU.
But any opinions on using a RAM disk for the cache--whether it has a palpable influence on performance? In my case, I have 8GB RAM but a relatively slow processor (i5200u 2.2ghz).
Short Answer: Yes, placing cache in RAM CAN be faster. at least when the browser does use the cache AND this cache can't be found on the queued area.
Long Answer: The CPU is always the fastest thing on a computer, many people assume that only a fast processor is what it takes for a good computer, that was true in the 80s and early 90s. But a computer is much more than just a processor. If you have a crap RAM or a crap HDD the CPU won't help.
As a rule of thumb the RAM is generally 100-1000 times slower than the CPU and the HDD can easily be up to 100000 times slower than the RAM. So placing cache on RAM means that it COULD be faster. Modern computers have hundreds, if not thousands, of "tricks" to make it run faster.
When you run a software it will be executed by the CPU, the CPU is super fast, but if all data remained in RAM it means that each time the CPU required a non-hardcoded data (like the calculation of some x) the CPU would need to sit idle for 100 clock cycles until the RAM could send it.
So CPU nowadays have what we call caches, some even have 3 levels of cache. Those "caches" you hear about on the processors are basically super-ultra fast RAMs, L1 caches generally can run at the same speed as the CPU, L2 and L3 are slightly slower, but still ultra fast compared to the main RAM.
But caches can't be infinite, they are fast because they are small and they are also small because they are expensive. So you can't put everything on them, just a very few bytes. The computer puts what it thinks is more often used and more often to be used. But many times this info is not there, and so it 'asks' the RAM if it has it, this process will take a minimum of 100 CPU clock cycles until the RAM can find and send it. But in the worst case scenario where it's not even on RAM it has to read directly from the disk and then it can take a million CPU clock cycles to get the data.
In this worst case scenario the RAM browser cache will make things faster, but only when this scenario happens, which is when the data can't be found both on CPU caches and your PC RAM. It won't make a difference if you have a page open and open a link from the same page, because even though much of the data is on the "browser RAM cache" there's a huge possibility that this info is already in the CPU caches or the queued RAM cache. But as webpages are bigger every day, this can happen quite a few times, enough to make a difference.
This info is not 100% complete or correct, I tried to explain it in a simpler way without nitpicking. But has the essence.
-
@onenil I'm personally cautious when it comes to making system-level changes or using undocumented command line switches to change the browser's behaviour at a low level.
Desktop Operating Systems are well tuned for tasks like web browsing, word processing, etc. Applications, like web browsers, are also tuned to run well on desktop systems. I personally wouldn't make any optimizations unless I first used performance tools on my system to understand what's slow and why it's slow. Then I'd make prescriptive changes to address specific issues and use the measurement tools again to verify that I got the performance gains that I was expecting. I have not employed any tricks on my system (outside of Vivaldi's menu settings) to make web browsing faster.
However, what if you're doing something on your system that it was not really meant/tuned/optimized to do? One time, I had to build a fairly large piece of software on my laptop; I had lots of RAM and a fairly fast processor but the disk was slow. Compilers generate a TON of temporary/intermediate files and the process was taking forever. The slow disk was the bottleneck, so I created a RAM disk and moved my build directory to that drive. I temporarily sacrificed system memory from other tasks but that sped up the software build considerably. When I was done, I reverted back to the normal system configuration.
System performance tuning is a very technical process and generally very specific to the tasks (workloads) running on your system. Generally, any changes that you make (tweaking software) will make some things faster and other things slower. What may make one person's system faster will not necessarily make things better for you, and could even have negative effects because your system hardware and workloads are different.
Just my opinion...
-
Just thought you might be interested in this bit of information to further validate the opinions given previously...
From the Google Chrome release team's Chrome 59-beta announcement:
In order to improve stability, performance, and security, users who are currently on 32-bit version of Chrome, and 64-bit Windows with 4GB or more of memory and auto-update enabled will be automatically migrated to 64-bit Chrome during this update. 32-bit Chrome will still be available via the Chrome download page.
So, if you're running 64-bit Windows and have at least 4GB of memory, Google recommends running a 64-bit version of Chrome.
Based on that, I'd say the only reason why you should run a 32-bit version of Vivaldi is if you're running 32-bit Windows or if you have memory constraints.
-
@liyin Thanks, that's good to know. Now I'm very curious to get confirmation whether or not there are any stability issues with 64-bit Vivaldi on 4GB systems.
-
I'm switching to the 64-bit version of Vivaldi on my PC, to see for myself if I can notice any improvement or any new issues. I'm gonna stick with the 32-bit version on my tablet since it has a 32-bit OS anyway...
-
-