DRM is a means of limiting the distribution of a purchased (or licensed) digital file by the owner (or licensee). Exclusively locking a subscription service to a platform is not DRM. Rather, it is a means of boosting the sale of the platform by offering additional platform-only services. We can discuss the harm and inconvenience that platform lock-in may cause. However, we should not confuse the issue with DRM. That will just inflame old passions, preventing someone from approaching this new distinct issue from a fresh perspective.
No doubt many people against DRM will also be against platform lock-in. Perhaps others may not. For instance, I am generally against DRM. I purchased a digital file; I would like to be free to make copies of it for my own use. However, with platform-based subscriptions, I just can't get all that upset about it. I don't own an Android device, so I won't subscribe to Google Play. Also, there are a wealth of quality subscription services out there that run on all of the popular platforms. So what's the big deal?
Have you spent any time in Blacksburg? It's a small town. They still remember. This student who had been there for nearly four years knew exactly what he was doing.
As long as you're all right with proprietary drivers, NVIDIA's Linux driver is quite solid. It needs to be, as it is used in all of their supercomputers.
I greatly prefer open standards as well. However, CUDA is considerably less painful to work in than OpenCL. NVIDIA has also demonstrated more commitment to capturing GPGPU business than AMD. For example, the first supercomputer on top500.org with AMD GPUs ranks in at 94th. In contrast, NVIDIA GPUs are used in the 2nd ranked supercomputer. Xeon Phi is gaining in popularity, but Intel wants you to work in CilkPlus not OpenCL.
That said, I believe the future is tight integration (i.e., cache coherence) between the GPU/accelerator and main memory. AMD's HSA is a step in the right direction. CUDA has some catching up to do in this regard.
I really appreciated the Cell BE too. I do hope that that architecture, with cache coherence (local stores are a pain to manage), becomes more common. Have you taken a look at Texas Instrument's KeyStone II? It's ARM + crazy DSPs. It doesn't seem that anyone has really noticed it though. http://www.ti.com/dsp/docs/dsp...
"Perl is an excellent candidate, especially considering how work on Perl6, framed as a complete revamp of the language, began work in 2000 and is still inching along in development."
This does not imply that Perl is on its way out. I don't use the language myself (I despise it, personally), but I know many who use it on a daily basis. It is still a go-to language for many programmers (albeit, who may no longer be in their 20s) who need to quickly hack together a test harness for a larger system. It could merely be that Perl is "complete" for applications where it is useful. Further revision is no longer necessary.
Also, I'd hardly say that C++ is on it's way out, even though C++11 took so long to be ratified.
There is a new problem that comes with reliance on adjuncts. Departments rarely monitor the performance of instruction themselves. Departments make decisions on re-hiring or firing an adjunct based upon student reviews and evaluations. Left without recourse, adjuncts are perversely incentivized to teach easy classes and give out high marks---this helps ensure good reviews. (It also continues the trend in grade inflation.) Adjunct professors cannot challenge their students without risking being fired.
My girlfriend recently graduated with a PhD in history from a department ranked 11th by US News. She's won a number of nationally recognized awards. She still can't find a tenure-track job. She was hired as a visiting professor at a university for this past year. Pay was around $40k with benefits. She got great reviews from her students, so the university offered to re-hire her as an adjunct with the same workload (teaching four classes a semester)... but at *half* the pay and *without* benefits. Her pay and benefits were better as a graduate student! She politely declined the offer. Being valued so little by the same world that qualified you is hard to endure.
This will increase the cost to farmers too. That gets passed on to consumers. But perhaps we're all just commenting on the obvious: Production cost of X increases. The production cost of any product Y directly (or transitively) dependent upon X will also increase (or the value/quality of Y may decrease to compensate).
What made Cell a nightmare to program for was the SPU's local store. The local store is great for performance, but a pain to program since the programmer had to explicitly move data back and forth between main memory and the local store (hardware designers back then all thought compilers could solve their problems for them--see Itanium). MIC is cache coherent. All memory references are snooped on the bus(es). MIC programmers don't have to worry about what's loaded in memory and what is not. An instruction merely has to dereference a memory address, and the MIC hardware will be happy to go fetch the needed data for you, automagically. It was not so with Cell.
It's not entirely syntactical. Local shared memory is exposed to the CUDA programmer (e.g., __sync_threads()). CUDA programmers also have to be mindful of register pressure and the L1 cache. These issues directly affect the algorithms used by CUDA programmers. CUDA programmers have control over very fast local memory---I believe that this level of control is missing from MIC's available programming models. Being closer to the metal usually means a harder time programming, but higher performance potential. However, I believe NVIDIA has made CUDA pretty programmer friendly, given the architectural constraints. I'd like to hear the opinions of MIC programmers, since I have no direct experience with MIC.
I'm glad to see SteamOS has picked up PREEMPT_RT. I hope they stick with it. The PREEMPT_RT developers recently reported that they lacked the man-power to continue development (https://lwn.net/Articles/572740/). Maybe Valve can contribute money or man-power?
Also, since NVIDIA is keen to support SteamOS, this means that NVIDIA must officially support PREEMPT_RT. NVIDIA's driver support for PREEMPT_RT has always been spotty. At best, hacks to the driver's GPL layer were required to make it work. I hope those days are over. NVIDIA has really improved their Linux driver over th years in order to better serve the Android and HPC markets. PREEMPT_RT support should make it even better (PREEMPT_RT can often uncover pre-existing bugs).
The choppiest site I've visited on my 4S with iOS7 is slashdot's mobile site. The background of each story is "active" in the sense that when I thumb-down to scroll, the story's background dims to grey. The regular white background returns when I lift my thumb. This, combining this action with scrolling really makes for a choppy experience!
Check out the Udacity class on parallel programming. It's mostly CUDA (I believe it's taught by NVIDIA engineers): https://www.udacity.com/course/cs344
CUDA is generally easier to program than OpenCL. Of course, CUDA only runs on NVIDIA GPUs though.
I am very skeptical of the marketing claims of low-latency human input devices like gaming mice and keyboards. I understand the usefulness of special device configuration (e.g., macro buttons), but does a mouse really need to be polled every 1ms (like Razer mice)? In driving tests, the reaction time of a prepared driver is on the order of 750 to 1000ms (http://www.tandfonline.com/doi/abs/10.1207/STHF0203_1#.UeGmimR4a04 --- sorry for the paywall). Obviously, driving is not gaming, but let's suppose a gaming reaction time is half this: 375ms to 500ms. Let's compare two mice: one polls at 1ms and the other polls at 10ms. With a base reaction time of 375ms, the resulting difference is about 3% at worst, 2% at best. Is low-latency input devices where we should be optimizing a player's performance? Does it really matter all that much? Wouldn't it be better to focus on things such as network latency and possibly even OS schedulers?
I admit, I am not a serious gamer and I don't invest heavily in gaming equipment. I would be very interested in hearing objective opinion from a gamer. Does an input latency 10ms really matter? If so, do you have objective data that can rule out the placebo effect?
I wonder if it's not so much a function of age, but rather that "older" programmers want to live in a place where they can own a home and raise a family. That is exceedingly hard in the Silicon Valley, even for someone with a well-paid tech job. The cost of a rundown three bedroom bungalow in Cupertino is in excess of one million dollars (Zillow link: http://tinyurl.com/lq2wpcq). A four or five bedroom home is closer to two million. Purchasing such a home is a challenge for even a family with two tech incomes, harder for a family with one tech income and one "normal" income, and damned near impossible for a family with a single breadwinner. Even if you manage to pull off purchasing a home, you've still got a rundown bungalow. Why not go somewhere where you can better enjoy the fruits of your labor?
As a tech worker in his early 30s in the Valley, guys my age talk constantly of moving to Austin, Raleigh, or some other non-Valley tech hub---some place where the idea of raising a family doesn't boggle the mind. I suggest that while age discrimination may be very real, we must also consider that "the old guys" are merely moving out of the Valley. Thus, the average employee age of any company that has the bulk of their operations in the Valley will skew towards the young side. I don't believe it's a coincidence that the average age is less than 30, since 30 is about the age many educated men start a family.
It strikes me that a 3D printed gun doesn't need to actually look like a gun at all. Indeed, a 3D printed gun could use colors/markings and form of existing toy guns (a nerf gun that fires real bullets!), or perhaps it could look like a toy dinosaur that actually shoots bullets from its head. Perhaps I am stating the obvious, but it never occurred to me during all these discussions about 3D printed guns. Something like this puts security/police/secret service officers facing people armed "toys" in a terrible position.
Now both American and Chinese solar companies are failing. Further private investment in this oversupplied economy seems unwise; there is a distaste for subsidizing failed business models in the US (at least where green tech is concerned). Perhaps university research is the best alternative investment.
With respect to throughput and multitasking, your desktop OS may be better. Theoretically, a focused game OS may take steps to reduce worst-case latency (real-time OS techniques) and optimize operations for game-related workloads (possibly game-tuned memory allocators?). Unfortunately, console makers are very secretive on how their OSs are designed and implemented. I would be interested to hear from anyone who is familiar with modern game OS development. Is there any secret sauce?
Slashdot Mirror
DRM is a means of limiting the distribution of a purchased (or licensed) digital file by the owner (or licensee). Exclusively locking a subscription service to a platform is not DRM. Rather, it is a means of boosting the sale of the platform by offering additional platform-only services. We can discuss the harm and inconvenience that platform lock-in may cause. However, we should not confuse the issue with DRM. That will just inflame old passions, preventing someone from approaching this new distinct issue from a fresh perspective.
No doubt many people against DRM will also be against platform lock-in. Perhaps others may not. For instance, I am generally against DRM. I purchased a digital file; I would like to be free to make copies of it for my own use. However, with platform-based subscriptions, I just can't get all that upset about it. I don't own an Android device, so I won't subscribe to Google Play. Also, there are a wealth of quality subscription services out there that run on all of the popular platforms. So what's the big deal?
Have you spent any time in Blacksburg? It's a small town. They still remember. This student who had been there for nearly four years knew exactly what he was doing.
As long as you're all right with proprietary drivers, NVIDIA's Linux driver is quite solid. It needs to be, as it is used in all of their supercomputers.
I greatly prefer open standards as well. However, CUDA is considerably less painful to work in than OpenCL. NVIDIA has also demonstrated more commitment to capturing GPGPU business than AMD. For example, the first supercomputer on top500.org with AMD GPUs ranks in at 94th. In contrast, NVIDIA GPUs are used in the 2nd ranked supercomputer. Xeon Phi is gaining in popularity, but Intel wants you to work in CilkPlus not OpenCL.
That said, I believe the future is tight integration (i.e., cache coherence) between the GPU/accelerator and main memory. AMD's HSA is a step in the right direction. CUDA has some catching up to do in this regard.
I really appreciated the Cell BE too. I do hope that that architecture, with cache coherence (local stores are a pain to manage), becomes more common. Have you taken a look at Texas Instrument's KeyStone II? It's ARM + crazy DSPs. It doesn't seem that anyone has really noticed it though. http://www.ti.com/dsp/docs/dsp...
I agree. I like to use python instead.
"Perl is an excellent candidate, especially considering how work on Perl6, framed as a complete revamp of the language, began work in 2000 and is still inching along in development."
This does not imply that Perl is on its way out. I don't use the language myself (I despise it, personally), but I know many who use it on a daily basis. It is still a go-to language for many programmers (albeit, who may no longer be in their 20s) who need to quickly hack together a test harness for a larger system. It could merely be that Perl is "complete" for applications where it is useful. Further revision is no longer necessary.
Also, I'd hardly say that C++ is on it's way out, even though C++11 took so long to be ratified.
There is a new problem that comes with reliance on adjuncts. Departments rarely monitor the performance of instruction themselves. Departments make decisions on re-hiring or firing an adjunct based upon student reviews and evaluations. Left without recourse, adjuncts are perversely incentivized to teach easy classes and give out high marks---this helps ensure good reviews. (It also continues the trend in grade inflation.) Adjunct professors cannot challenge their students without risking being fired.
My girlfriend recently graduated with a PhD in history from a department ranked 11th by US News. She's won a number of nationally recognized awards. She still can't find a tenure-track job. She was hired as a visiting professor at a university for this past year. Pay was around $40k with benefits. She got great reviews from her students, so the university offered to re-hire her as an adjunct with the same workload (teaching four classes a semester)... but at *half* the pay and *without* benefits. Her pay and benefits were better as a graduate student! She politely declined the offer. Being valued so little by the same world that qualified you is hard to endure.
It seems like taint tracking and sanitation should be pervasive and explicit. This can be partially enforced by type enforcement, no?
Recent CNN report on the prices of beef and dairy: http://money.cnn.com/2014/04/1...
This will increase the cost to farmers too. That gets passed on to consumers. But perhaps we're all just commenting on the obvious: Production cost of X increases. The production cost of any product Y directly (or transitively) dependent upon X will also increase (or the value/quality of Y may decrease to compensate).
What made Cell a nightmare to program for was the SPU's local store. The local store is great for performance, but a pain to program since the programmer had to explicitly move data back and forth between main memory and the local store (hardware designers back then all thought compilers could solve their problems for them--see Itanium). MIC is cache coherent. All memory references are snooped on the bus(es). MIC programmers don't have to worry about what's loaded in memory and what is not. An instruction merely has to dereference a memory address, and the MIC hardware will be happy to go fetch the needed data for you, automagically. It was not so with Cell.
It's not entirely syntactical. Local shared memory is exposed to the CUDA programmer (e.g., __sync_threads()). CUDA programmers also have to be mindful of register pressure and the L1 cache. These issues directly affect the algorithms used by CUDA programmers. CUDA programmers have control over very fast local memory---I believe that this level of control is missing from MIC's available programming models. Being closer to the metal usually means a harder time programming, but higher performance potential. However, I believe NVIDIA has made CUDA pretty programmer friendly, given the architectural constraints. I'd like to hear the opinions of MIC programmers, since I have no direct experience with MIC.
I'm glad to see SteamOS has picked up PREEMPT_RT. I hope they stick with it. The PREEMPT_RT developers recently reported that they lacked the man-power to continue development (https://lwn.net/Articles/572740/). Maybe Valve can contribute money or man-power?
Also, since NVIDIA is keen to support SteamOS, this means that NVIDIA must officially support PREEMPT_RT. NVIDIA's driver support for PREEMPT_RT has always been spotty. At best, hacks to the driver's GPL layer were required to make it work. I hope those days are over. NVIDIA has really improved their Linux driver over th years in order to better serve the Android and HPC markets. PREEMPT_RT support should make it even better (PREEMPT_RT can often uncover pre-existing bugs).
The choppiest site I've visited on my 4S with iOS7 is slashdot's mobile site. The background of each story is "active" in the sense that when I thumb-down to scroll, the story's background dims to grey. The regular white background returns when I lift my thumb. This, combining this action with scrolling really makes for a choppy experience!
I can imagine reddit threads where members crowdfund promoted tweets against the most despised companies, such as cable and telco providers.
Check out the Udacity class on parallel programming. It's mostly CUDA (I believe it's taught by NVIDIA engineers): https://www.udacity.com/course/cs344
CUDA is generally easier to program than OpenCL. Of course, CUDA only runs on NVIDIA GPUs though.
I am very skeptical of the marketing claims of low-latency human input devices like gaming mice and keyboards. I understand the usefulness of special device configuration (e.g., macro buttons), but does a mouse really need to be polled every 1ms (like Razer mice)? In driving tests, the reaction time of a prepared driver is on the order of 750 to 1000ms (http://www.tandfonline.com/doi/abs/10.1207/STHF0203_1#.UeGmimR4a04 --- sorry for the paywall). Obviously, driving is not gaming, but let's suppose a gaming reaction time is half this: 375ms to 500ms. Let's compare two mice: one polls at 1ms and the other polls at 10ms. With a base reaction time of 375ms, the resulting difference is about 3% at worst, 2% at best. Is low-latency input devices where we should be optimizing a player's performance? Does it really matter all that much? Wouldn't it be better to focus on things such as network latency and possibly even OS schedulers?
I admit, I am not a serious gamer and I don't invest heavily in gaming equipment. I would be very interested in hearing objective opinion from a gamer. Does an input latency 10ms really matter? If so, do you have objective data that can rule out the placebo effect?
"The rule is that you use a before words that start with a consonant sound and an before words that start with a vowel sound."
It's all about sound. "N" is pronounced "En." Hence, "an."
Grammar Girl: http://tinyurl.com/nuj8h5a
I wonder if it's not so much a function of age, but rather that "older" programmers want to live in a place where they can own a home and raise a family. That is exceedingly hard in the Silicon Valley, even for someone with a well-paid tech job. The cost of a rundown three bedroom bungalow in Cupertino is in excess of one million dollars (Zillow link: http://tinyurl.com/lq2wpcq). A four or five bedroom home is closer to two million. Purchasing such a home is a challenge for even a family with two tech incomes, harder for a family with one tech income and one "normal" income, and damned near impossible for a family with a single breadwinner. Even if you manage to pull off purchasing a home, you've still got a rundown bungalow. Why not go somewhere where you can better enjoy the fruits of your labor?
As a tech worker in his early 30s in the Valley, guys my age talk constantly of moving to Austin, Raleigh, or some other non-Valley tech hub---some place where the idea of raising a family doesn't boggle the mind. I suggest that while age discrimination may be very real, we must also consider that "the old guys" are merely moving out of the Valley. Thus, the average employee age of any company that has the bulk of their operations in the Valley will skew towards the young side. I don't believe it's a coincidence that the average age is less than 30, since 30 is about the age many educated men start a family.
It strikes me that a 3D printed gun doesn't need to actually look like a gun at all. Indeed, a 3D printed gun could use colors/markings and form of existing toy guns (a nerf gun that fires real bullets!), or perhaps it could look like a toy dinosaur that actually shoots bullets from its head. Perhaps I am stating the obvious, but it never occurred to me during all these discussions about 3D printed guns. Something like this puts security/police/secret service officers facing people armed "toys" in a terrible position.
Electric shock in a game is not new. Tekken Torture from 2001: http://www.eddostern.com/tekken_torture_tournament.html
A capitalist economy partly guards against oversupply. However, oversupply has resulted directly from Chinese policies: http://www.nytimes.com/2012/10/05/business/global/glut-of-solar-panels-is-a-new-test-for-china.html
Now both American and Chinese solar companies are failing. Further private investment in this oversupplied economy seems unwise; there is a distaste for subsidizing failed business models in the US (at least where green tech is concerned). Perhaps university research is the best alternative investment.
With respect to throughput and multitasking, your desktop OS may be better. Theoretically, a focused game OS may take steps to reduce worst-case latency (real-time OS techniques) and optimize operations for game-related workloads (possibly game-tuned memory allocators?). Unfortunately, console makers are very secretive on how their OSs are designed and implemented. I would be interested to hear from anyone who is familiar with modern game OS development. Is there any secret sauce?
Maybe this isn't a solution for FPS games, but I would love to be able to play Civilization V from the cloud with all the graphic bells and whistles.