Blender and 64-bit processors...

[meestaplu]

a good processor doesn't make a bad app run faster.

What is that supposed to mean?

Don't worry, this isn't some kind of subliminal Blender bashing! In all seriousness, though, this is well known in computer science. If you use a crappy algorithm to do something, and you upgrade to a processor that's twice as fast, your bad algorithm will run...twice as fast. However, if you use a better algorithm that's not only optimized but also scales better, your program will run perhaps TEN THOUSAND times faster.

Thus, a 64-bit processor might not do anything significant for the speed of Blender's code.

[slikdigit]

Antares:
linux, macOS and windows will/do all have 64 versions of their OSs. 64 bit will happen, not might, so in a way, its not a real 'choice' just a matter of when.
I've created scenes that paged on a machine with 1 Gig of RAM (I went a bit insane in this scene) I toned it down later on to fit it in under 1 Gig, but it made me see how you could go nuts with memory requirements- Think high res renders and texture maps, and lots of polys.This wasn't even "epic" so I could see wanting more in the not so distant future.
I agree, not a big deal for 90% of blender's users today. But eventualy, it will become reality.
I think blender has been ported to 64 bit architectures before? so it may not even be all that hard.

[Antares]

Antares:
linux, macOS and windows will/do all have 64 versions of their OSs. 64 bit will happen, not might, so in a way, its not a real 'choice' just a matter of when.

i have to admit that i am not against 64bit. i just wanted to point out that 64bit isnt really improving rendering times like many people think it should if they just look at numbers (32 <=> 64).

I've created scenes that paged on a machine with 1 Gig of RAM ...

1GB is possible. one of my own scenes nedded 700 MB too. but 4GB are barely possible for a meaningful scene. of course you can create a scene which needs that much memory on purpose.

[tbaldridge]

Now I'm not exactly a guru at programming, but I have been at it for about ten years, and have dove into the sources of blender afew times for modifying the particle system and the bump mapping. However, I do see a great use for AMD64 bit support.

Because of the following facts:

(1) 8 new GPR (General Perpose Registers) that will allow twice as many variables to be kept in the CPU registers instead of in the cache.
(2) 8 new XMM registers (for floating point SSE calculation)
(3) 128bit XMM registers. This is the big one. This basicly means that we could conceivably pack 4 32 bit floats into one register. Or 2 64 bit floats. And then multiply them all at once. Lowering the execution speed by an insane amount. This is why the intel compiler does so much better than gcc. Icc uses SSE and MMX to allow the same operation to be done on the same data at once. Basicly single instruction, multiple data.

All this is with very little or no modification to the existing code.


Alright guys, tear it apart now. I'm interested in your thoughts.

tbc++

[Antares]

i see no reason to tear it apart tbaldridge. the things you mentioned are facts and good arguments for the new athlon.

but most of the things you mentioned were already included in the northwood for a long time

the problem is still that somebody tells me where exactly a 64bit integers could speed up blender, if they arent used for parallel programming and stuff like addressing.

whats the benefit of a maximum value of 18446744073709551616 for control structures and counters?

perhaps bit masks may become more easy since you can store 64 of them in a single date.

[tbaldridge]

Right, but did the Northwood support as many GPR and XMM registers as the Athlon64? To my knowledge one of the big advantages of moving to Athlon64 is that there are more registers. Which could in some cases be a huge plus.

[Antares]

Right, but did the Northwood support as many GPR and XMM registers as the Athlon64? To my knowledge one of the big advantages of moving to Athlon64 is that there are more registers. Which could in some cases be a huge plus.

an intel CPU with SSE2 got the following registers:
8 32 bit general purpose registers:

EAX
EBX
ECX
EDX
EDI
ESI
EBP (stack base or frame pointer)
ESP (stack pointer)

2 32 bit registers system registers
EFL (flag register)
EIP (istruction pointer)

16 bit segment registers:

CS
DS
ES
FS
GS
SS

8 floating point registers of the FPU with 80bit internal and 64bit external size:

ST 0-7

8 MMX registers which are the same registers like for the FPU just with SIMD instructions defined on them. there are now special MMX registers the FPU registers just get a new name:

MM 0-7

8 128bit registers for SSE(2) SIMD instructions:

XMM 0-7

that's it

i doubt that the new AMD64 got 8 additional multi-purpose registers. they just call the extended basic registers (EAX, EBX, ...) "new" for marketing reasons.

for compatibility reasons new registers cannot be added, since the opcodes cannot address 8 new registers for which additional 4 bits would be needed (1 for selecting old/new general purpose registers and 3 for addresing the register itself).

in order to add new gen. purp. registers the hole opcode map would need redone.

