Strom

1 day ago

I'm using Firefox 5.0, one of the most popular (and standard-adherent) browsers around.

Your precious FX5 does not adhere to the H.264 standard.

I use C++ when performance is very important and that usually means realtime, e.g. gaming related stuff. Whenever it is possible to wait for the results for a bit longer, C# is a much better choice due to .NET framework. Like others have said, having a light version of .NET Framework for C++ would be awesome. The higher level abstraction of common tasks makes quickly getting a prototype ready so much easier.

I also use C++ for debugging related tasks, because it's easy to communicate with the winapi.

Regarding the IDE performance degradation, it is definetly easily noticeable. In fact from 2003 to 2008 the performance got so bad that the IDE froze everytime I typed ".", i.e. intellisense stuff. When I bought a brand new computer with a SSD, these problems went away. For the record, eclipse is still abnormally slow with a top tier SSD & quadcore CPU.

Jul 06, 2011 at 8:36 PM,Charles wrote

In terms of the ctrl+f bug in VS2010, I've been informed that it has been fixed in SP1.

Nope, it's still there and it is easily the most annoying thing in VS.

Really liked this.

I can't decide if this is a joke or are you actually suggesting implementing something like this?

Thing is, this would not work well at all, in fact your 4 core example would work much slower, if at all, than just running all the code on 1 core.

The issue is concurrent memory access. By definition the 4 cores would run at the same time, and in your example it is an increment by one opcode. Well, all four cores would get the value of 01 and change it to 02. And in the next step all the cores would have 02 as the value and increment it to 03. Actually this is even an oversimplified situation, in reality core 2 for example might finish earlier than others because it runs at a higher clock rate and thus will get ahead of the other cores.

Now you might say that: "But there are atomic instructions available!". This is true for some instructions, but they are much slower. The CPU would be constantly hitting L3 cache, or even worse - RAM. The cores do not share the same low level cache, so if you modify some data, the change won't show up on other cores unless you push the change back into higher level memory, like L3 cache or RAM.