What's up with multicore CPUs, anyway?

[DaMan]

Note that RISC still haven't taken over.

The holy war continues though. Intel's failure on the mobile battlefield has given them false hope. Look at power wasted decoding x86 instructions they exclaim. The macolytes think Apple is going to give Intel the boot and switch MacOS to ARM any day now.

[Hellser]

MacOS to ARM any day now.

Good luck with that. I'd imagine like.. 99.99% of all programs / games not working. XD

[Blzut3]

Good luck with that. I'd imagine like.. 99.99% of all programs / games not working. XD

Apple changed architectures twice already. Not sure why this keeps being used as a reason they wouldn't switch again.

Edit: Plus lets not forget that even ignoring architecture changes Apple doesn't seem to put a lot of effort into backwards compatibility. When something is marked deprecated in their API you can be pretty certain it will be gone in a future release of OS X. An example of this is when they broke pretty much every application using SDL when Lion came out.

[printz]

I think Apple cares less about backward compatibility. Their Mac user base is not so big for Apple to be concerned about, and those users are generally more skilled with computers in order to adapt, considering they spent so much money and are still happy with their Macs. Apple is more concerned about pushing lighter and lighter computers into the market, and ARM paper-thin laptops that are just good enough to qualify as general-purpose personal computers (i.e. still better than tablets) fit perfectly with their possible agenda.

[ibm5155]

Go has a simple but nice multithread support, but, no one uses it .
I had some fun with threads, but I couldn't do much with that, I used alot of threads for processing some image data and then generate voxels for each pixel, the process for allocating was so heavy for my case (1GB image) that it was much better to coint how many pixels should I separate for each group of pixels and then alloc the precise size into The ram.
But still, it sucks, because I was stucked to a monothread rendering framework and for loading the 3D elements into the gpu or manipulating it, it took ages for loading ¬¬
hmm thinking about that Project now, wow, I was rendering 1,610,612,736 polygons O_O

EDIT:

Note that RISC still haven't taken over.

The holy war continues though. Intel's failure on the mobile battlefield has given them false hope. Look at power wasted decoding x86 instructions they exclaim. The macolytes think Apple is going to give Intel the boot and switch MacOS to ARM any day now.

And also, now we have arm processors with 10Watts TDP into an smartphone, more like an core i processor on ultrabooks (soon, we'll have smartphones with coolers)

EDIT: Now look how much power wasted is being done by java, c#,...
They waste too much cpu cycles compared to assembly language, but who cares, people just get an easy language, do some ctrl-c ctrl-v from stackoverflow and if it doesn't break, it's good to go.

[Graf Zahl]

Their Mac user base is not so big for Apple to be concerned about, and those users are generally more skilled with computers in order to adapt, considering they spent so much money and are still happy with their Macs.

... and that's the eternal conundrum with Apple. No matter how shitty Apple treats their users, they stick with them. Microsoft gets beaten down for much minor transgressions.

[Hellser]

They waste too much cpu cycles compared to assembly language, but who cares, people just get an easy language, do some ctrl-c ctrl-v from stackoverflow and if it doesn't break, it's good to go.

Correct me if I am wrong, but is it the job of compilers to take the human readable language and compile it into assembly for the CPU? Or did that one video I watched lied to me?

[Dancso]

It is totally correct, but there are tiny dribs and drabs here and there that may not be necessary to do for all the commands you're calling. (heck if you're skilled, automated array boundary checking can be a waste) It's really not all that much, the main reason why java and c# are slower (not as much as some people would have you believe, but it's definitely not >optimal< for games for instance) is because they compile their code on the run.. which might actually be more beneficial after the initialization because the JIT (Just In Time Compiler) can take advantage of hardware technologies you have not explicitly specified to support/take advantage of. Of course if you code them in to your C++ app for instance it will come out ahead, but theoretically you will be open for future optimization outside of your hands through java updates for instance.

There's another argument to be made for object oriented languages being less efficient in general because of all the management that goes on behind the scenes.. though whether it is really a big loss remains to be determined whether you're creating the next unreal engine and want to crank out as much as possible, or if you're the average joe who just wants to develop in the language you find most comfortable to use.

[GooberMan]

the main reason why java and c# are slower (not as much as some people would have you believe, but it's definitely not >optimal< for games for instance) is because they compile their code on the run.. which might actually be more beneficial after the initialization because the JIT (Just In Time Compiler) can take advantage of hardware technologies you have not explicitly specified to support/take advantage of.

That is so close to being right, yet so far.

.NET programs compile to MSIL, which is then compiled to optimal machine language on first run of the program and stored in a cache. That cached version is what actually executes on your machine.

Java also compiles to an intermediary language and traditionally runs it in a VM. While I don't know the internals these days I'd be surprised if it doesn't also compile to machine language on Windows. Dalvik on Android, at the very least, compiled to ARM code on every single program start; ART does it on program download/install.

.NET's slowness tends to come from its memory model - specifically, the boxing/unboxing nature of many standard operations. Java's slowness, in my experience, tends to be by API design. I've worked with a codebase previously that cross-compiles between C++ and Java, and I couldn't even begin to tell you how inefficient that code is in C++. Look in to Java Arrays, and the hacks the language has included to get around its slowness.

Emerging languages like Swift, Go, Rust, and D (my pick of the bunch) keep many of the nice .NET/Java features but still aim to be fast languages. My preference for D is down to its compile time features, the other languages mentioned are downright primitive compared to D.

[Graf Zahl]

.NET's slowness tends to come from its memory model - specifically, the boxing/unboxing nature of many standard operations.

A lot of C++ code in the wild does similar shit and becomes slow, too. A good programmer can easily work around these issues. The real problem here is that 'modern' programmers never realize how inefficient their code is. They just use these features extensively where another approach can be more beneficial.


Java, on the other hand, that looks like a lost cause to me. Whoever decided that that language is good for real life programming should rot in hell forever.
Every time I had to write performant code in Java I had to do my best to work around the language's features, the worst often being replacing use of structs/classes with arrays so that it isn't necessary to allocate hundreds of small memory blocks when one large one would suffice.

[Naniyue]

So, VR is (finally) slowly getting better and better, eh? It would be nice to play DooM like this, as I could get exercise at the same time.