Roughly, it is. However that has never been used to connect a discrete GPU to a CPU, to my knowledge. AMD did it first, Intel copied it, and nVidia has joined the world of proprietary interconnects, but the first to do so for CPUGPU situation.
Don't get a development team larger than the task really calls for. I've seen so many chunks of code that really has not much to do be horribly convoluted because they split up the work amongst more developers than it makes sense to have working on it.
Cost per port on the switch side and power requirements on the switch side I presume he means. Particularly if he's talking about CAT6 rather than DAC, it is a pretty huge power hog. Note that in relatively recent developments a wave of PHYs have come about that significantly improve that, but it's still pretty big.
Now using DACs should bring the power complaint in line with infiniband, though the runs can't be very long by comparison, but then again 'cheap' Infiniband cables can't be that long either (which are just common with 40 GbE assuming we are talking about QDR, FDR, or EDR IB).
Well, maybe if the ARM servers did NV-Link. POWER and ARM can do NV-Link CPU to GPU, Intel however was either not invited to the party or was disinterested in working to enable it. Of course I'm suspecting AMD and nVidia collaborating would be unlikely
Again though, there'd be no room to complain about PCIe lanes.
While this is presumably a dig at AMD APUs, the fact is that GPUs greatly outclass even the most powerful CPUs for a lot of tasks. The next time the question is likely to be worth re-examining will be when Xeon's start getting AVX-512 extensions.
Well, I'd like to think that his language suggests he knows full well the legislation is a dead end and just a way for him to introduce controversy for the sake of having his viewpoint heard more widely... I mean he's a relative nobody who no one would bother reporting on if he had some press conference, and this is his lever of getting something out there. Of course I could be being optimistic in hoping that a legislator wouldn't seriously realize how bad an idea in practice such a bill could be.
Hoping that the stated sentiment behind the bill is not lost in the face of how terrible an idea the actual bill is.
I agree there's no way this could be a good idea to actually implement.
However I question the value of widespread, instant, and permanent documentation of everything. We do not need pictures of every snack and meal each person eats. We don't need to instantly be able to access 100 different camera angles of a gruesome car accident (though camera angles of such things may be helpful in the medium term to understand what went wrong). We don't have a long term value from footage of all sorts of common things that individually tell us nothing we didn't already know.
It's striving for some sort of compromise in the face of a rather uncomfortable scenario.
We value free speech and it's a dangerous thing to flirt with the idea of *any* restriction. So to *forbid* anything is just outright unacceptable from the outset.
On the other hand, people are jerks and intentionally or unintentionally do hurtful things that really offer no value whatsoever to public discourse.
So if you care about it and feel compelled to say *something*, this doesn't seem such a strange thing to put out there, even though I can't see it being a good idea even in this form.
Particularly in professional software, this is all too common. The pitiable users subjected to it have very little say in the matter, and that reality is reflected in the quality of the software. It's bad enough for common enterprise products from various vendors (IBM and MS commonly), but it just goes completely hellish when we start looking at custom software for particular businesses.
Like you, I've seen consequences of marching orders that serve more to make people provide supporting evidence to vindicate a decision to spend money rather than actually focusing on providing an experience the end users would actually want...
Probably the TSX problems are closer in some respect, that the fix comes in microcode. With F00F, the OSes had to workaround the issue one way or another.
For an analogous screw up, you only need to look at Haswell/Broadwell and TSX feature, which they retroactively disabled due to defect.
The FDIV was noteworthy because the state of things were such that they didn't have much recourse other than replacing the processors. We haven't seen a defect such that processors had to be physically recalled at such scale since, though there have been a number of similarly disastrous issues, if not for the fact they could push a microcode change to disable something or workaround...
Yeah, it's just that Java was *the* de-facto language for the tech education to churn out. So the 'I don't know what I'm doing but I'm told to do code to get money' crowd is comprised largely of people who do Java and only Java because they were taught the one thing. So good Java developers are hard to see in the sea of crap. Meanwhile, good developers realize that knowing Java or any other language for that matter means you don't need to be picky about what language you use and are flexible to do other things, making less popular languages that don't receive as much 'formal' education looking rosy since it's mostly the playground of motivated and/or skilled individuals who don't get too phased by deviating from their specific teachings.
In other words, a technology or process that gets supremely popular will inevitably be made to look bad by people 'forced' to do it, and they will do it badly as a rule.
I guess that's a fair point, though I would argue that most common developers are nowhere near getting their code to the point where they get good advantage out of those sorts of differences.
It may have a higher ceiling for programmer to convey intent to optimizer, but most programmers aren't that proficient. The breed of programmer that could match the general required skill by systems in the 80s and earlier and before are a rare breed...
And for 99% of code out there, that nitty gritty won't even be noticed against the backdrop of suboptimal design decisions. Mortals are one or two orders of magnitude away from it being worth sweating that overhead.
Note that the 'language' is not slow, inefficient, etc. It's hard for a language to be anything.
Now the de-factor *runtime* implementation of said language... Actually isn't that bad either for most people. Yes, if you are an idealized developer writing the most efficient code possible, there is more absolute potential in a C implementation, however in practice the potential delta is extremely small compared to doing a 'good' implementation, regardless of which runtime is executing. A lot of code out there can see an order of magnitude performance improvement through improvements to the code in-place.
Java gets *particularly* a bad rap by being the first language to popularize the runtime as a 'performance friendly' strategy when their runtime was particularly bad, but mostly because by virtue of its popularity, all the less than best programmers are turning out code for it.
Of course, while I recognize that the usual criticisms are not as bad or not JRE's fault, I still hate the wrangling of java runtimes on a system...
Note that in the debian.org set, Java won on cpu speed in one benchmark, lost on all in terms of resource utilization compared to C. So compared to C, it seems to back the assertion that Java on a JVM is disadvantaged cpu/memory wise compared to a compiled C application. Of course this is a selection of benchmarks that has had the world to think about it and probably does not represent what the average developer will achieve with the respective languages.
Of course, there are a lot of languages whose runtime are as slow if not slower than Java, yet Java does continue to be the whipping boy for people wanting to talk about bad performance.
The short of it is that in the real world, the differences in the languages pale in comparison to what the developer can do. On a typical application I've encountered, generally optimizations within the way the code runs can yield given the same runtime can see an order of magnitude difference without even thinking about the relative contribution of the runtime differences from porting to another language. So it's a fascinating academic discussion, but comfort with the languages is far more important in reality. Java has suffered in practice because it's where all the developers went to churn out their dubious code...
I agree, but 'the' definitive style guide for indentation said '4 spaces, no tabs'. I always thought the tab character made most sense for indicating code depth, with spaces for extending the tabs on a line continuation to align with whatever content it should align with. However it's more important that everyone be using the same thing than me getting my way, so I use spaces now.
Swift shouldn't do away with braces nor should python add them. Once a language has made a choice, they need to stick with it. A language that would change such fundamentals once in productive use would be idiotic.
Slashdot Mirror
Roughly, it is. However that has never been used to connect a discrete GPU to a CPU, to my knowledge. AMD did it first, Intel copied it, and nVidia has joined the world of proprietary interconnects, but the first to do so for CPUGPU situation.
Don't get a development team larger than the task really calls for. I've seen so many chunks of code that really has not much to do be horribly convoluted because they split up the work amongst more developers than it makes sense to have working on it.
Cost per port on the switch side and power requirements on the switch side I presume he means. Particularly if he's talking about CAT6 rather than DAC, it is a pretty huge power hog. Note that in relatively recent developments a wave of PHYs have come about that significantly improve that, but it's still pretty big.
Now using DACs should bring the power complaint in line with infiniband, though the runs can't be very long by comparison, but then again 'cheap' Infiniband cables can't be that long either (which are just common with 40 GbE assuming we are talking about QDR, FDR, or EDR IB).
Well, maybe if the ARM servers did NV-Link. POWER and ARM can do NV-Link CPU to GPU, Intel however was either not invited to the party or was disinterested in working to enable it. Of course I'm suspecting AMD and nVidia collaborating would be unlikely
Again though, there'd be no room to complain about PCIe lanes.
While this is presumably a dig at AMD APUs, the fact is that GPUs greatly outclass even the most powerful CPUs for a lot of tasks. The next time the question is likely to be worth re-examining will be when Xeon's start getting AVX-512 extensions.
Well, I'd like to think that his language suggests he knows full well the legislation is a dead end and just a way for him to introduce controversy for the sake of having his viewpoint heard more widely... I mean he's a relative nobody who no one would bother reporting on if he had some press conference, and this is his lever of getting something out there. Of course I could be being optimistic in hoping that a legislator wouldn't seriously realize how bad an idea in practice such a bill could be.
Hoping that the stated sentiment behind the bill is not lost in the face of how terrible an idea the actual bill is.
I agree there's no way this could be a good idea to actually implement.
However I question the value of widespread, instant, and permanent documentation of everything. We do not need pictures of every snack and meal each person eats. We don't need to instantly be able to access 100 different camera angles of a gruesome car accident (though camera angles of such things may be helpful in the medium term to understand what went wrong). We don't have a long term value from footage of all sorts of common things that individually tell us nothing we didn't already know.
It's striving for some sort of compromise in the face of a rather uncomfortable scenario.
We value free speech and it's a dangerous thing to flirt with the idea of *any* restriction. So to *forbid* anything is just outright unacceptable from the outset.
On the other hand, people are jerks and intentionally or unintentionally do hurtful things that really offer no value whatsoever to public discourse.
So if you care about it and feel compelled to say *something*, this doesn't seem such a strange thing to put out there, even though I can't see it being a good idea even in this form.
Particularly in professional software, this is all too common. The pitiable users subjected to it have very little say in the matter, and that reality is reflected in the quality of the software. It's bad enough for common enterprise products from various vendors (IBM and MS commonly), but it just goes completely hellish when we start looking at custom software for particular businesses.
Like you, I've seen consequences of marching orders that serve more to make people provide supporting evidence to vindicate a decision to spend money rather than actually focusing on providing an experience the end users would actually want...
"Clear Linux Project for Intel Architecture"
In reading a few pages, I don't think they used the word 'Intel' enough....
They mean warm in the sense of color temperature (yellowish).
Interesting acheivement, though I wonder at any help for lifespan. I'd rather put in LED bulbs that will probably outlive the rest of the house...
Probably the TSX problems are closer in some respect, that the fix comes in microcode. With F00F, the OSes had to workaround the issue one way or another.
Well 'Deja Vu' and you can leave '5' off.
For an analogous screw up, you only need to look at Haswell/Broadwell and TSX feature, which they retroactively disabled due to defect.
The FDIV was noteworthy because the state of things were such that they didn't have much recourse other than replacing the processors. We haven't seen a defect such that processors had to be physically recalled at such scale since, though there have been a number of similarly disastrous issues, if not for the fact they could push a microcode change to disable something or workaround...
Yeah, it's just that Java was *the* de-facto language for the tech education to churn out. So the 'I don't know what I'm doing but I'm told to do code to get money' crowd is comprised largely of people who do Java and only Java because they were taught the one thing. So good Java developers are hard to see in the sea of crap. Meanwhile, good developers realize that knowing Java or any other language for that matter means you don't need to be picky about what language you use and are flexible to do other things, making less popular languages that don't receive as much 'formal' education looking rosy since it's mostly the playground of motivated and/or skilled individuals who don't get too phased by deviating from their specific teachings.
In other words, a technology or process that gets supremely popular will inevitably be made to look bad by people 'forced' to do it, and they will do it badly as a rule.
yes, but the phrase was 'all of Java is extremely fast' [on certain runtimes]. The post didn't say the runtimes were fast, but all of Java being fast.
Also a 'rubtime' being efficient is a bit TMI
I guess that's a fair point, though I would argue that most common developers are nowhere near getting their code to the point where they get good advantage out of those sorts of differences.
It may have a higher ceiling for programmer to convey intent to optimizer, but most programmers aren't that proficient. The breed of programmer that could match the general required skill by systems in the 80s and earlier and before are a rare breed...
And for 99% of code out there, that nitty gritty won't even be noticed against the backdrop of suboptimal design decisions. Mortals are one or two orders of magnitude away from it being worth sweating that overhead.
I assume/hope that is a joke.... There is no way for 'all' of any language to be 'fast'.
Eg.
sleep 100
echo hello world
would be a slow way of doing hello world regardless of language.
Note that the 'language' is not slow, inefficient, etc. It's hard for a language to be anything.
Now the de-factor *runtime* implementation of said language... Actually isn't that bad either for most people. Yes, if you are an idealized developer writing the most efficient code possible, there is more absolute potential in a C implementation, however in practice the potential delta is extremely small compared to doing a 'good' implementation, regardless of which runtime is executing. A lot of code out there can see an order of magnitude performance improvement through improvements to the code in-place.
Java gets *particularly* a bad rap by being the first language to popularize the runtime as a 'performance friendly' strategy when their runtime was particularly bad, but mostly because by virtue of its popularity, all the less than best programmers are turning out code for it.
Of course, while I recognize that the usual criticisms are not as bad or not JRE's fault, I still hate the wrangling of java runtimes on a system...
Wheels on my car do the job and have improved a lot. However, it's a bit disappointing that there isn't something new in 2015.
(Actually not that enamored of Java, but just feel like 'not new' should not be some automatic disappointment in a technology).
Note that for the DK2, I've been having a fun time with a GTX660. Still a hair above the average GPU in a random desktop, but not too shabby actually.
Quite a few developers actually were simplifying their graphics design specifically to work with VR with dreams of targeting 'mid-range' users.
Note that in the debian.org set, Java won on cpu speed in one benchmark, lost on all in terms of resource utilization compared to C. So compared to C, it seems to back the assertion that Java on a JVM is disadvantaged cpu/memory wise compared to a compiled C application. Of course this is a selection of benchmarks that has had the world to think about it and probably does not represent what the average developer will achieve with the respective languages.
Of course, there are a lot of languages whose runtime are as slow if not slower than Java, yet Java does continue to be the whipping boy for people wanting to talk about bad performance.
The short of it is that in the real world, the differences in the languages pale in comparison to what the developer can do. On a typical application I've encountered, generally optimizations within the way the code runs can yield given the same runtime can see an order of magnitude difference without even thinking about the relative contribution of the runtime differences from porting to another language. So it's a fascinating academic discussion, but comfort with the languages is far more important in reality. Java has suffered in practice because it's where all the developers went to churn out their dubious code...
I agree, but 'the' definitive style guide for indentation said '4 spaces, no tabs'. I always thought the tab character made most sense for indicating code depth, with spaces for extending the tabs on a line continuation to align with whatever content it should align with. However it's more important that everyone be using the same thing than me getting my way, so I use spaces now.
Swift shouldn't do away with braces nor should python add them. Once a language has made a choice, they need to stick with it. A language that would change such fundamentals once in productive use would be idiotic.