Humus - Comments

More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 129 130 131 132 133 134 135 136 137 138 139 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438

Query Failedkyle
Wednesday, June 30, 2010

re Overlord:
Something like Itanium?

Imo, we are stuck with x86 forever ...

sqrt[-1]
Wednesday, June 30, 2010

Just bring on a huge grid of memristors and each application can configure the chip hardware how it wants!

(I actually have no idea - just was amazed at some of the predictions in http://www.youtube.com/watch?v=bKGhvKyjgLY "Finding the Missing Memristor"

Humus
Sunday, June 27, 2010

The obvious downside of that is that it comes with some overhead because in a well written class that initializes everything itself the memory will be written twice at every creation. Also, as you mentioned, it doesn't cover the stack-allocated case, although this problem is more common on big classes who normally are not allocated on the stack. However, the very weak spot of this is reuse of already allocated memory from pool, and in-place creation, which are common things in games for performance reasons.

idinev
Sunday, June 27, 2010

Override new/delete

extern void * _cdecl operator new (size_t size);
extern void * operator new[] (size_t size);
extern void _cdecl operator delete (void * ptr);
extern void operator delete[] (void * ptr);

Zero-initialize in 'new', with a fast memfill func ("rep stosd" may suffice), that's before setting-up the vTable ptr.

Only problematic area will remain the stack-allocated classes.

Overlord
Friday, June 25, 2010

Personally i think the faster x86 CPUs get a few vector processors for each core the better, but then again the reason we still don't have that setup is because of x86.
I would much rather see them invent a new type of processor, one with multiple types of processor cores, like a few general purpose cores, a bunch of vector cores and a lot of SPPUs(Single purpose processing units, really tiny cores that can only do a few things).

And when it comes to flops/watt, if done right such a processor if you only used whats needed would fit the mobile market pretty good as you could often just use a smaller core for the same job

Kayru
Thursday, June 24, 2010

The console way definitely seems like the way forward. GPU is just another processor in the system. Ideally, with shared memory and very low level API, like libgcm. But thats probably too much to ask...

Bryan McNett
Wednesday, June 23, 2010

My suspicion is that, as flops/watt continues to improve for many tiny slow cores, there will eventually come a mobile computer generation in which the sequential CPU no longer earns its keep and is left out. Amdahl's law always applies, but the common belief that popular apps require serialism is a myth, IMO.

The driving force behind this is flops/watt. So it should happen to mobile computers first, then videogame consoles or servers, and finally to desktops. But the process may take decades, and a majority of developers will resist it.

diegopark
Sunday, June 20, 2010

Although a paid application, I suggest Visual Lint / PC-Lint


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