recently ive been redoing some of my 32 bit maths programs to run on 64 bit
much to my surprise these run at about 2/3 of the speed of their 32 bit equivalents
the programs straight compiled with ml64 using a bog standard make file
anyone else experience the same [ i wd have expected roughly the same kind of speed as theyre mostly single threaded ]
apologies for not posting the makefile stuff but its fairly trivial
regards mike b
Quote from: mikeburr on February 02, 2022, 10:44:35 PM
to my surprise these run at about 2/3 of the speed
Maked you AV exceptions for that files?
Here Android Studio all time is warning that tools can run faster if I make AV exceptions.
HSE
good idea ... but ....theres no virus protection on the system other than native windows [win 10] .. ive suspended some of the win10 crap and other junk as some of the analysis are very heavy on mill and take days to run so i want as much as the machine can give
also
...all instructions are 64 bit so im a bit surprised
just wondered if anyone had tested a direct conversion 32 - 64 and compared ... sort of thing JJ and Hutch might have tried ????
regards mike b
Quote from: mikeburr on February 03, 2022, 09:07:40 AMsort of thing JJ and Hutch might have tried ????
We tried every now and then :tongue:
Between 16- and 32-bit code, there is a factor 6-8 in terms of speed gain.
Between 32- and 64-bit code, there is a difference around 0-5%, in
both directions. It depends on factors such as cache misses, the length of pointers, etc. Sometimes 64-bit code is faster because modern 64-bit
compilers make more use of SIMD instructions than older (32-bit) ones; which is not true for Assembly: we always used SIMD instructions in 32-bit land.
64-bit code can address more than 2GB, which is occasionally an advantage.
64-bit code has more registers, which is occasionally an advantage (but I very rarely run out of registers in 32-bit code).
Mike,
I have never had any problems using SSE2 floating point instructions, what type of maths instruction set are you using ?
The old x87 set should be reasonably fast on recent (less that 10 years) hardware, I doubt conventional integer maths have ever got any faster.
hello mikeburr
how old is your PC?
Intel FPU had a terrible slow performance when dealing with NaN's, is you math program producing NaN's?
Mike,
As you can see, we speculate. Can you isolate a test case and post sources and executables?
thanks for the replies
im not interested in posting anything atm .. no sse or special instructions very basic set [ which wd run on much older machines than the dell t7500 96 gb dual intel 5700
which proved to be pretty rapid in some of your tests] .. very simple conversions from 32 bit
i ran two versions of a couple of programs ..the first doing a fairly complicated version of gcd
and the second to calculate the factors of say.. the first million numbers also computing phi and versions of sigma [used it as a test but timed by simply using the calendar clock .. about 45 seconds in x64 but a bit quicker in x32 !!!! ]
methods identical .. mill oriented .. except they place the outputs in linked lists [ 1 self sorted ] and paged for printing due to the volume of data
sorry to be so vague .. general question ..will look to see if theres an error some where ..
ps .. i need to look at memory ..in 32 bit i used a program [possibly by Japeth ??] called procwin which benefited from being very basic while giving easy access to everything required .. is there something similar for 64 bit assembler ???
thanks
mike b