Bram Moolenaar wrote:
Bram Moolenaar wrote:
Hello Vim users!

Announcing:  Vim (Vi IMproved) version 8.1

This is a minor release with many small improvements and lots of bug
fixes.  The main new feature is the terminal window.  I have put up a
few screenshots on the Vim website:
    It's not clear if this that binary is a 64-bit version ...
32-bit runs between 10-15% slower on 64-bit machines.

It is 32 bit.  Previous comparisons show that the 32 bit version is a
bit faster.  Where do you get the information that it would be slower?
   Various places and own benchmark.  It depends on which operations
you are doing and if the program can use more data.  If you take
a 32-bit prog and keep all the data at 32-bit sizes, then you have alot
of masking and shifting.  In those cases  64-bit can run 1-7% slower,
but I tend to work with larger files and being able to edit those
with out using a swap or cache file noticeably speeds things up.  Less
so today with SSD's, but unless you are using the PCI-based SSD's, that
are really non-volatile ram-disks attached to the system-bus -- those
operate on a similar order as SSD's.

Going back to 2005, some numbers:

*TEST: CPU - Integer Math*
PT6 64bit, Win2003 64bit, Result = 193.3
PT6 32bit, Win2003 64bit, Result = 92.9
PT6 32bit, WinXP 32bit, Result = 92.9

*TEST: CPU - Find Prime Numbers*
PT6 64bit, Win2003 64bit, Result = 217.7
PT6 32bit, Win2003 64bit, Result = 158.2
PT6 32bit, WinXP 32bit, Result = 157.9

*TEST: CPU - Data compression*
PT6 64bit, Win2003 64bit, Result = 2584.6
PT6 32bit, Win2003 64bit, Result = 2578.6
PT6 32bit, WinXP 32bit, Result = 2582.77

*TEST: CPU - Integer Math*
PT6 64bit, Win2003 64bit, Result = 210.0
PT6 32bit, Win2003 64bit, Result = 111.6
PT6 32bit, WinXP 32bit, Result = 112.7

*TEST: CPU - Find Prime Numbers*
PT6 64bit, Win2003 64bit, Result = 254.7
PT6 32bit, Win2003 64bit, Result = 192.4
PT6 32bit, WinXP 32bit, Result = 191.8

*TEST: CPU - Data compression*
PT6 64bit, Win2003 64bit, Result = 4846.1
PT6 32bit, Win2003 64bit, Result = 3244.5
PT6 32bit, WinXP 32bit, Result = 3125.6

Apple tends to distort their test results though -- it turns out when they
went with x86, they had wait loops in x86 drivers so the Windows versions
of the same program would run 15-20% slower.  People found out when they
loaded 3rd party drivers and the same programs were now 10-15% faster. Created a minor squawk at the time, but Apple customers tended to see
what they wanted to see.

Another: (5 yrs ago)
... in general you may expect a 2-20% performance gain from mere recompilation of a program - this is explained by architectural changes in 64-bit processors [1]. (on the referenced page:) Adobe Company claims that new 64-bit "Photoshop CS4" is 12% faster than its 32-bit version.

This site: shows a mix, but they show slowdowns even on math functions, so I wonder if they
were using single-precisions or 32-bit integers rather than larger numbers.

The areas where 32-bit was faster -- had 64-bit being 1-7% slower in some tests,
but where 64-bit was faster -- multimedia by 30-50%, SSL connections/crypto
were an average of 15-20% faster.

In many cases, 32-bit SW running on 64-bit ran slower due to all the
translation overhead.

Look at a 32-bit programs stack sometime -- nearly every stack level requires another level just to align the data.
If you have low-memory (<=4GB), which was true even for many 3-5 years ago,
32-bit may have an edge, but if your system has >=16G, it's likely to have
notably better perf on 64-bit.  There's where your perf can really shine --

If you have a large amound of memory -- more things can be kept in memory even when the app is not running -- linux is real good about this -- it will use all of free memory for filesystem caching. Windows -- not quite as much, but most
of window's cache memory is hidden on the "free list" -- and will show up as
"free memory" -- even though cache memory on linux is also effectively free
as well -- they just count it as being used -- but both can be reallocated
to program nearly instantaneously (nothing is written to disk -- the memory just
has to be zeroed, at most and sometimes not even that).

Another factor -- is how much of the application can be done asynchronously -- in the background so the user doesn't have to wait. Adobe went to background saves in PS6 -- so the save dialogue came back immediately. In PS5, it could take 20-40 seconds for a 4GB file.

In the firefox family, they hurt possibilities for faster I/O by using small I/O sizes. They use a 4k read/write size for everything (disk and net), whereas
optimal is closer to 16M for fast links.  So there 64-bit won't help due to
the small I/O sizes.

So there are MANY places on the web that show 64bit as faster for most ops -- and that the gap is increasing due to wider bus transfer sizes and higher
multipliers (DDR) for those widths.

All that said -- everyone see evidence to support their own point of view --
can you really find as much in the way of recent benchmarks that would support
32-bits being faster -- especially on systems with >16G of memory.

There was a 64 bit version somehwere, but it isn't very popular.

You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit

--- You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to