I was reading about some VBA performance optimisations and learned that there's a difference between optimising for memory usage versus performance in 32bit VBA applications.
An example of memory optimisation would be using the smallest variable appropriate for your application, eg using an Int instead of a Long of a Float.
For performance it appears to be about matching the variable size in bits to the OS so that it doesn't have to do any type conversions from 8bit to 32bit 'under the hood'.
Can I assume this logic extends into the 64bit version of Excel 365 running VBA7?
Ie, is a LongLong (64bit) the most performance optimised approach to working with integers at the cost of memory use versus alternatives such as the Long or Int?
EDIT: There's an answer here that shows the results of testing on 64 bit operating systems and the answer was to use Longs but the optimisation doesn't account for much in terms of time saved (13s over 1 billion operations).
In 64 bit standard integer size is 32 bits (and signed). Memory addressing is 64 bit (and unsigned). CPU is optimised for both.
The major way programs are optimised for speed versus memory is to unwind functions to inline code for speed if it can. Function calls are slow.
x64 has a faster calling convention than x32 on Windows. In x32 all parameters are passed on the stack, an area of memory so slower than a register. In x64 they are passed in registers where ever possible, ie if it runs out of registers it will pass the rest on the stack..
Related
I am looking into Google V8 Javascript Engine. It is said that they are having problems for porting to 64 bit systems.
What kind of programming or programming constraints can make a program a 32-bit or 64-bit specific, apart from building and testing them on 64 bit machine with 64 bit settings ?
You may check this wiki which says:-
The main disadvantage of 64-bit architectures is that, relative to
32-bit architectures, the same data occupies more space in memory (due
to longer pointers and possibly other types, and alignment padding).
This increases the memory requirements of a given process and can have
implications for efficient processor cache utilization. Maintaining a
partial 32-bit model is one way to handle this, and is in general
reasonably effective. For example, the z/OS operating system takes
this approach, requiring program code to reside in 31-bit address
spaces (the high order bit is not used in address calculation on the
underlying hardware platform) while data objects can optionally reside
in 64-bit regions.
Is it always the case that the 64-bit release built program is faster than the 32-bit?
Execution happens on 64-bit machine for both.
Thanks
It depends what the program is doing.
If it was a chess engine, for example, which used bitboard representation of piece placement and movement, then I would expect it to be much faster than the 32-bit version.
For other compute-intensive applications then it should be faster as well, given the additional registers available to x86-64 processors.
However this is not true for all programs, for example if the problem is memory intensive and that memory is read from the filesystem, then the 64-bit version may be slower due to I/O.
In most cases, yes, it is. 64-bit program can enjoy more CPU registers, bigger address-space (which can probably speed-up memory allocations on the heap even if the program does not actually need more then 2GB) so it is easier to the heap management to deal with heap fragmentation.
But it may also be slower in some cases, mainly due to the fact that 64-bit binary is in general bigger and eats a bit of more memory then its 32-bit counterpart. Every pointer takes 8 bytes instead of 4. That may cause difference whether important data fit into a CPU cache or not. And if it is a data used in a tight computation loop, it can make the speed difference. However "normal" programs hardly every hit this problem.
x86-64 should be faster than x86-32.
x86-64 has more registers.
Its can do 64-bits operations in a single instruction.
It used improved __fastcall. The first four parameters you are passed to function is passed via register.
Alway use 64-bits if you can.
I don't understand what 32 bit and 64 bit means. It seems that people say 64 bit computers run faster - but why? Does it mean that there are 64 bit integers instead of 32? If it's something like that, is there a way to write a program to determine if we're on a 32 bit or 64 bit machine?
On 64-bit machines pointers are 8 bytes (64 bits). On 32-bit machines they are 4 bytes (32 bits). Thus we can determine by the size of a pointer what we are dealing with, in it's simplest form:
#define IS_64BIT (sizeof(void *) == 8)
The only drawback is that a 64 bit computer running in 32 bit mode will register as 32 bit. Of course, this isn't actually important as for all intents and purposes a 32 bit OS on a 64 bit computer will be a 32 bit computer.
There's actually several different things your asking here.
First of all there's the CPU. Most modern day CPUs (within the past 5-years approx) will support 64-bit.
Now just because the CPU supports it doesn't mean the OS supports it, that's where you have either 64-bit OS or 32-bit OS (32-bit is also known as x86, there's small technical differences in the x86 refers to the CPU instruction set, but for most common usage x86 and 32-bit are interchangeable)
Even if the OS supports it, it doesn't mean the specific program you're running supports 64-bit. What most (if not all?) 64-bit OS's do is they have a 32-bit emulation mode so you can still run 32-bit programs.
Now for your question of how to determine which architecture you're running on, the most reliable way is to ask the OS through some API call.
As for why 64-bit is sometimes considered faster, it because with 32-bits it is only possible to address 4GB of memory, whereas with 64-bit the limit imposed by address space is much higher (as in about 4 billion times higher) and the limiting factor is hardware not address space. As to when and why more memory is faster, that's a separate topic altogether.
64-bit machines do not run faster than 32-bit machines except in cases where 64-bit math is being done or in cases where more than 4 GB of RAM is needed.
64-bit AMD (and later Intel) machines run faster than 32-bit x86 machines because when AMD designed the new instruction set they added more CPU registers and made SSE math the default.
32-bit x86 systems can waste a lot of CPU time pushing data around in RAM, while a x86_64 system can store that data in CPU registers instead. Registers are much faster than level-1 CPU cache. Having more registers also saves CPU instructions that otherwise need to store the old value of a register in RAM, load in a different value from RAM, then load the original value back from RAM.
In some especially register-starved cases the extra registers can gain 30% speed for a program. The benefit is usually much less than that.
The speed benefits from assuming SSE2 are many. In 32-bit CPUs SSE instructions may or may not exist, so to use them the software needs to have clumsy test code and two (or more!) implementation of the math functions. Most software just doesn't care enough and so it never bothers, always falling back on x87 FPU math from the 486 days. The 64-bit CPUs made SSE2 a required part of the instruction set, so all x86_64 programs are free to assume it exists and use it in all cases.
64bit computers do not run faster, per se. It just can support higher precision (larger integers, more precise floats).
In some rare cases, libraries might jam two 32bit numbers into 64bits to perform a large number of parallel operations, possibly resulting in potentially up to 2x speedup. This might occur for some highly optimized scientific/numeric libraries, or in special applications that (for some reason or another) have been highly optimized at a very low level. For example, some multimedia software. It should be noted that such applications could always have made this tradeoff even in 32bit mode, but chose not to; they are merely trading away precision (which they may not need) for parallelism.
Operating system benchmarks which reveal faster performance (maybe <10% improvement) are not necessarily related to 64bit-related optimizations. 64bit architectures may be correlated with having for example more registers or advanced features that programs can take aware of [citation: http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks ], which may be the cause of a performance difference (as well as other variables).
How to determine whether a CPU is 32bit or 64bit depends on what OS you are using. For example on Linux, you can call uname -a, though there's probably a better way to do so. If you're using C/C++, see the other answer for a way to determine it in a program.
Is there any specific sectors of Software Engineer/Computer Science where there's a marked difference when developing for 64 bit systems? I've been coding for around 10 years now, and since the break of 64 bit systems, my code hasn't changed one bit.
What applications that a single coder can code as a side project require you to use 64 bit technology?
Anything that requires more than 4 GB of working and program memory would certainly qualify, since that is the maximum amount of memory that a 32 bit system can address directly.
Since 64 bit numbers can reside in the CPU registers, calculations requiring numbers of these sizes would see a performance improvement.
Aside from address space or big calculations, doubling your word size helps more in the low level stuff, and mostly for people who are going to be doing kernel hacking or writing device drivers. For instance, let's say you have a stream of bytes from a network connection and you have to process them. You can now pull those bytes in from main memory to CPU registers 8 at a time rather than 4. But I would think you need a "64 bit aware" string library to take advantage of this.
Anecdotally, we did observe a performance increase when upgrading from 32 bit SQL Server to 64 bit SQL Server (2005) on the same hardware (a 64 bit machine).
We recently ported some of our internally-used libraries to 64-bit. The C code didn't change at all; we just had to get the 64-bit versions of the third-party libraries we link against and figure out which new compiler directives we needed to use. The biggest headache was finding 64-bit versions of our dependencies and refactoring our build system to handle both 32-bit and 64-bit.
That's not to say that other software wouldn't require modification. For example, if you pack your data to fit within word boundaries, you might now be inclined to pack it differently when programming for a 64-bit system.
If you need to ask, you probably will not get any advantage, as you are probably not building into your code any assumptions about size of ints. Rather few use cases, and all fairly low-level, will see any speedup. Bignums and heavy integer arithmetic on very large numbers will be quicker (like crypto).
Obviously, a 64-bit processor has a 64-bit address space, so you have more than 4 GB of RAM at your disposal. Does compiling the same program as 64-bit and running on a 64-bit CPU have any other advantages that might actually benefit programs that aren't enormous memory hogs?
I'm asking about CPUs in general, and Intel-compatible CPUs in particular.
There's a great article on Wikipedia about the differences and benefits of 64bit Intel/AMD cpus over their 32 bit versions. It should have all the information you need.
Some on the key differences are:
16 general purpose registers instead of 8
Additional SSE registers
A no execute (NX) bit to prevent buffer overrun attacks
The main advantage of a 64-bit CPU is the ability to have 64-bit pointer types that allow virtual address ranges greater than 4GB in size. On a 32-bit CPU, the pointer size is (typically) 32 bits wide, allowing a pointer to refer to one of 2^32 (4,294,967,296) discrete addresses. This allows a program to make a data structure in memory up to 4GB in size and resolve any data item in it by simply de-referencing a pointer. Reality is slightly more complex than this, but for the purposes of this discussion it's a good enough view.
A 64-bit CPU has 64-bit pointer types that can refer to any address with a space with 2^64 (18,446,744,073,709,551,616) discrete addresses, or 16 Exabytes. A process on a CPU like this can (theoretically) construct and logically address any part of a data structure up to 16 Exabytes in size by simply de-referencing a pointer (looking up data at an address held in the pointer).
This allows a process on a 64-bit CPU to work with a larger set of data (constrained by physical memory) than a process on a 32 bit CPU could. From the point of view of most users of 64-bit systems, the principal advantage is the ability for applications to work with larger data sets in memory.
Aside from that, you may get a native 64-bit integer type. A 64 bit integer makes arithmetic or logical operations using 64 bit types such as C's long long faster than one implemented as two 32-bit operations. Floating point arithmetic is unlikely to be significantly affected, as FPU's on most modern 32-bit CPU's natively support 64-bit double floating point types.
Any other performance advantages or enhanced feature sets are a function of specific chip implementations, rather than something inherent to a system having a 64 bit ALU.
This article may be helpful:
http://www.softwaretipsandtricks.com/windowsxp/articles/581/1/The-difference-between-64-and-32-bit-processors
This one is a bit off-topic, but might help if you plan to use Ubuntu:
http://ubuntuforums.org/showthread.php?t=368607
And this pdf below contains a detailed technical specification:
http://www.plmworld.org/access/tech_showcase/pdf/Advantage%20of%2064bit%20WS%20for%20NX.pdf
Slight correction. On 32-bit Windows, the limit is about 3GB of RAM. I believe the remaining 1GB of address space is reserved for hardware. You can still install 4GB, but only 3 will be accessable.
Personally I think anyone who hasn't happily lived with 16K on an 8-bit OS in a former life should be careful about casting aspersions against some of today's software starting to become porcine. The truth is that as our resources become more plentiful, so do our expectations. The day is not long off when 3GB will start to seem ridiculously small. Until that day, stick with your 32-bit OS and be happy.
About 1-3% of speed increase due to instruction level parallelism for 32-bit calculations.
Just wanted to add a little bit of information on the pros and cons of 64-bit CPUs. https://blogs.msdn.microsoft.com/joshwil/2006/07/18/should-i-choose-to-take-advantage-of-64-bit/
The main difference between 32-bit processors and 64-bit processors is the speed they operate. 64-bit processors can come in dual core, quad core, and six core versions for home computing (with eight core versions coming soon). Multiple cores allow for increase processing power and faster computer operation. Software programs that require many calculations to function operate faster on the multi-core 64-bit processors, for the most part. It is important to note that 64-bit computers can still use 32-bit based software programs, even when the Windows operating system is a 64-bit version.
Another big difference between 32-bit processors and 64-bit processors is the maximum amount of memory (RAM) that is supported. 32-bit computers support a maximum of 3-4GB of memory, whereas a 64-bit computer can support memory amounts over 4 GB. This is important for software programs that are used for graphical design, engineering design or video editing, where many calculations are performed to render images, drawings, and video footage.
One thing to note is that 3D graphic programs and games do not benefit much, if at all, from switching to a 64-bit computer, unless the program is a 64-bit program. A 32-bit processor is adequate for any program written for a 32-bit processor. In the case of computer games, you'll get a lot more performance by upgrading the video card instead of getting a 64-bit processor.
In the end, 64-bit processors are becoming more and more commonplace in home computers. Most manufacturers build computers with 64-bit processors due to cheaper prices and because more users are now using 64-bit operating systems and programs. Computer parts retailers are offering fewer and fewer 32-bit processors and soon may not offer any at all.