Let's see, 3D Performance on a Discrete card. For all the billions they make they STILL can't make a discrete (or mobile) GPU worth a crap. Also, OpenCL on Windows, OSX, and Linux.
> Most of their other consumer audio equipment is extremely over-priced.
Gee you think?? Why the hell would I buy form ANY company that can't release tech specs such as S/N ratio, THD, etc. for their products?? If they can't be honest, authentic, and treat the customer with respect FUCK THEM for their "lies" of omission.
The same garbage happens with bicycle manufacturers not listing their average weight, and motorcycles "conveniently" not listing their dry weight, wet weight, and more importantly bhp.
> But how many people can actually see that when all the shit be blowing up all over the screen?
After 1080+ I agree most can't. Resolution is NOT the barrier today.
Lighting is. As in Real-Time Radiosity. Crysis/Unreal is doing real-time 3-pass bounces. It is "good enough" (for the next few years)
Almost every game has crappy lighting -- i.e. quantity (performance) is favored over quality (accurate)
> when I am focusing on actually playing a game as long as it stays above 30FPS
There are those who can tell _instantly_ when the framerate drops from 60 Hz down to 30 Hz and it looks stutterly as hell. Once you get used to 120+ Hz monitors with Lightboost it is hard to go back to crappy 30 Hz.
Games should be targeting 120+ Hz, and giving the player options to GUARANTEE 120 Hz framerates unlike some console games which run at a crappy 30 Hz.
Holy crap -- has hell frozen over? Sony is actually thinking about developers for once!? Using (mostly) off the shelf commodity parts is definitely going to help win back some developers. Time will tell if "they are less evil then Microsoft"
Ain't that the truth !! Glad you got modded up. It seems like every tech gets re-invented every 20 years by somebody trying to sell you their silver bullet. Microsoft is particularly bad with their 3 letter acronyms every 5 years. That is not to say they don't have a solution, but there are ALWAYS edge cases and assumptions that need to checked before I'll "buy" into it. Namely is your solution:
a) scalable? b) robust? c) efficient? d) not over-engineered? e) proven? f) using industry standards? g) Do you know when and where it _doesn't_ work?
The last one tells me how well you understand the problem, solution, and domain. If you haven't thought about ALL the issues your solution is probably half-baked. It is perfectly fine that a solution is not "complete" as long as you know both the pro's and con's of a solution. Programmers need to make tradeoffs every day. Some are acceptable, some are not. Do you know the difference on how to prioritize them?;-)
It seems to me there are 3 types of programmers...
1. Unable,
2. Unwilling,
3. Unmotivated, or
... with respect to learning.
As you grow older there are more calcium deposits in your brain which is where the term "fossilized thinking" comes from. You can't help those unable to learn or unwilling. These are where the stereotypes come from.
Now as to the last group...
They say the mind is like a muscle -- to keep it in top shape you need to exercise it. If old programmers are not motivated to learn then I have to ask why?? Have they mastered THAT much of programming that they have exhausted all the interested topics?? I would argue that there are SO MANY interesting topics in computing that any programmer worth his salt should _easily_ be able to find enough interesting problems to solve as they get older. That's one of the benefits to comp. sci. -- there is always something neat to learn. Nay, the human condition -- you will NEVER stop learning (unless you become close minded.) Everything from bit-twiddling tricks to optimizing multi-threaded-multi-core programming with "Big Data" should keep any reasonable programmer motivated to learn. If not, they they are probably either burnt-out or crappy programmers.
The advantages older programmers have is that they have a much wider experience to draw upon so they don't make the same dumb mistakes over-and-over as the youth. i.e. When you have badly designed languages like Javascript that do NO type-checking on misspelt variables you use better tools to prevent the mistakes from the 80's Basic.
Another advantage is that older programmers don't have to focus on the tediousness of syntax and can focus on the higher level algorithms.
It is not a matter of IF but WHEN. i.e. When is the human race going to grow up and look outside their myopic & arrogant view that they are the most important lifeform on the universe? Oh that's right, they finally have proof.
Contact has _already_ happened. It is just NOT allowed on the global scale - yet.
If I'm wrong I'll be just another idiot ranting that you won't remember.:-)
But if I'm right you'll be more interested in knowing that the limits to knowledge are not artificially limited by Science; there is another path to Knowledge.
Beside, the real interesting question is not "Are we alone?" but "Why the hell do we look so similar??"
1. One size doesn't fit all though. Most filesystems aside from ZFS sacrifice correctness for the sake of performance. * For enterprise correctness is more important then performance. * For home use performance is more important then correctness.
2. You seem to be ignoring history. As we've gone from 32-bit to 64-bit CPUs filesystems have likewise gone from 32-bit, 64-bit, and 128-bit.
Remember software (and hardware) is about engineering tradeoffs between 2 extremes:
Correct but Slow < - - - and - - - > Fast but Unstable
One of the retarded things about btrfs is that you can not see how much disk space is being used by each subvolume. How the hell can you have a filesystem and not know how much space is in use or free ??
The design of ZFS is much more wholistic. That is, when we take a step back and look at both the micro and macro we see that we are really trying to solve 3 problems:
* Volume Management * File System * Data Integrity
1. Your fallacy is assuming Privacy is mutually exclusive with Protection. It is not.
2. This issue has already been discussed to death a thousand times before:
"Sell not virtue to purchase wealth, nor Liberty to purchase power."
Which is better know as:
* Those who would trade a little bit of freedom for temporary safety deserve neither. * They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. * Those Who Sacrifice Liberty For Security Deserve Neither.
-- http://en.wikiquote.org/wiki/Benjamin_Franklin
> I have yet to see any vaguely credible evidence of any dangers from GMO crops.
Just because YOU are not aware of any does not imply there isn't any.
Until we see 100+ years long term studies WE DON'T KNOW.
When in doubt it would be better to NOT ACT hastily before we permanently cause irrevocable damage. Once the cat is out of the bag it is impossible to put it back in again.
>> Scientists don't make conclusions based on lack of evidence. We need proof they're not harmful to us and the environment. We don't have that proof. > You cannot prove a negative. What you can prove (and what already has been proven) is that all of the GMO crops are safer.. GMOs 0 deaths with...
Everyone that has eaten carrots has a 100% fatality rate. Therefore carrots are bad. See, I can abuse stats and provide bullshit arguments based on it too.
This phrase "prove a negative" is incorrect. If there are LONG-TERM studies (40 - 100 years) on the RESULTS of people eating GMO foods then we can make safety decisions based on EVIDENCE. i.e.
* Are people more or less healthy? * Are there chemicals / toxins / etc that are there when they shouldn't be? * Are there any effects on birth? etc.
We don't have 100+ years of study on GMO foods. Man has a annoying habit of fucking everything up in nature. It would be more prudent to ban the commercial use UNTIL we have more complete LONG TERM data on their safety especially when you have corporations that are proven & documented as being dishonest, unethical, and have paid some shill to advocate their propaganda because they ONLY care about corporate greed.
References: * The World According to Monsanto * Food Inc.
It is hard to determine the optimal efficiency of traffic flow without numbers, but let's try anyways...
a) If an HOV is _added_ to an _existing_ infrastructure, then having it is not taking anything away, but I agree with the assertion that it may not be the most optimal.
The problem we are trying to optimize is: How can we move the most cars (maximize distance) in the least amount of time. i.e. dX/dT. Which looks like a differential equation.
Would it be better instead of having the extra lane be HOV or be a Open lane? I don't know. I would like to see some studies in various high population areas first. Otherwise I think we are all pulling numbers out of our an ass. The technical term is "SWAG": scientific wild assed guess.
b) Likewise I would also like to see the converse data. If an _existing_ lane is _converted_ over then what happens to the traffic efficiency?
> that one clown doing 40 mph doesn't screw up the entire benefit (to drivers) of the HOV lane.
I partially agree with you. The 2+ clowns doing 60 mph instead of the legal 65 mph (or the more realistic 75 mph) in the far left-most two lanes are a MUCH bigger problem then maximizing the HOV lane usage. Those retards introduce standing waves in traffic which are far most destructive to dX/dT.
It is a shame that the Dept. of Motor Vehicles doesn't know shit about standing waves nor teaches people how to help optimize keeping vehicles moving in the traffic flow. One of these days every car will be able to pass it's current speed both forward and backwards to its neighbor's car so that people 5, 10, 20 mins down the road can know about future traffic conditions. i.e. Peer-to-Peer Car Knowledge.
*sigh* Another high ID that can't seem to focus on the _original_ discussion. Way to stay focused on the negative instead of adding something constructive to the dicussion! Thanks for proving my point that 6+ digit ids rarely add any useful signal; mostly useless noise.
Now, to bring this back on-topic:
Where are the studies that show benefits and negatives to HOV lanes?
I'm not interested in anecdotal evidence, hyperbole, nor conjecture; I'm interested in facts about HOV.
Guess people would rather bitch about off-topic non-issues then raise questions in order to get answers and have a healthy, constructive, informative discussion.
-- Unless you grok BOTH the postive AND negative about any system, you do NOT understand it (fully.)
He's got a 6-digit id. He's still relatively young.
The kids these days always rant and rave without any substance. Notice how he didn't provide _any_ stats on HOV lanes. He hasn't pointed out any factual benefits or disadvantages to them.
> for three register specifiers, which take up 15 bits total. Going to 256 registers would blow that up to 24 bits I appreciate your feedback.
> And it's vital for it to have single cycle access times. I'm not sure why you are asserting that MUST be single cycle? CPUs in the 80's were not single cycle. Even in today's CPUs there are many instructions that operate on registers that take multiple clock cycles. Would it be nice? Hell yeah. But is it mandatory? Since existing CPUs don't "break" I must conclude "no".
Your analysis is good however there are other options that still may make this feasible:
1. CPUs can be designed for specifying 1, 2, or 3 registers. I wasn't saying one was forced to use a tri-opcode format. But it certainly is _convenient_.:-)
2. Additionally there is a way to specify 3 registers, keep 32-bit code density and still gain 31-bit precision for "Load Immediate".:-)
Reserve the high bit of each opcode to mean: 0 = Immediate 1 = Opcodes
Anytime the Fetch & Decode sees a immediate value it knows that it is supposed to be paired with the previous opcode (or vice versa.) The point is, one doesn't need to stall the pipeline simply because you interleave 32-bit and "effective" 64-bit opcodes.
i.e. Given the pseudo-code:
r3 = r1 / r2;
r4 = r1 % r4
> constants are actually a well-studied problem in computer architecture. It's beneficial to include special features to help represent them in the instruction set, but there are good and bad ways of doing that
Actually I'd be very interested in that! Have any links or specific terms to search for?
Slashdot Mirror
> what more could you want in support?
Let's see, 3D Performance on a Discrete card. For all the billions they make they STILL can't make a discrete (or mobile) GPU worth a crap. Also, OpenCL on Windows, OSX, and Linux.
Meanwhile, almost everybody else in Scientific Computing is using (nVidia's) CUDA across all 3 platforms. /Oblg. Sad but true.
http://media.bestofmicro.com/V/6/233106/original/feature_image09.jpg
Wake me up when Bose releases ANY technical specifications (S/N ratio, THD) for their speakers.
Apple may be overpriced but at least they ALWAYS have tech specs for every shipping product.
> Most of their other consumer audio equipment is extremely over-priced.
Gee you think?? Why the hell would I buy form ANY company that can't release tech specs such as S/N ratio, THD, etc. for their products?? If they can't be honest, authentic, and treat the customer with respect FUCK THEM for their "lies" of omission.
The same garbage happens with bicycle manufacturers not listing their average weight, and motorcycles "conveniently" not listing their dry weight, wet weight, and more importantly bhp.
It is time to hold companies accountable.
> But how many people can actually see that when all the shit be blowing up all over the screen?
After 1080+ I agree most can't. Resolution is NOT the barrier today.
Lighting is. As in Real-Time Radiosity. Crysis/Unreal is doing real-time 3-pass bounces. It is "good enough" (for the next few years)
Almost every game has crappy lighting -- i.e. quantity (performance) is favored over quality (accurate)
> when I am focusing on actually playing a game as long as it stays above 30FPS
There are those who can tell _instantly_ when the framerate drops from 60 Hz down to 30 Hz and it looks stutterly as hell. Once you get used to 120+ Hz monitors with Lightboost it is hard to go back to crappy 30 Hz.
Games should be targeting 120+ Hz, and giving the player options to GUARANTEE 120 Hz framerates unlike some console games which run at a crappy 30 Hz.
Yes, I know it is 30-bits total. Hence the comment about 24-bit vs 30-bit, since 8-bit / channel is inadequate.
Oooh, that is awesome that 10-bit display is the minimum. I've hated banding in 24-bit images for ages.
Now if we could get 120 Hz standardized we'd be all set. Checking the link, oooh, I see it is. Excellent!
I really don't think there is enough demand though for 4K resolutions? Chicken-Egg problem of not enough content - not enough TVs to demand content.
At least the spec is shaping up VERY nicely.
Holy crap -- has hell frozen over? Sony is actually thinking about developers for once!? Using (mostly) off the shelf commodity parts is definitely going to help win back some developers. Time will tell if "they are less evil then Microsoft"
Thanks for the great read.
/Oblg.
http://www.dvhardware.net/news/nvidia_intel_insides_gpu_santa.jpg
or
http://media.bestofmicro.com/V/6/233106/original/feature_image09.jpg
So I'm supposed to pay $150 for a brand new router to replace a working box w/ Tomato that hasn't been touched in 4+ years ??
When it finally dies THEN I'll look into replacing the WRT54GL workhorse.
The first rule of networking: If it ain't broke, don't fuck with it.
Ain't that the truth !! Glad you got modded up. It seems like every tech gets re-invented every 20 years by somebody trying to sell you their silver bullet. Microsoft is particularly bad with their 3 letter acronyms every 5 years. That is not to say they don't have a solution, but there are ALWAYS edge cases and assumptions that need to checked before I'll "buy" into it. Namely is your solution:
a) scalable?
b) robust?
c) efficient?
d) not over-engineered?
e) proven?
f) using industry standards?
g) Do you know when and where it _doesn't_ work?
The last one tells me how well you understand the problem, solution, and domain. If you haven't thought about ALL the issues your solution is probably half-baked. It is perfectly fine that a solution is not "complete" as long as you know both the pro's and con's of a solution. Programmers need to make tradeoffs every day. Some are acceptable, some are not. Do you know the difference on how to prioritize them? ;-)
It seems to me there are 3 types of programmers ...
1. Unable,
... with respect to learning.
2. Unwilling,
3. Unmotivated, or
As you grow older there are more calcium deposits in your brain which is where the term "fossilized thinking" comes from. You can't help those unable to learn or unwilling. These are where the stereotypes come from.
Now as to the last group ...
They say the mind is like a muscle -- to keep it in top shape you need to exercise it. If old programmers are not motivated to learn then I have to ask why?? Have they mastered THAT much of programming that they have exhausted all the interested topics?? I would argue that there are SO MANY interesting topics in computing that any programmer worth his salt should _easily_ be able to find enough interesting problems to solve as they get older. That's one of the benefits to comp. sci. -- there is always something neat to learn. Nay, the human condition -- you will NEVER stop learning (unless you become close minded.) Everything from bit-twiddling tricks to optimizing multi-threaded-multi-core programming with "Big Data" should keep any reasonable programmer motivated to learn. If not, they they are probably either burnt-out or crappy programmers.
The advantages older programmers have is that they have a much wider experience to draw upon so they don't make the same dumb mistakes over-and-over as the youth. i.e. When you have badly designed languages like Javascript that do NO type-checking on misspelt variables you use better tools to prevent the mistakes from the 80's Basic.
Another advantage is that older programmers don't have to focus on the tediousness of syntax and can focus on the higher level algorithms.
Since you are too dam to lazy to google: brtfs vs zfs ...
http://www.seedsofgenius.net/uncategorized/zfs-vs-btrfs-a-reference
This is a PDF mirror of the scribd link
ZFS: THE LAST WORD IN FILE SYSTEMS by Bill Moore
http://www.cs.utexas.edu/users/dahlin/Classes/GradOS/papers/zfs_lc_preso.pdf
We have these called links. Reading. Try it sometime.
It is not a matter of IF but WHEN. i.e. When is the human race going to grow up and look outside their myopic & arrogant view that they are the most important lifeform on the universe? Oh that's right, they finally have proof.
Contact has _already_ happened. It is just NOT allowed on the global scale - yet.
If I'm wrong I'll be just another idiot ranting that you won't remember. :-)
But if I'm right you'll be more interested in knowing that the limits to knowledge are not artificially limited by Science; there is another path to Knowledge.
Beside, the real interesting question is not "Are we alone?" but "Why the hell do we look so similar??"
1. One size doesn't fit all though.
Most filesystems aside from ZFS sacrifice correctness for the sake of performance.
* For enterprise correctness is more important then performance.
* For home use performance is more important then correctness.
2. You seem to be ignoring history.
As we've gone from 32-bit to 64-bit CPUs filesystems have likewise gone from 32-bit, 64-bit, and 128-bit.
Remember software (and hardware) is about engineering tradeoffs between 2 extremes:
Correct but Slow < - - - and - - - > Fast but Unstable
--
Only Cowards use Censorship.
Please mod parent informative.
One of the retarded things about btrfs is that you can not see how much disk space is being used by each subvolume. How the hell can you have a filesystem and not know how much space is in use or free ??
The design of ZFS is much more wholistic. That is, when we take a step back and look at both the micro and macro we see that we are really trying to solve 3 problems:
* Volume Management
* File System
* Data Integrity
ZFS solves all of these be leveraging knowledge from ALL the layers as one cohesive whole.
https://blogs.oracle.com/bonwick/en_US/entry/rampant_layering_violation
Why RAID is fundamentally broken
https://blogs.oracle.com/bonwick/entry/raid_z
Another interesting doc
http://www.scribd.com/doc/43973847/5/ZFS-Design-Principles
> There is no room for any bugs at all in a filesystem to which you will trust your essential data.
Your ideology is admired except it is not practical :-(
* So you are able to guarantee you are able to write 100% bug free code?
* AND it can deal with hardware failures such as bad memory?
I have a bridge to sell you :-)
1. Your fallacy is assuming Privacy is mutually exclusive with Protection. It is not.
2. This issue has already been discussed to death a thousand times before:
"Sell not virtue to purchase wealth, nor Liberty to purchase power."
Which is better know as:
* Those who would trade a little bit of freedom for temporary safety deserve neither.
* They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
* Those Who Sacrifice Liberty For Security Deserve Neither.
-- http://en.wikiquote.org/wiki/Benjamin_Franklin
> I have yet to see any vaguely credible evidence of any dangers from GMO crops.
Just because YOU are not aware of any does not imply there isn't any.
Until we see 100+ years long term studies WE DON'T KNOW.
When in doubt it would be better to NOT ACT hastily before we permanently cause irrevocable damage. Once the cat is out of the bag it is impossible to put it back in again.
--
Only Cowards use Censorship.
>> Scientists don't make conclusions based on lack of evidence. We need proof they're not harmful to us and the environment. We don't have that proof. .. GMOs 0 deaths with ...
> You cannot prove a negative. What you can prove (and what already has been proven) is that all of the GMO crops are safer
Everyone that has eaten carrots has a 100% fatality rate. Therefore carrots are bad. See, I can abuse stats and provide bullshit arguments based on it too.
This phrase "prove a negative" is incorrect. If there are LONG-TERM studies (40 - 100 years) on the RESULTS of people eating GMO foods then we can make safety decisions based on EVIDENCE. i.e.
* Are people more or less healthy?
* Are there chemicals / toxins / etc that are there when they shouldn't be?
* Are there any effects on birth?
etc.
We don't have 100+ years of study on GMO foods. Man has a annoying habit of fucking everything up in nature. It would be more prudent to ban the commercial use UNTIL we have more complete LONG TERM data on their safety especially when you have corporations that are proven & documented as being dishonest, unethical, and have paid some shill to advocate their propaganda because they ONLY care about corporate greed.
References:
* The World According to Monsanto
* Food Inc.
Finally, some interesting commentary.
It is hard to determine the optimal efficiency of traffic flow without numbers, but let's try anyways ...
a) If an HOV is _added_ to an _existing_ infrastructure, then having it is not taking anything away, but I agree with the assertion that it may not be the most optimal.
The problem we are trying to optimize is: How can we move the most cars (maximize distance) in the least amount of time. i.e. dX/dT. Which looks like a differential equation.
Would it be better instead of having the extra lane be HOV or be a Open lane? I don't know. I would like to see some studies in various high population areas first. Otherwise I think we are all pulling numbers out of our an ass. The technical term is "SWAG": scientific wild assed guess.
b) Likewise I would also like to see the converse data. If an _existing_ lane is _converted_ over then what happens to the traffic efficiency?
> that one clown doing 40 mph doesn't screw up the entire benefit (to drivers) of the HOV lane.
I partially agree with you. The 2+ clowns doing 60 mph instead of the legal 65 mph (or the more realistic 75 mph) in the far left-most two lanes are a MUCH bigger problem then maximizing the HOV lane usage. Those retards introduce standing waves in traffic which are far most destructive to dX/dT.
It is a shame that the Dept. of Motor Vehicles doesn't know shit about standing waves nor teaches people how to help optimize keeping vehicles moving in the traffic flow. One of these days every car will be able to pass it's current speed both forward and backwards to its neighbor's car so that people 5, 10, 20 mins down the road can know about future traffic conditions. i.e. Peer-to-Peer Car Knowledge.
*sigh* Another high ID that can't seem to focus on the _original_ discussion. Way to stay focused on the negative instead of adding something constructive to the dicussion! Thanks for proving my point that 6+ digit ids rarely add any useful signal; mostly useless noise.
Now, to bring this back on-topic:
Where are the studies that show benefits and negatives to HOV lanes?
I'm not interested in anecdotal evidence, hyperbole, nor conjecture; I'm interested in facts about HOV.
Guess people would rather bitch about off-topic non-issues then raise questions in order to get answers and have a healthy, constructive, informative discussion.
--
Unless you grok BOTH the postive AND negative about any system, you do NOT understand it (fully.)
He's got a 6-digit id. He's still relatively young.
The kids these days always rant and rave without any substance. Notice how he didn't provide _any_ stats on HOV lanes. He hasn't pointed out any factual benefits or disadvantages to them.
> for three register specifiers, which take up 15 bits total. Going to 256 registers would blow that up to 24 bits
I appreciate your feedback.
> And it's vital for it to have single cycle access times.
I'm not sure why you are asserting that MUST be single cycle? CPUs in the 80's were not single cycle. Even in today's CPUs there are many instructions that operate on registers that take multiple clock cycles. Would it be nice? Hell yeah. But is it mandatory? Since existing CPUs don't "break" I must conclude "no".
Your analysis is good however there are other options that still may make this feasible:
1. CPUs can be designed for specifying 1, 2, or 3 registers. I wasn't saying one was forced to use a tri-opcode format. But it certainly is _convenient_. :-)
2. Additionally there is a way to specify 3 registers, keep 32-bit code density and still gain 31-bit precision for "Load Immediate". :-)
Reserve the high bit of each opcode to mean:
0 = Immediate
1 = Opcodes
Anytime the Fetch & Decode sees a immediate value it knows that it is supposed to be paired with the previous opcode (or vice versa.) The point is, one doesn't need to stall the pipeline simply because you interleave 32-bit and "effective" 64-bit opcodes.
i.e. Given the pseudo-code:
r3 = r1 / r2;
r4 = r1 % r4
The data stream could be encoded as:
1...xxxx 32-bit opcode LOAD R1
0...abcd 32-bit immediate r1
1...yyyy 32-bit opcode LOAD R2
0...bbbb 32-bit immediate r2
1...zzzz 32-bit opcode R3 = R1 / R2
1...zzzz 32-bit opcode R4 = R1 % R3
> constants are actually a well-studied problem in computer architecture. It's beneficial to include special features to help represent them in the instruction set, but there are good and bad ways of doing that
Actually I'd be very interested in that! Have any links or specific terms to search for?
Thanks for the interesting feedback AC