AMD cannot create something that intel doesnt support. AMD is always one step behind in terms of improving the instruction set (they added SSE2 to their AMD64 while the new Prescott already got SSE3).

AMD MUST be compatible to the x86 architecture otherwise they would kick themselves out of the buisness.

the conclusion is, that an AMD64 doesnt have any additional registers.

[tbaldridge]

Let me preface my post here with the note that I am getting all my information from the AMD64 Arcitecture Programmer's Manual: Volume 1.

Section 1.1.1 shows a diagram of the registers that shows the old ia32 registers, and the new AMD64 registers. You will note, that the first 8 GPRs are labeled EAX, EBX, etc. Then AMD adds the R8-R16 Registers, and also extends the old registers (EAX, EBX, etc.) to 64 bit. The EIP register is expanded to the RIP register for 64 bit code, and the registers XMM8-XMM16 are added.

I must now correct two of your comments:

(1) That the opcodes cannot be changed. That is not true. I remember doing some reading many years back, about how to use debug (yes that terrible dos program) to generate code that would use the extended registers. I don't know exactly what the opcodes where, but there was an opcode prefix that would be used before the register to tell the processor that the next register refferenced would be an extended register.

So, if let's say the hex code for ADD AX, BX looked like this:

3F 5E 2C (Yes, I just randomly put out some numbers)

Then the ADD EAX, EBX would look like this:

3F FF 5E FF 2C (assuming that FF was the hex code for the EAX extention)

(2) The seccond point that I must correct, is that Intel makes the standards. This is not true. I guess you haven't heard of Intel's new ultra-highend P4 EM64T that uses the SAME AMD64 opcodes to do 64bit programming. (I bet Microsoft made them do it.) In this case, AMD had the standard first, and still has the standard, because the EM64T (or whatever Intel calls it), is slower, and more expensive then the AMD counterpart (http://www.anandtech.com/linux/showdoc.aspx?i=2158). Let me ammend that, the EM64T does almost as good as an Athlon64! If you wanted a real comparison an Opteron would be better.

Anyway, that's my issues with the last post

tbc++

[_styken]

I saw on AMDs dev pages that they claim that 64 bit integer math is more precise than floats since floats use 8bits for exponent and other things so only 56 bits is actual "information". They recommended to use 64bits integer before floats to boost accuracy in calculations. (and speed)


PS. Im no expert it was just a note I saw to which I have no link.

[tbaldridge]

Which brings up an interesting topic? What if in Blender 3 we used fixed point math instead of floating. In that way the speed would be much faster, without compromising accuacy. Of course floating would still have to be supported for the older procs.

[bobthevirus]

_styken - basically what that means is that in the old method, when you want ints greater than 2^32, you have to use floats, which are imprecise - basically the closest float to the int you are looking for. With the amd64 instuction set, you can get ints 2^32 (my maths skills are horrible this early in the morning - that might be off) times as big, before having to move to floats... Also, if you are using floats that need a smaller level of accuracy, you can just move the decimal point over - eg, for 5dp, you can have ints representing floats up to 184467440737095.51616 without losing anything - they are way more accurate, but of coarse not as versitile. This is the way $$ are stored in bank computers - they are actually stored as the number of cents - the int looks like 1000000, but is actually $10000.00 - which is only every used in the gui... (man I wish I had that much money (-;)

[Antares]

if it is like you say tbaldridge, it's really cool
i never thought they would add a new set of GPR to the x86 architecture.

and yes you are right, opcodes can be extended, by adding prefixes to the opcode. i just looked it up in the assembler programming manual.

[konrad_ha]

I saw on AMDs dev pages that they claim that 64 bit integer math is more precise than floats since floats use 8bits for exponent and other things so only 56 bits is actual "information". They recommended to use 64bits integer before floats to boost accuracy in calculations. (and speed)

Now that's along the lines I was thinking.

And for the record: I stopped programming about 3 years ago (after 2 years as developer of Java-based web-services [interesting stuff, J2EE and all]) and never actually studied it. Currently I'm downloading all necessary components to start building and understanding Blender, but it will take a while.

And tbaldridge, I am sure you're one of the best programmers around here, but you might want to work on your social skills. I've had friendlier discussions about more controversial topics then whether 64-bit could do a 3D-app some good. Simply stating "NO, end of discussion" just isn't good enough. If the quote above is applicable this might be very interesting indeed.

[bobthevirus]

Which brings up an interesting topic? What if in Blender 3 we used fixed point math instead of floating. In that way the speed would be much faster, without compromising accuacy. Of course floating would still have to be supported for the older procs.

and of course, he has to finish his post before mine, and use all the correct terminology as well (-: I'm glad that I'm thinking on the same kind of wavelength as somone as brainy as him though

[mpan3]

Win 64bit beta available @ MS website for free download.