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:
https://www.vim.org/vim-8.1-released.php
----
    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:
(https://www.passmark.com/forum/performancetest/283)

Intel:
*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

AMD:
*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)
https://www.viva64.com/en/k/0003/
... 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: http://www.iinuu.eu/en/it-guru/windows-7-32-vs-64-bit-performance-benchmark 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 http://www.vim.org/maillist.php

--- 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 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to