So forget the content distributors, they aren't even relevant, you need to get the content producers to create and distribute free (open/freedom) works.
Only we seem to be voluntarily providing the companies with this stuff in return for shiny baubles.
It's not that you seem to be doing that, it's that you are doing that, so the simple solution is to stop doing that. Sure it is less convenient but that's the tradeoff.
My point is that there's more platforms to develop games today than a decade ago.
But they are different platforms, for different types of games. iOS and Android certainly don't seem to be cannibalizing the console market and the obvious explanation for it is that games like Candy Crush and Doodle Jump are suitable for smartphones while others like Alan Wake or Metal Gear Solid are suitable for consoles and people simply are not playing one type in exclusion of the other.
Do you have a suggestion for finding the size of a class layout without knowing all the members?
Use pointers for object members, just like Java does. Ultimately you still can't use those private members and you don't get any private implementation details from just the header anyway so the programmer isn't going to be relying on them at all.
So what's your point? That the console market is dying because more people buy general purpose smartphones than buy game-focused consoles? How many people actually game on their smartphones? And how many of those people play the games on their smartphone instead of on a console?
A hell of a lot more people bought PCs than they did consoles for decades and contrary to the experience on iOS and Android you actually can get a comparable (almost identical) gaming experience on a PC and that still didn't kill consoles.
Well maybe, but also there is the trend that most people are playing games on smart phones and not consoles. For everyone that bought a new game for PS4 or Xbox One, there are probably 10x as many consumers who bought Candy Crush Saga.
It really is a completely different type of game, smartphone games are more time wasters than immersive experiences and they typically don't need much in the way of computing power. People aren't going to play Candy Crush or Doodle Jump on their XBox just as they aren't going to play Skyrim or Metal Gear Solid or Diablo on their smartphone. There are a myriad of Android consoles that you could use to play all those Android games on your TV but who wants to do that?
Which is why as far as FOSS is concerned the community needs to focus on actually finishing the Hurd. Linux is free software but by convenience rather than ideology, it's about collaborative development and "tit for tat" rather than software freedom. You can support products that have open bootloaders and such but you can never guarantee that and Linux will never enforce it which is why the FOSS community needs to focus less on proliferation of Linux and complaining about closed bootloaders and more on actually developing a proper FOSS kernel, a GPLv3 kernel that is even better than Linux.
That is interesting, because I thought a bunch of handset makers are using Android while giving nothing at all back to google.
They are, but they are restricted. They can't create any incompatibilities and the key element to being part of the Android ecosystem is the proprietary Google Play Services and all the proprietary Google apps. Sure they could take the stock AOSP project and maintain, upgrade and develop it themselves but they aren't really in the business of doing that.
The current generation of "smart" TV's with every brand having their own interface is getting a bit tedious. Give me Android, give me Firefox OS, even give me iOS if you have to.
I prefer it to be just a display, I can plug a cable box or a PC or a gaming console or a Chromecast or an AppleTV into it or whatever, I can choose what device, capabilities and interface I prefer and change it whenever I like. A TV just has to support as many connection options as possible.
Huh? The point of difference is that variable-length objects are represented by their pointers in Java, and not necessarily in C++. In specific, if class A has class B as a member, the size of class A doesn't depend on the size of class B in Java (since it's a pointer anyway), but it does in C++.
Only if it isn't a pointer, so if you care about that then just use pointers, simple, though if you aren't doing things "specifically related to that class" then I'd question why you have it there as a member at all. But regardless, that's beside the point, how does the compiler needing to know the size of a class lead to showing that class's private members & functions to programmers and them subsequently relying on them?
Most PCs have only one sound card, and most people listen to one musical recording at once. More cores do make sense for people producing music, which might involve dozens of tracks feeding into a tree of DSP effects and mixers.
Obviously, and playing music is only one of virtually infinite possibilities for a multitude of background tasks.
Encoding an entire album's worth of music is embarrassingly parallel: one core for each track. Video is a bit harder. First, what kind of video does a home user have the legal right to transcode "from other formats or from physical media" without unlawfully circumventing a technical measure?
I don't know, frankly I don't really care. If you don't use all the cores of your CPU I also don't care.
Second, video typically isn't stored with each chapter as a separate file; instead, chapter stops tend to be treated as cue points. So how is video encoding typically split up across threads?
Encoding video is a very parallel process and extensively documented and certainly beyond the scope of a reply here. Google is really easy to use so I suggest you educate yourself on this. But you appear to be looking at it without any knowledge of the actual process of encoding or the concept that data can be split up or combined and just because it is presented to you in terms of "tracks" or "chapters" or "files" doesn't mean you have to process it that way.
I'd like to see statistics on "plenty"
Then perhaps you should study it before dismissing CPUs with more than 2 cores.
Sure, the processor of the featured article is massively multicore because it fits the nature of "the problems to be solved" in supercomputing. But to what extent do "the problems to be solved" on most home computers admit a likewise massively multicore design?
Most problems are able to exploit massively parallel processors it's just that typically it has been unnecessary to leverage such processors. If you don't need it then don't buy it, if it becomes cheaper than dual core someday then buy it because it's cheaper and pretend the redundant cores aren't there if you really have to.
Perhaps you should research and provide a well-reasoned basis for your recommendations in future.
I guess I'm so clueless that I don't know how much overhead there is in A. adding a single item to a worker queue and then B. waiting for a worker queue to have an item and retrieving that item.
Very little, it's just a threadsafe queue and a barrier for workers.
But my intuition is that if one stage of processing spends all its time waiting to acquire the locks needed to add an item to the next stage's worker queue, that could negate the gains of fine-grained parallelism.
Of course, but the idea that one stage would be spending "all its time waiting to acquire the locks needed to add an item to the next stage's worker queue" makes little sense in practice. It seems you're working more on theoretical situations that could arise from poor design, poor threading constructs and poor schedulers rather than actual issues or experience.
Almost all ads are malicious in one way or another. If they don't carry bad stuff to your computer you can be misled to click on them and $DIETY knows where you end up sometimes. If nothing else they burn a lot of CPU ticks and makes your computer consume more power.
Yeah displaying a link and a one-sentence blurb is really burning a lot of CPU clocks and making my computer consume more power.
Web browsers should ship with support for the web (that means HTML, semantic markup, period) and extensions should be used to add to that, rather than by default supporting every piece of nonsense any adware/spyware/malware pusher might ever want to use, and then having extensions to try and turn that off after the fact.
So fork Firefox or Chromium or build a browser atop webkit and offer such a thing. Nothing stopping you from doing it if you really think that's the way it should be.
It doesn't matter that it's a background application, you can't have infinite background applications running on just one core. When I'm rendering a 3D scene it is the background application too. Encoding music and video for your portable devices from other formats or from physical media is also a background task, but one that is probably more intensive than a foreground web browsing task.
You said the S word. When a "server" enters the picture, I agree that larger core counts become easier to justify, as background processing begins to dominate. But I'd like to see statistics on how popular PC-based home media servers are in the first place.
Plenty of people use XBMC, iTunes, PS3 Media Server, Twonky, Windows Media Server, VideoLAN, Firefly, Quicktime, TVersity, etc... it isn't a niche market and such people wouldn't consider running these applications on their system to mean it's suddenly a "server".
I'm trying to find what use cases are most common because economies of scale benefit the most common use cases.
No you said 1 core for foreground and 1 core for background, but that is completely unjustified. Look at what you replied to: Even if you are using a single process program, it can benefit from not having to share it's core with the various system processes.
So your use case is if the foreground process is single-threaded and all your background processing is single-threaded and non-instensive and the combination of it adds up to less than the processing power of one core - which itself is not a unit of measure. Speaking in terms of number of cores makes no sense anyway. It depends not only on the use cases but also the problems to be solved and the implementation of the applications to solve those problems.
So how would parallel speedup help with a linked list, a tree, or a hash table? Perhaps rotations of a balanced search tree could run in a separate thread, but that's about all I can think of. I admit to having fallen victim to the fallacy of lack of imagination.
Because - and perhaps I misspoke when I repeated the term 'traverse' - you are never just traversing a tree, you are always doing some sort of processing on the nodes (which can be passed to worker threads) and every branch in a tree is an opportunity to have other threads take up the traversal task.
What I meant was that the serial part dominates long before 72 cores are used.
In theory you could have a problem that is 99.99999% percent serial, but in practice you probably don't.
Which brings in synchronization delays when your parser thread has to pass such "enough information" about each element to another thread.
Of course you will have synchronization delays at some point but if that is the case then another possible way is that the parser thread goes through processing each element and when it has enough information to process the next element it pops the current one onto a worker queue for completion by another thread. There are many ways to go about this if you have a bit of imagination but it depends on your target hardware, your specific problem and the context of the problem (you may not want to thrash all your available resources on this one problem leaving nothing for other concurrent tasks).
It is never necessary for the compiler to know the size of a given class when not doing things specifically related to that class. In C++, objects can be existing in memory (like Java's basic types) or separately on the heap (like Java's classes). This means it's often necessary to know how large an instantiation of a class will be, which leads to the private members being viewable.
It's necessary in both C++ and Java, the point of difference is if you were to create a stack allocated instance of a class in C++ but not use it, why would you be doing that?
and traversing an index was an inherently serial process.
Traversing an index? What do you mean by "index"? Traversing data structures is certainly not inherently serial at all.
I don't see how rendering a web page can be fully parallelized.
Probably because he didn't say "fully parallelized", in fact "fully parallelized" would be that every element of something is parallel, which isn't ever the case, you are always going to have a serial element somewhere.
Parsing and reflow, no.
Why not? Just because there is a serial part to the problem doesn't mean you can't leverage parallel processing. If I have a set of elements that need to be processed serially that doesn't mean the task of processing of each element couldn't utilize multiple cores. Or even that I couldn't process each element to a degree that it provides enough information for another thread/process to start processing the next element.
Slashdot Mirror
So forget the content distributors, they aren't even relevant, you need to get the content producers to create and distribute free (open/freedom) works.
Obviously this closed source software wasn't, in fact, the best tool for the job. If it were it wouldn't have been hacked.
So what bulletin board software is unhackable then?
That doesn't mean you have to do it too, be your own person and don't just follow the crowd.
The sad truth is not enough people care.
Enough for what?
Time for a boycott?
Why do you want to boycott it?
Only we seem to be voluntarily providing the companies with this stuff in return for shiny baubles.
It's not that you seem to be doing that, it's that you are doing that, so the simple solution is to stop doing that. Sure it is less convenient but that's the tradeoff.
My point is that there's more platforms to develop games today than a decade ago.
But they are different platforms, for different types of games. iOS and Android certainly don't seem to be cannibalizing the console market and the obvious explanation for it is that games like Candy Crush and Doodle Jump are suitable for smartphones while others like Alan Wake or Metal Gear Solid are suitable for consoles and people simply are not playing one type in exclusion of the other.
Do you have a suggestion for finding the size of a class layout without knowing all the members?
Use pointers for object members, just like Java does. Ultimately you still can't use those private members and you don't get any private implementation details from just the header anyway so the programmer isn't going to be relying on them at all.
Yeah you're probably right, the Hurd has failed for long enough that it's probably time to just give up on a GPLv3 kernel.
So what's your point? That the console market is dying because more people buy general purpose smartphones than buy game-focused consoles? How many people actually game on their smartphones? And how many of those people play the games on their smartphone instead of on a console?
A hell of a lot more people bought PCs than they did consoles for decades and contrary to the experience on iOS and Android you actually can get a comparable (almost identical) gaming experience on a PC and that still didn't kill consoles.
Well maybe, but also there is the trend that most people are playing games on smart phones and not consoles. For everyone that bought a new game for PS4 or Xbox One, there are probably 10x as many consumers who bought Candy Crush Saga.
It really is a completely different type of game, smartphone games are more time wasters than immersive experiences and they typically don't need much in the way of computing power. People aren't going to play Candy Crush or Doodle Jump on their XBox just as they aren't going to play Skyrim or Metal Gear Solid or Diablo on their smartphone. There are a myriad of Android consoles that you could use to play all those Android games on your TV but who wants to do that?
> whose founders hail from the NSA
> CEO Raj Shahsays he worked in the Air Force Reserve supporting the NSA
They aren't really the same thing now are they?
Which is why as far as FOSS is concerned the community needs to focus on actually finishing the Hurd. Linux is free software but by convenience rather than ideology, it's about collaborative development and "tit for tat" rather than software freedom. You can support products that have open bootloaders and such but you can never guarantee that and Linux will never enforce it which is why the FOSS community needs to focus less on proliferation of Linux and complaining about closed bootloaders and more on actually developing a proper FOSS kernel, a GPLv3 kernel that is even better than Linux.
That is interesting, because I thought a bunch of handset makers are using Android while giving nothing at all back to google.
They are, but they are restricted. They can't create any incompatibilities and the key element to being part of the Android ecosystem is the proprietary Google Play Services and all the proprietary Google apps. Sure they could take the stock AOSP project and maintain, upgrade and develop it themselves but they aren't really in the business of doing that.
The current generation of "smart" TV's with every brand having their own interface is getting a bit tedious. Give me Android, give me Firefox OS, even give me iOS if you have to.
I prefer it to be just a display, I can plug a cable box or a PC or a gaming console or a Chromecast or an AppleTV into it or whatever, I can choose what device, capabilities and interface I prefer and change it whenever I like. A TV just has to support as many connection options as possible.
What does the "Open" in the Open Automotive Alliance actually mean?
Huh? The point of difference is that variable-length objects are represented by their pointers in Java, and not necessarily in C++. In specific, if class A has class B as a member, the size of class A doesn't depend on the size of class B in Java (since it's a pointer anyway), but it does in C++.
Only if it isn't a pointer, so if you care about that then just use pointers, simple, though if you aren't doing things "specifically related to that class" then I'd question why you have it there as a member at all. But regardless, that's beside the point, how does the compiler needing to know the size of a class lead to showing that class's private members & functions to programmers and them subsequently relying on them?
Most PCs have only one sound card, and most people listen to one musical recording at once. More cores do make sense for people producing music, which might involve dozens of tracks feeding into a tree of DSP effects and mixers.
Obviously, and playing music is only one of virtually infinite possibilities for a multitude of background tasks.
Encoding an entire album's worth of music is embarrassingly parallel: one core for each track. Video is a bit harder. First, what kind of video does a home user have the legal right to transcode "from other formats or from physical media" without unlawfully circumventing a technical measure?
I don't know, frankly I don't really care. If you don't use all the cores of your CPU I also don't care.
Second, video typically isn't stored with each chapter as a separate file; instead, chapter stops tend to be treated as cue points. So how is video encoding typically split up across threads?
Encoding video is a very parallel process and extensively documented and certainly beyond the scope of a reply here. Google is really easy to use so I suggest you educate yourself on this. But you appear to be looking at it without any knowledge of the actual process of encoding or the concept that data can be split up or combined and just because it is presented to you in terms of "tracks" or "chapters" or "files" doesn't mean you have to process it that way.
I'd like to see statistics on "plenty"
Then perhaps you should study it before dismissing CPUs with more than 2 cores.
Sure, the processor of the featured article is massively multicore because it fits the nature of "the problems to be solved" in supercomputing. But to what extent do "the problems to be solved" on most home computers admit a likewise massively multicore design?
Most problems are able to exploit massively parallel processors it's just that typically it has been unnecessary to leverage such processors. If you don't need it then don't buy it, if it becomes cheaper than dual core someday then buy it because it's cheaper and pretend the redundant cores aren't there if you really have to.
Perhaps you should research and provide a well-reasoned basis for your recommendations in future.
I guess I'm so clueless that I don't know how much overhead there is in A. adding a single item to a worker queue and then B. waiting for a worker queue to have an item and retrieving that item.
Very little, it's just a threadsafe queue and a barrier for workers.
But my intuition is that if one stage of processing spends all its time waiting to acquire the locks needed to add an item to the next stage's worker queue, that could negate the gains of fine-grained parallelism.
Of course, but the idea that one stage would be spending "all its time waiting to acquire the locks needed to add an item to the next stage's worker queue" makes little sense in practice. It seems you're working more on theoretical situations that could arise from poor design, poor threading constructs and poor schedulers rather than actual issues or experience.
Almost all ads are malicious in one way or another. If they don't carry bad stuff to your computer you can be misled to click on them and $DIETY knows where you end up sometimes. If nothing else they burn a lot of CPU ticks and makes your computer consume more power.
Yeah displaying a link and a one-sentence blurb is really burning a lot of CPU clocks and making my computer consume more power.
Web browsers should ship with support for the web (that means HTML, semantic markup, period) and extensions should be used to add to that, rather than by default supporting every piece of nonsense any adware/spyware/malware pusher might ever want to use, and then having extensions to try and turn that off after the fact.
So fork Firefox or Chromium or build a browser atop webkit and offer such a thing. Nothing stopping you from doing it if you really think that's the way it should be.
Foreground application.
Nope, not necessarily.
Background application.
It doesn't matter that it's a background application, you can't have infinite background applications running on just one core. When I'm rendering a 3D scene it is the background application too. Encoding music and video for your portable devices from other formats or from physical media is also a background task, but one that is probably more intensive than a foreground web browsing task.
You said the S word. When a "server" enters the picture, I agree that larger core counts become easier to justify, as background processing begins to dominate. But I'd like to see statistics on how popular PC-based home media servers are in the first place.
Plenty of people use XBMC, iTunes, PS3 Media Server, Twonky, Windows Media Server, VideoLAN, Firefly, Quicktime, TVersity, etc... it isn't a niche market and such people wouldn't consider running these applications on their system to mean it's suddenly a "server".
I'm trying to find what use cases are most common because economies of scale benefit the most common use cases.
No you said 1 core for foreground and 1 core for background, but that is completely unjustified. Look at what you replied to:
Even if you are using a single process program, it can benefit from not having to share it's core with the various system processes.
So your use case is if the foreground process is single-threaded and all your background processing is single-threaded and non-instensive and the combination of it adds up to less than the processing power of one core - which itself is not a unit of measure. Speaking in terms of number of cores makes no sense anyway. It depends not only on the use cases but also the problems to be solved and the implementation of the applications to solve those problems.
So how would parallel speedup help with a linked list, a tree, or a hash table? Perhaps rotations of a balanced search tree could run in a separate thread, but that's about all I can think of. I admit to having fallen victim to the fallacy of lack of imagination.
Because - and perhaps I misspoke when I repeated the term 'traverse' - you are never just traversing a tree, you are always doing some sort of processing on the nodes (which can be passed to worker threads) and every branch in a tree is an opportunity to have other threads take up the traversal task.
What I meant was that the serial part dominates long before 72 cores are used.
In theory you could have a problem that is 99.99999% percent serial, but in practice you probably don't.
Which brings in synchronization delays when your parser thread has to pass such "enough information" about each element to another thread.
Of course you will have synchronization delays at some point but if that is the case then another possible way is that the parser thread goes through processing each element and when it has enough information to process the next element it pops the current one onto a worker queue for completion by another thread. There are many ways to go about this if you have a bit of imagination but it depends on your target hardware, your specific problem and the context of the problem (you may not want to thrash all your available resources on this one problem leaving nothing for other concurrent tasks).
It is never necessary for the compiler to know the size of a given class when not doing things specifically related to that class. In C++, objects can be existing in memory (like Java's basic types) or separately on the heap (like Java's classes). This means it's often necessary to know how large an instantiation of a class will be, which leads to the private members being viewable.
It's necessary in both C++ and Java, the point of difference is if you were to create a stack allocated instance of a class in C++ but not use it, why would you be doing that?
and traversing an index was an inherently serial process.
Traversing an index? What do you mean by "index"? Traversing data structures is certainly not inherently serial at all.
I don't see how rendering a web page can be fully parallelized.
Probably because he didn't say "fully parallelized", in fact "fully parallelized" would be that every element of something is parallel, which isn't ever the case, you are always going to have a serial element somewhere.
Parsing and reflow, no.
Why not? Just because there is a serial part to the problem doesn't mean you can't leverage parallel processing. If I have a set of elements that need to be processed serially that doesn't mean the task of processing of each element couldn't utilize multiple cores. Or even that I couldn't process each element to a degree that it provides enough information for another thread/process to start processing the next element.