Humus - Comments

More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 77 78 79 80 81 82 83 84 85 86 87 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 365

Query FailedMagnus F.
Saturday, February 20, 2010

Hi,
will the new framework4 abstract OpenGL 3.x(2) and D3D11? If so, i would really like a look at your abstraction, because i am working on a similar project right now and i always get the "if i want to have this (very rare) feature, how can i abstract it for both" illness

.

keep up the excellent work!
M.

Humus
Friday, February 19, 2010

FMoreira: Yes, that's a Release build. Debug builds generate function calls building the StringHash class and everything. That 64bit is faster could very well be due to double the amount of registers available, so far fewer reads/writes to the stack. I did some SIMD optimizations at work which dramatically improved our performance, which mostly was about keeping things in registers and avoid the stack.

Arseny Kapoulkine: Yes, that's true. Although I would have expected that the compiler would do a final pass over the generated code and eliminate sequential writes to the same address.
Using a single local variable worked too, so I'll use that instead since it looks better (and is less prone to copy-paste errors).

Martin Vilcans: Yeah. It was just a coincidence that I noticed this, because the code was working. I was looking at other stuff when I suddenly saw that chunk of code above the code I was really looking at.

Martin Vilcans
Friday, February 19, 2010

At least it doesn't generate invalid code, which has happened to me at least once in Visual C++ 2.0. (Way back.)

Arseny Kapoulkine
Friday, February 19, 2010

First rule of member function optimization: never access (r/w) your class members in an inner loop unless you must. This is a hidden indirection, therefore it contains implicit aliasing and god knows what else. In some situations like this, compiler can produce good code, but the probability of failure is higher.

You can change your ctor to operate as before, but store all results in a local, i.e.

uint32 hash = 0;
hash = hash * 65599 + str[0];
... etc
m_Hash = hash;

It will likely solve the problem.

FMoreira
Thursday, February 18, 2010

"I also noticed that 64bits that the code that VS2010 RC generates is much more faster than the 32bits code."

should be read: I also noticed that the 64bits code that VS2010 RC generates is much more faster than the 32bits code.

FMoreira
Thursday, February 18, 2010

that assembly code results from a release build?

I've been doing some performances tests using both C++ and Assembly (SIMD) and some times the compiler ends up doing something closer to what you've just described. when I compile in release mode it generates correct code!
I also noticed that 64bits that the code that VS2010 RC generates is much more faster than the 32bits code. Even more faster than hand-tuned assembly...

these conclusions were all taken from some performances tests that I did with 4x4 matrices operations.

Seth
Monday, February 8, 2010

Good to hear. I'm glad PIX has improved support for DX11.

Microsoft has really done a great job evolving Direct3D into a beautiful API. The generality of the new tessellation functionality is something to be admired.

macnihilist
Saturday, February 6, 2010

WOOT!
I just resurrected my 8800GTX in the oven.
GPU-Z readings look ok and I played Dragon Age and Cod4 for about an hour now.
Thank for the hint, I never would have thought about that.


General
	News 3D Pictures Textures Articles Cool stuff
Other
	FAQ About Humus
Other 3D sites
	OpenGL.org GameDev.net Beyond3D Rage3D
Programming info
	OpenGL extension registry NeHe