Re: Vim 8.1 is released!

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