I used to be a huge proponent of threading applications, but now, whenever possible, I choose multiprocess models instead. The extra protection from separate address spaces is very often worth it from a debugging perspective. And if you're serious about multiprocessing - you're likely gonna spend more time in the debugger than coding.
Of course, threads have legitimate uses too - but always try to see if you can design for separate processes instead, before commiting to a threaded single process model. Google Chrome shows the way.
PLEASE KEEP IN MIND THAT SOME OF US ARE STILL ON TLGRPH STOP YOU INSENSITIVE CLODS STOP
(yeah yeah. lameness filter. yeah yeah.)
Some more antilameness filter. And some more.
There is also the issue of the antilameness filter. It really sucks.
It's true that MMGR is single thread only, and if your program allocates and frees memory on multiple threads you should choose another alternative.
However, many many programs only allocate and free memory on one thread, and for those MMGR is simple to use and is pretty damn good at finding leaks, overruns and similar problems.
Yep, Paul Nettle's little memory manager rocks. It WILL find leaks in your program.
http://www.paulnettle.com/
(Yes, you have to navigate through a horrible flash site to get it, but it's worth it).
The simple answer is that the base windowing system of Win32 was designed in the 80's for very weak computers, and it simply can't be changed. They HAD to keep it lean and mean. Of course, there was obviously some lack of forethought involved, but hindsight is 20/20...
Instead, they've now developed Avalon / WPF, which contains most of the missing features you are listing there, and a lot more than that. Yeah they should have done this sooner, but hey, it's Microsoft...
Because the ugly x86 instruction set acts as a form of compression, x86 code is more dense and fits more easily into the instruction cache than RISC code. The overhead of translating x86 to internal RISC is basically fixed and is therefore getting smaller each process shrink. It's already negligble.
For this reason, the ugly x86 instruction encodings are now an advantage!
x86 also gained an additional 8 registers and a cleanup with AMD64.
No way Jose, SIMD isn't going out of style at all.
What do you think the SPE:s of the Cell processor do best? SIMD.
What did Intel put a LOT of resources into in its new Core architecture, theoretically doubling the speed of this part? SIMD.
What is it that makes it possible for a PII300 to decode DivX, or a P4 3GHz/Athlon64 2GHz able to decode video in HDTV resolutions? SIMD. It wouldn't stand a chance with just regular scalar instructions. MMX/SSE2 are essential.
Sorry, you're wrong.
Windows NT has done this (mapped executables into memory instead of loading them) since 1992 or so. It's nothing specific to linux.
Well, the IE engine is just that: an OCX control. Internet Explorer is just a little window that contains an address bar, some buttons, and this OCX control.
It's not in the kernel. It's not really part of the OS other than that the shell (which is a user mode app) uses it for some things, and that it's included in the installation.
You already got what you asked for. The reason IE has so many exploits is simply bad design and crappy code, not that it's somehow "part of the OS". Unfortunately the MS guy didn't clarify this enough for obvious reasons.
I would love to switch from 3DSMax to Blender for my little hobby game, but the lack of smoothing groups in Blender makes this absolutely impossible. Googling for "Blender smoothing groups" didn't give me much hope. Are they even planned for inclusion?
Have you ever looked at an MPEG file or a DivX file on a CPU without SSE2 (which basically contains an extended MMX)?
HEAVY MMX usage there.
MMX was never used very much for 3D and such but it found its niche in video codecs and image processing.
Sure, but that's not traditional UNIX and is not guaranteed to exist under all unix systems. On Windows you can count on a reasonably decent threading model being there. Although it may be argued that limiting yourself to Windows is just as limiting as limiting oneself to a few particular unixes.
I'm studying for a CS masters and a UNIX-based web server is the final project of our "Systems programming in C" course. It's an optional course though.
Oh and BTW, fork() and the unix process model sucks as a parallellism primitive. I love Win32 threads and io completion ports:/
(assuming we're talking x86)
16-bit code is invariably slower than 32-bit code on modern processors. 32-bit code can deal with 16-bit values just fine and has a much simpler and more efficient memory model.
Why would anyone want to run 16-bit code except when running old DOS programs?
Actually, the same can since some time be said for MS code since they simply deprecated every string handling function of the CRT and introduced the new and improved "Secure CRT" which includes a length parameter on every function, and with more predictable behaviour than the old CRT. Since this is in the latest compiler I assume that any software from MS from now on should be sanitized this way. Of course there are other exploits like integer overflows but they are considerably harder to find and exploit.
Interesting how a slashdotter with such a low user ID has such a weak grasp on how GPU:s work.
They are VERY different from CPU:s and the interface to access them from software is incredibly complicated because of all their specialized features. They can not run generic code, only short snippets called shaders.
Slashdot Mirror
Of course, threads have legitimate uses too - but always try to see if you can design for separate processes instead, before commiting to a threaded single process model. Google Chrome shows the way.
Here in Switzerland, you can choose from 4-6 digits, and all ATMs I've seen here have no problem with six digits.
(yeah yeah. lameness filter. yeah yeah.) Some more antilameness filter. And some more. There is also the issue of the antilameness filter. It really sucks.
It's true that MMGR is single thread only, and if your program allocates and frees memory on multiple threads you should choose another alternative. However, many many programs only allocate and free memory on one thread, and for those MMGR is simple to use and is pretty damn good at finding leaks, overruns and similar problems.
Yep, Paul Nettle's little memory manager rocks. It WILL find leaks in your program. http://www.paulnettle.com/ (Yes, you have to navigate through a horrible flash site to get it, but it's worth it).
What kind of useless speculation is that?
It does JIT (or BT as you call it). Otherwise it would be unbearably slow. It might not do it as efficiently as VMware though.
The simple answer is that the base windowing system of Win32 was designed in the 80's for very weak computers, and it simply can't be changed. They HAD to keep it lean and mean. Of course, there was obviously some lack of forethought involved, but hindsight is 20/20...
Instead, they've now developed Avalon / WPF, which contains most of the missing features you are listing there, and a lot more than that. Yeah they should have done this sooner, but hey, it's Microsoft...
Simple: Time is money, and the DX9 SDK is free to download and use for everyone.
Okay, this complaining about IE being in the KERNEL needs to stop. It's not, and it never has been.
It is a little too integrated in the shell at the moment though, but they're mostly pulling that out in Vista.
Because the ugly x86 instruction set acts as a form of compression, x86 code is more dense and fits more easily into the instruction cache than RISC code. The overhead of translating x86 to internal RISC is basically fixed and is therefore getting smaller each process shrink. It's already negligble. For this reason, the ugly x86 instruction encodings are now an advantage! x86 also gained an additional 8 registers and a cleanup with AMD64.
No way Jose, SIMD isn't going out of style at all. What do you think the SPE:s of the Cell processor do best? SIMD. What did Intel put a LOT of resources into in its new Core architecture, theoretically doubling the speed of this part? SIMD. What is it that makes it possible for a PII300 to decode DivX, or a P4 3GHz/Athlon64 2GHz able to decode video in HDTV resolutions? SIMD. It wouldn't stand a chance with just regular scalar instructions. MMX/SSE2 are essential.
Huh? XP installs just fine on a PII 400 and I've even seen it run decently on a 233MHz machine (with 256MB RAM)...
Sorry, you're wrong. Windows NT has done this (mapped executables into memory instead of loading them) since 1992 or so. It's nothing specific to linux.
Well, the IE engine is just that: an OCX control. Internet Explorer is just a little window that contains an address bar, some buttons, and this OCX control. It's not in the kernel. It's not really part of the OS other than that the shell (which is a user mode app) uses it for some things, and that it's included in the installation. You already got what you asked for. The reason IE has so many exploits is simply bad design and crappy code, not that it's somehow "part of the OS". Unfortunately the MS guy didn't clarify this enough for obvious reasons.
I'm pretty sure that the "last-known-good" is from the last successful shutdown.
I would love to switch from 3DSMax to Blender for my little hobby game, but the lack of smoothing groups in Blender makes this absolutely impossible. Googling for "Blender smoothing groups" didn't give me much hope. Are they even planned for inclusion?
It should, if you have anywhere to store the games.
Have you ever looked at an MPEG file or a DivX file on a CPU without SSE2 (which basically contains an extended MMX)? HEAVY MMX usage there. MMX was never used very much for 3D and such but it found its niche in video codecs and image processing.
Sure, but that's not traditional UNIX and is not guaranteed to exist under all unix systems. On Windows you can count on a reasonably decent threading model being there. Although it may be argued that limiting yourself to Windows is just as limiting as limiting oneself to a few particular unixes.
I'm studying for a CS masters and a UNIX-based web server is the final project of our "Systems programming in C" course. It's an optional course though. Oh and BTW, fork() and the unix process model sucks as a parallellism primitive. I love Win32 threads and io completion ports :/
(assuming we're talking x86) 16-bit code is invariably slower than 32-bit code on modern processors. 32-bit code can deal with 16-bit values just fine and has a much simpler and more efficient memory model. Why would anyone want to run 16-bit code except when running old DOS programs?
Actually, the same can since some time be said for MS code since they simply deprecated every string handling function of the CRT and introduced the new and improved "Secure CRT" which includes a length parameter on every function, and with more predictable behaviour than the old CRT. Since this is in the latest compiler I assume that any software from MS from now on should be sanitized this way. Of course there are other exploits like integer overflows but they are considerably harder to find and exploit.
Interesting how a slashdotter with such a low user ID has such a weak grasp on how GPU:s work. They are VERY different from CPU:s and the interface to access them from software is incredibly complicated because of all their specialized features. They can not run generic code, only short snippets called shaders.
It's "Hear hear". Courtesy of the SGPD, Slashdot Grammar Police Dept.
What are you talking about? You are still able to do that, and the native C++ compiler is better than ever.