Assuming Doctors, Lawyers and Engineers all take the same amount of brain power then, of those three, engineers will make the lowest amount of money over their lifetimes.
But, you forget that doctors and lawyers have their own downsides.
Doctors make the most, but they are stuck in school the longest (8 years plus residency), and have very high debt by the time they graduate. They have terrible hours (long shifts, few days off, by-far the worst of the three disciplines mentioned), and they are often on-call, further disrupting their lives.
Wait, did I say that doctors have a LIFE outside work? I guesss I was mistaken.
Lawyers are stuck in school for years longer than most engineers, because they are actually getting their doctorates. They also get stuck with large sums of debt, thanks to all those years of school. When they finally graduate, they find that the average salary is only 100K per year, and that the only way to get the monster salaries is to work your way into a partnership, and take demanding positions (i.e. 2000+ billable hours, which is around 3000+ real hours).
Basically, if you get the mad money, you have no time for life, let alone time to spend that money. I have two lawyers in my family: one makes serious cash, and he's always busy, attached to his blackberry. The other is my sister, and she actually took a high five-figure salary just so she could get a position with sane hours (1400 billable).
Engineers can get jobs with decent pay with nothing but a bachelor's degree. Really, a master's degree is the highest education most engineers will find worthwhile, and this is often paid by their employer. Further, if you are the type to go for the doctorate, most schools will pay for you to attend and teach.
Engineers also tend to have more sane hours; you CAN work 60+ hour weeks in the engineering field, but it is not the norm.
What it comes down to is this: engineering will not pay grandly over the course of your lifetime, but it does not pay badly. Of the three above, it is the best balance of life vs work, and that's why you still get so many graduates.
My school (Lafayette College) has the same thing, but we call it AB Engineering.
Basically, you have two drop-out paths
1. If you drop by your second year, there's the business school at the bottom of the hill. You can count all the math, and apply your core engineering classes as electives.
2. If you drop later, AB Engineering is your savior. Basicaly, you stop taking technical classes, and spend the rest of your college life taking business and social sciences/humanities.
I actually knew two people who took this major. One of them was a lazy bastard who played too much UO; somehow, he hadn't failed all his classes, but the third year of engineering was killing him, so he moved to AB. The other actually started out in the program, which really surprised me.
But in order to fall back to the post, firstly as noted, there are bit fields in C, and you can use them to represent sequences of bits in 90% of the cases where you need to.
Ada has an equivilant with packed types. You can set the 'Size attribute on custom types with bit precision, and you can pack multiple custom types into a record just like bitfields. We use this to read in packed data from hardware all the time.
The only major failing I found was using these for stream IO (file in/out): unless you redefine the stream attributes for the type, Ada will automatically assume that the minimum size of the type is 8 bits, and will resize fields smaller than this. Makes for a lot of fun when trying to figure out why your file format is wrong, or you read in incorrect data.
C has bitwise operators that actually works (compared to Ada), which makes it a lot more suitable for bitmanipulation than Ada.
Oh, hell yes. Bitwise operations in Ada are so clumsy they made me tear my hair out.
C also treat arrays and pointers as the same, and pointers are not checked, and you can cast data and pointers to whatever you want, this is why it is suitable for low level memory manipulation.
I don't consider treating arrays and pointers the same to be a huge benefit; it's more of a kludge. Anyway, you can get the same performance as C pointers by using Ada access types; just make sure your types are aliased.
They know that Intel is delivering 45 nanometer CPU designs. They know that Intel is working on 32 nanometer CPUs, and that there will eventually be 22 nanometer processors, for delivery in 8 years. Each new processor architecture uses less power. So, the problem will solve itself, to some degree.
No. The demand for processing power outstrips the efficiency improvements in process revisions. That's how we got ourselves into this mess in the first place.
Process improvements and new "more efficient" designs are not something new: they've been happening for years, with.35,.25,.18,.13,.09,.065,.045 um process jumps in just the last ten years! And no, there is nothing magical about current process shrinks: every major process shrink since.35 micron has halved the capacitance (and thus power consumption) of chips produced. All this time, our hunger for performance has grown even faster than the process shrinks could provide, which is why we have severe power problems TODAY!
Think about it: if process improvements could have any hope of keeping up with our power demands, then we wouldn't see a high rate of growth in datacenter power consumption. In fact, you'd better hope that the current process shrink rates continue tom improve things, or the problem could balloon overnight.
truthfully only real application for the gpu/cpu hybrid would be in laptop use where they can get away with using lower end gpu chips
You only need so much power for %95 of users. And thanks to the introduction of PCIe, most desktop systems come with an x16 expansion port, even if the chipset has integrated graphics. Further, there's a push from ATI and Nvidia to support switching to the IGP and turning off the discrete chip when you're not playing games, which cuts down on power used when you're at the desktop. Isn't technology great?
And further, there's more out there in the land of IGPs than just crappy Intel. AMD's new 780 chipset actually packs a real HD 3450 core onboard (not cut-down at all), and Nvidia has a new IGP on the horizon that's even faster. Both of these will be more than enough power to run Aeroglass, and you can even run recent games at low settings.
Now, what's the difference between affordably integrating graphics in the chipset and affordably integrating it in the same die as the CPU? Maybe one process revision, tops. And that's the beauty of it: integrated graphics will improve in performance over the years just like performance improves in IGP and discrete chipsets now; it's only a matter of time before ALL users have PCs that come with the power of quad-Crossfire/SLI ultra setups.
Yes, actually what Nvidia fears most is being cut-out of the chipset business. Right now, most PCs ship with an integrated graphics chipset (even more true in the notebook/ultraporatble market). If the GPU is integrated on the CPU die, then Nvidia loses out completely in the integrated graphics chipset market.
They may also lose market share because new APIs besides Direct3D may surface to control these new hybrid processors (think CUDA). If Nvidia is not there on the ground floor, then their own API (CUDA) will not gain traction in the general-purpose stream computing market. While big players like Microsoft may eventually release a standard, this may take years (remember how long DirextX took to "get it right," and how Glide initially stole the show).
I've actually been waiting for Nvidia to buy Via; it's made sense from the moment that AMD announced Fusion and Intel announced similar plans. Nvidia has got to create a hybrid product, and unfortunately for them it's got to be x86-compatible. Right now, they're playing around with an Arm-based hybrid processor setup, but they need to move to x86 if they inten to be taken seriously.
Except for the fact that text compresses well, and most webservers support gzip. I get about 4 to 1 compression, which knocks your 120kB down to reasonable sizes. Even if the webserver doesn't support gzip compression, you can be damned sure the modem will compress the text as it is sent.
I've also been told they do it out of fear of the phone being turned into a remote microphone
It's not out of the range of possibility. What if you accidentally leave your phone on, then accidentally speed-dial someone? You now have a tranmission of audio, a potential security leak.
There's also a fear of re-transmission, i.e. amplification of signals that might otherwise not get outside the closed area. Signals can be picked up locally, and amplified by your cell phone. That's not how it's supposed to work, but it could happen, because your cell phone CAN accept interference (if it is powerful enough). The very same circuits that can transmit to the cell tower can receive signals, and that's what freaks the security nuts out.
(IMHO people driving cars below 30 mpg should be required to pay a pollution tax, to cover the extra costs of cleaning the crap out of the air, so I can BREATHE instead of suffer asthma attacks.)
They do, they're called gas taxes. Drivers pay tax on exactly how much gas they use (and thus, how much they pollute). If you have a more efficient car, you pay less gas tax.
While the taxes do not go directly to cleaning up pollution, they do go toward paying for transportation. This would otherwise come out of the general fund (i.e. everyone paying equally) if they didn't impose gas taxes. Thus, indirectly, these drivers do pay for their pollution, even if pollution cleanup come out of the general fund.
And that's not even getting into tax deductions/credits for hybrids/electrics, which indirectly increase the tax burden for the owners of less efficient vehicles. That money has to come from somewhere, so they increase income/sales taxes to cover the credits, and pass on the "savings" to those who have more efficient vehicles.
Face it, there's already a whole infarstructure to extract additional taxes from owners of inefficient vehicles.
That's certainly a valid point, but I think you are not in the majority with that preference.
Sure he is.
How many people do you know that specifically own a commuter car, in addition to a car for "everything else?" Sure, some families can pull this off, but most single people can't afford the second car, unless they're car nuts who can grab a cheap used car and keep it running nice.
Now, think about it: how many people who actually sacrificed cargo/seating room and performance just to cut down their gas budget are going to be commuting ONLY 35 miles both ways? And then, how many of those commutes are going to just use up 35 miles of range? You have to add additional range to account for detours, traffic jams, acts of god, the need to go to the store or pick up the kids on the way home, etc. 100 miles range is not nearly enough for the average commuter to rest easy, when they find themselves stuck in a 2-hour backup, and Johnny calls and needs to be picked-up from school.
And hell yes, traffic jams eat up more power than unhindered traffic, even for an electric vehicle with regenerative braking. Or do you honestly expcet people to TURN OFF the air conditioner in the summer heat, or turn off the heater in the icy depths of winter? Or turn off the wipers in a rainstorm? Or turn off their headlights at night? Or simply turn off the stereo? All of these suck down power on an electric vehicle, and are an utter necessity for a car to be successful in the USA. If you have to turn these on, your range can drop considerably, and this can happen even if the car isn't moving.
It is much less stressful to own an efficient gasoline commuter car that has 3-times the range of the electric vehicle, and can be refueled at any station in 5 minutes. This is why the gasoline-electric hybrid has made inroads in the country, but electric-only has not. Eventually, plug-in hybrids and improvements in storage may pave the way for electric-only vehicles, but that day is not today.
That is the correct behaviour of the default 'Write (to stream) attribute of a type as defined in:
Oh, sure, it's there. But it's not in a language that somebody still learning Ada can understand. I made this mistake while I was still learning Ada. And, as you can imagine, there's not a lot of people out there who know the inner workings of Ada these days, so I was forced to experiment and learn.
Yes, you're right - that was the wrong way (to some extent). You should have overridden the 'Write and 'Read attributes for the types you were trying to output as shown in Cohen, N. "Ada As A Second Language" (Second Edition) section 16.7.1.
Sure, you can do that for general file output.
For this particular project, that would have made the code too specific; the goal was to make this easily expandable, so programmers could add output files easily as they found they needed more data. With the implementation I came up with, all you had to do to add a new output buffer was make a copy of the package, then add the appropriate type. The rest took care of itself.
And yeah, I did consider using a true generic when designing this, but the annoyance is that Ada forces all generic instances to share local memory (anything not defined by the input parameters to the generic). If you want independence between generics instances, this means you have to have huge declaration blocks for your generics (not pretty or maintainable), or you have to design around the limitations (not possible in my case). Unfortunately, the capability to make local memory independent in Ada generics is an optional feature for compilers.
It's not very difficult in Ada, you can use Unchecked_Conversion (http://en.wikibooks.org/wiki/Ada_Programming/Types#Unchecked_Conversion) if you're desparate. However the point here is that, if you've got into that sort of hole, you've probably done something wrong earlier on!
Or, sometimes you're just forced to pound square pegs into a round hole.
IAAAP (I Am An Ada Programmer)
As you can imagine, we use it on embedded airborne systems, a place that has always been a hotspot for Ada. I could tell you so many instances where Ada has forced me to pound a square peg into am round hole, but this is by-far my favorite:
When I designed the data extraction package for our system, I designed it correctly using Access types to avoid redundant copies, and Ada Stream_IO to output binary data directly into a file. This is how I would have done it in C++, and it should have worked fine on Ada.
Cut to testing of my system, where I was writing data to the files, and discovering that there was far too much data in the output (and the format was wrong).
What happened? Ada, as usual, assumed the programmer was an idiot. We were using packed types (a necessity of the hardware), and instead of just outputting the entire record like it was told, Ada picked-apart the record into individual pieces. Every piece that was smaller than 1 byte, Ada increased the size of the data to 1 byte, and output it to the destination file.
Thanks Ada. Now, instead of nicely compressed bitfields, I have each flag taking up an entire byte of memory, and non-aligned packed types are all increased to a byte in size. The only solution was to do an unchecked conversion to a generic array of bytes, and output that using Stream_IO (the wrong way).
It's never been feasable. People swear it's possble, they drop all sorts of tantalyzing numbers, but the fact that it hasn't yet happened is a testament to the impracticality of the idea.
Basically, it comes down to this: icebergs can last over a year in artic waters, but in 0C waters they last about 90 days, and in 10C waters a few weeks. This will be amplified if you tow it through the water, because moving water will melt the berg much faster than if it were stationary. Combine that with their tendancy to break apart (really, can you afford to chase every little piece that breaks off?), and you can easily lose most of the berg before you get it into port.
According to this video that's almost 10 times farther than a person could walk on a gallon of gasoline... if a person could metabolize gasoline, of course.
Of course, that's why we invented the bicycle. Humans with mechanical advantage are quite competitive, as with a bike we can travel 5 times faster on the same amount of power (vs walking).
I don't imagine you'd need SLI if the boards are working separately. In other words, have GPU1 crunch PROBLEM1, and GPU2 crunch PROBLEM2. There's no conflict, because they both have independent PCIe x16 connections.
What, am I the only one here who can think outside the SLI box? You only need something like SLI if you want to combine the results, or if you have to resolve dependences. And while I'm sure there are ways to use SLI with CUDA, you don't necessarily have to.
I'm sure somebody clever out there in the game design world will make some must-have title that has multiple monitor support.
Yeah, they did this when Matrox released the G400 and brought multiple-monitor gaming to the world. No, it didn't catch on, except for flight simulators.
The fact is, for most games, multiple monitors add very little immersion and questionable utility. Basically, unless your platform makes it standard (like the Nintendo DS), you're not going to see wide support.
You're not asking too much, you're simply over-valuing what 3-year-old tech is capable of. The GeForce 6800 Ultra was the best Nvidia card in existence 3 years ago, and soon, you will be able to purchase the 9500 GT, which will have more performance.
The card features %20-30 more performance than the 8600GT (plenty to top GPUs from 3 years ago), and with a 65nm process, should consume around 30w or less at-load.
I have to agree, I'm seeing less and less use for a higher-resolution screen for home/gaming use.
For games on the desktop, the maximum resolution you have to push (realistically) is 1920x1200 (really, anything larger at 2-3 feet away is overkill), and the maximum resolution you have to push on a television (if you're into that) is 1920x1080. Funny, midrange $150-200 cards can do that today, with high quality, in all games except Crysis.
So yeah, I can see the slowdown in graphics tech coming around. The fact that you can play any modern game in medium settings at 1280x1024 with a $75 add-in card shows us exactly why we're hitting the developmental wall. Most people are happy with our current level of graphics, and the cost of new graphics architectures rises exponentially with every new revision; so, if you don't have the demand, you're not going to rush production on the next-generation of GPU architectures.
Unfortunately, this leaves the %1 of hardcore gamers bitching, and they tend to bitch the loudest, so Nvidia and ATI are trying to placate them with stop-gap SLI solutions.
It's not necessairly a limit of the board design, but a limit to what game engines can be optimized for. Most game engines do not scale well beyond two cards, as can be seen here:
While there are a few key games that get no boost out of 2-way SLI, the vast majority of games do see improvement. 3-way, on the other hand, can actually cause WORSE performance.
It probably has to do with limitations on how the SLI/Crossfire drivers can fake-out the game engine. There are probably limits to how many frames the game engine allows to be in-flight at once, limiting how much performance boost you can get from AFR SLI. And although you can get around game engine limitations with split-screen rendering, this mode needs specific game support, and shows less potential performance increase. Plus, split-screen rendering and has to be selected explicitly in Crossfire (AFR is the default).
It's not much of a stopgap if you many millions of lines of code written against it. Which I expect Adobe have.
Yup. Apple, welcome to Windows's world. Microsoft didn't create and make 32-bit Vista the primary OS just because they were sadistic; they did it because vendors would have a hissy-fit if certain 16 and 32-bit legacies weren't supported.
You can't hope to compete with Windows if you don't offer the same legacy support. Apple has a habit of uprooting and tossing processors and operating systems whenerver they feel like it, and compatibility support is usually very limited. I think, in this case, Adobe is being a lazy, fat beast, but at the same time, Apple is being a pretentious prick that doesn't want to meet in the middle with the needs of developers.
Both companies are acting like children, and in the end, only the consumers will be hurt. Apple will save the money it would have cost to port Carbon to 64-bit, and Adobe will probably get some of their Mac users to convert to Windows just to get more memory support (more software sales). This leaves the Photoshop users willing to stay on OS X stuck with a castrated version (but they will buy it anyway), all because each company was busy being a hardass.
Oh, sure, you can see the overall advantages of an IDEAL fully-digital system. But the fact was, this system had shortcomings: the kind of design compromises and limitations you normally see with the lowest bidder. Imagine a system where you can't easily correct mistakers or go out-of-order because there wasn't enough money for such niceties Imagine instead, jumping through menus just to go back a page). Now throw onto the heap a mix of myriad bugs that may cause partial or complete loss of data, often without any indication to the user. There are tons of real-world examples of this, so why is it so hard to imagine for a custom hardware/software device having such teething problems?
Wireless? Sure, if you can get the infarstructure to be reliable, which is almost impossible out the gate. Even if you use commercial wireless carriers, their coverage is still spottry in many parts of the country.
Eventually, they will make a digital data collection system that works almost as well as it's advertised on paper...but until that point, you have to weigh the disbenefits of using early-revision digital versus paying the cost of staying with paper. Although it is easier to stick with paper for 2010, I expect that paper will be gone by the time the 2020 census rolls around. They just need more time to get more things right.
Although I certainly agree that if somebody is driving right at, or just above, the speed limit, should move to the right lane when possible, I don't quite understand why they would be 'assholes' for staying on the left.
The reason said driver is an asshole is simple: by matching speed with drivers in the right lane, the driver in the left lane is creating an unsafe situation. The left-lane driver is essentially boxing-in the driver in the right lane, giving him one less option if he gets into trouble and needs to avoid an accident. Further, some of these assholes in the left lane not only match speed, but also ride inside the blind spot of the other driver! This means that if that other driver needs to avoid an accident, they may go for the left lane (unknowingly occupied), and hit the asshole.
As a courteous speeder like yourself (I like to speed as long as conditions are good, I don't see any cops, and traffic allows it), you know that safe driving practices are essential. I make it a point to not box people in or drive in blind spots, and I tend to keep a sharp eye out for idiot drivers, because it makes driving safer for me and everyone else. In my book, if you box others in, block the passing lane, and just ignore those around you, then you're a liability and an asshole.
Yeah, here in Maryland, not only are the unmarked interceptors getting impossible to spot, and I've found that an increasing number of speedtraps are using LIDAR, which makes any radar detector utterly useless. The last two times I've gotten pulled over, it's been laser, so there's really no use for detectors these days. Luckily, I'm observant, I'm over 25, and I had a few years between these traffic stops, so I got off with warnings.
I've also noticed they've created revenue-generators like the 40mph limit areas approaching the tunnel and Key Bridge toll booths. Example: the cops sit at the bottom of Key Bridge, hidden amongst the cars, and laser you right as the speed limit drops from 55 to 40. Since most people are going 60-65 anyway, the ticket is guaranteed to be over $100.
Slashdot Mirror
Assuming Doctors, Lawyers and Engineers all take the same amount of brain power then, of those three, engineers will make the lowest amount of money over their lifetimes.
But, you forget that doctors and lawyers have their own downsides.
Doctors make the most, but they are stuck in school the longest (8 years plus residency), and have very high debt by the time they graduate. They have terrible hours (long shifts, few days off, by-far the worst of the three disciplines mentioned), and they are often on-call, further disrupting their lives.
Wait, did I say that doctors have a LIFE outside work? I guesss I was mistaken.
Lawyers are stuck in school for years longer than most engineers, because they are actually getting their doctorates. They also get stuck with large sums of debt, thanks to all those years of school. When they finally graduate, they find that the average salary is only 100K per year, and that the only way to get the monster salaries is to work your way into a partnership, and take demanding positions (i.e. 2000+ billable hours, which is around 3000+ real hours).
Basically, if you get the mad money, you have no time for life, let alone time to spend that money. I have two lawyers in my family: one makes serious cash, and he's always busy, attached to his blackberry. The other is my sister, and she actually took a high five-figure salary just so she could get a position with sane hours (1400 billable).
Engineers can get jobs with decent pay with nothing but a bachelor's degree. Really, a master's degree is the highest education most engineers will find worthwhile, and this is often paid by their employer. Further, if you are the type to go for the doctorate, most schools will pay for you to attend and teach.
Engineers also tend to have more sane hours; you CAN work 60+ hour weeks in the engineering field, but it is not the norm.
What it comes down to is this: engineering will not pay grandly over the course of your lifetime, but it does not pay badly. Of the three above, it is the best balance of life vs work, and that's why you still get so many graduates.
My school (Lafayette College) has the same thing, but we call it AB Engineering.
Basically, you have two drop-out paths
1. If you drop by your second year, there's the business school at the bottom of the hill. You can count all the math, and apply your core engineering classes as electives.
2. If you drop later, AB Engineering is your savior. Basicaly, you stop taking technical classes, and spend the rest of your college life taking business and social sciences/humanities.
I actually knew two people who took this major. One of them was a lazy bastard who played too much UO; somehow, he hadn't failed all his classes, but the third year of engineering was killing him, so he moved to AB. The other actually started out in the program, which really surprised me.
But in order to fall back to the post, firstly as noted, there are bit fields in C, and you can use them to represent sequences of bits in 90% of the cases where you need to.
Ada has an equivilant with packed types. You can set the 'Size attribute on custom types with bit precision, and you can pack multiple custom types into a record just like bitfields. We use this to read in packed data from hardware all the time.
The only major failing I found was using these for stream IO (file in/out): unless you redefine the stream attributes for the type, Ada will automatically assume that the minimum size of the type is 8 bits, and will resize fields smaller than this. Makes for a lot of fun when trying to figure out why your file format is wrong, or you read in incorrect data.
C has bitwise operators that actually works (compared to Ada), which makes it a lot more suitable for bitmanipulation than Ada.
Oh, hell yes. Bitwise operations in Ada are so clumsy they made me tear my hair out.
C also treat arrays and pointers as the same, and pointers are not checked, and you can cast data and pointers to whatever you want, this is why it is suitable for low level memory manipulation.
I don't consider treating arrays and pointers the same to be a huge benefit; it's more of a kludge. Anyway, you can get the same performance as C pointers by using Ada access types; just make sure your types are aliased.
They know that Intel is delivering 45 nanometer CPU designs. They know that Intel is working on 32 nanometer CPUs, and that there will eventually be 22 nanometer processors, for delivery in 8 years. Each new processor architecture uses less power. So, the problem will solve itself, to some degree.
.35, .25, .18, .13, .09, .065, .045 um process jumps in just the last ten years! And no, there is nothing magical about current process shrinks: every major process shrink since .35 micron has halved the capacitance (and thus power consumption) of chips produced. All this time, our hunger for performance has grown even faster than the process shrinks could provide, which is why we have severe power problems TODAY!
No. The demand for processing power outstrips the efficiency improvements in process revisions. That's how we got ourselves into this mess in the first place.
Process improvements and new "more efficient" designs are not something new: they've been happening for years, with
Think about it: if process improvements could have any hope of keeping up with our power demands, then we wouldn't see a high rate of growth in datacenter power consumption. In fact, you'd better hope that the current process shrink rates continue tom improve things, or the problem could balloon overnight.
truthfully only real application for the gpu/cpu hybrid would be in laptop use where they can get away with using lower end gpu chips
You only need so much power for %95 of users. And thanks to the introduction of PCIe, most desktop systems come with an x16 expansion port, even if the chipset has integrated graphics. Further, there's a push from ATI and Nvidia to support switching to the IGP and turning off the discrete chip when you're not playing games, which cuts down on power used when you're at the desktop. Isn't technology great?
And further, there's more out there in the land of IGPs than just crappy Intel. AMD's new 780 chipset actually packs a real HD 3450 core onboard (not cut-down at all), and Nvidia has a new IGP on the horizon that's even faster. Both of these will be more than enough power to run Aeroglass, and you can even run recent games at low settings.
Now, what's the difference between affordably integrating graphics in the chipset and affordably integrating it in the same die as the CPU? Maybe one process revision, tops. And that's the beauty of it: integrated graphics will improve in performance over the years just like performance improves in IGP and discrete chipsets now; it's only a matter of time before ALL users have PCs that come with the power of quad-Crossfire/SLI ultra setups.
Yes, actually what Nvidia fears most is being cut-out of the chipset business. Right now, most PCs ship with an integrated graphics chipset (even more true in the notebook/ultraporatble market). If the GPU is integrated on the CPU die, then Nvidia loses out completely in the integrated graphics chipset market.
They may also lose market share because new APIs besides Direct3D may surface to control these new hybrid processors (think CUDA). If Nvidia is not there on the ground floor, then their own API (CUDA) will not gain traction in the general-purpose stream computing market. While big players like Microsoft may eventually release a standard, this may take years (remember how long DirextX took to "get it right," and how Glide initially stole the show).
I've actually been waiting for Nvidia to buy Via; it's made sense from the moment that AMD announced Fusion and Intel announced similar plans. Nvidia has got to create a hybrid product, and unfortunately for them it's got to be x86-compatible. Right now, they're playing around with an Arm-based hybrid processor setup, but they need to move to x86 if they inten to be taken seriously.
Except for the fact that text compresses well, and most webservers support gzip. I get about 4 to 1 compression, which knocks your 120kB down to reasonable sizes. Even if the webserver doesn't support gzip compression, you can be damned sure the modem will compress the text as it is sent.
I've also been told they do it out of fear of the phone being turned into a remote microphone
It's not out of the range of possibility. What if you accidentally leave your phone on, then accidentally speed-dial someone? You now have a tranmission of audio, a potential security leak.
There's also a fear of re-transmission, i.e. amplification of signals that might otherwise not get outside the closed area. Signals can be picked up locally, and amplified by your cell phone. That's not how it's supposed to work, but it could happen, because your cell phone CAN accept interference (if it is powerful enough). The very same circuits that can transmit to the cell tower can receive signals, and that's what freaks the security nuts out.
(IMHO people driving cars below 30 mpg should be required to pay a pollution tax, to cover the extra costs of cleaning the crap out of the air, so I can BREATHE instead of suffer asthma attacks.)
They do, they're called gas taxes. Drivers pay tax on exactly how much gas they use (and thus, how much they pollute). If you have a more efficient car, you pay less gas tax.
While the taxes do not go directly to cleaning up pollution, they do go toward paying for transportation. This would otherwise come out of the general fund (i.e. everyone paying equally) if they didn't impose gas taxes. Thus, indirectly, these drivers do pay for their pollution, even if pollution cleanup come out of the general fund.
And that's not even getting into tax deductions/credits for hybrids/electrics, which indirectly increase the tax burden for the owners of less efficient vehicles. That money has to come from somewhere, so they increase income/sales taxes to cover the credits, and pass on the "savings" to those who have more efficient vehicles.
Face it, there's already a whole infarstructure to extract additional taxes from owners of inefficient vehicles.
Transistor current is proportional to Width/Length. A wider transistor produces a bigger current for the same input voltage (basically, an amplifier).
Transistor load (capacitance) is determined by the area of the gate, or Width * Length.
That's certainly a valid point, but I think you are not in the majority with that preference.
Sure he is.
How many people do you know that specifically own a commuter car, in addition to a car for "everything else?" Sure, some families can pull this off, but most single people can't afford the second car, unless they're car nuts who can grab a cheap used car and keep it running nice.
Now, think about it: how many people who actually sacrificed cargo/seating room and performance just to cut down their gas budget are going to be commuting ONLY 35 miles both ways? And then, how many of those commutes are going to just use up 35 miles of range? You have to add additional range to account for detours, traffic jams, acts of god, the need to go to the store or pick up the kids on the way home, etc. 100 miles range is not nearly enough for the average commuter to rest easy, when they find themselves stuck in a 2-hour backup, and Johnny calls and needs to be picked-up from school.
And hell yes, traffic jams eat up more power than unhindered traffic, even for an electric vehicle with regenerative braking. Or do you honestly expcet people to TURN OFF the air conditioner in the summer heat, or turn off the heater in the icy depths of winter? Or turn off the wipers in a rainstorm? Or turn off their headlights at night? Or simply turn off the stereo? All of these suck down power on an electric vehicle, and are an utter necessity for a car to be successful in the USA. If you have to turn these on, your range can drop considerably, and this can happen even if the car isn't moving.
It is much less stressful to own an efficient gasoline commuter car that has 3-times the range of the electric vehicle, and can be refueled at any station in 5 minutes. This is why the gasoline-electric hybrid has made inroads in the country, but electric-only has not. Eventually, plug-in hybrids and improvements in storage may pave the way for electric-only vehicles, but that day is not today.
That is the correct behaviour of the default 'Write (to stream) attribute of a type as defined in:
Oh, sure, it's there. But it's not in a language that somebody still learning Ada can understand. I made this mistake while I was still learning Ada. And, as you can imagine, there's not a lot of people out there who know the inner workings of Ada these days, so I was forced to experiment and learn.
Yes, you're right - that was the wrong way (to some extent). You should have overridden the 'Write and 'Read attributes for the types you were trying to output as shown in Cohen, N. "Ada As A Second Language" (Second Edition) section 16.7.1.
Sure, you can do that for general file output.
For this particular project, that would have made the code too specific; the goal was to make this easily expandable, so programmers could add output files easily as they found they needed more data. With the implementation I came up with, all you had to do to add a new output buffer was make a copy of the package, then add the appropriate type. The rest took care of itself.
And yeah, I did consider using a true generic when designing this, but the annoyance is that Ada forces all generic instances to share local memory (anything not defined by the input parameters to the generic). If you want independence between generics instances, this means you have to have huge declaration blocks for your generics (not pretty or maintainable), or you have to design around the limitations (not possible in my case). Unfortunately, the capability to make local memory independent in Ada generics is an optional feature for compilers.
It's not very difficult in Ada, you can use Unchecked_Conversion (http://en.wikibooks.org/wiki/Ada_Programming/Types#Unchecked_Conversion) if you're desparate. However the point here is that, if you've got into that sort of hole, you've probably done something wrong earlier on!
Or, sometimes you're just forced to pound square pegs into a round hole.
IAAAP (I Am An Ada Programmer)
As you can imagine, we use it on embedded airborne systems, a place that has always been a hotspot for Ada. I could tell you so many instances where Ada has forced me to pound a square peg into am round hole, but this is by-far my favorite:
When I designed the data extraction package for our system, I designed it correctly using Access types to avoid redundant copies, and Ada Stream_IO to output binary data directly into a file. This is how I would have done it in C++, and it should have worked fine on Ada.
Cut to testing of my system, where I was writing data to the files, and discovering that there was far too much data in the output (and the format was wrong).
What happened? Ada, as usual, assumed the programmer was an idiot. We were using packed types (a necessity of the hardware), and instead of just outputting the entire record like it was told, Ada picked-apart the record into individual pieces. Every piece that was smaller than 1 byte, Ada increased the size of the data to 1 byte, and output it to the destination file.
Thanks Ada. Now, instead of nicely compressed bitfields, I have each flag taking up an entire byte of memory, and non-aligned packed types are all increased to a byte in size. The only solution was to do an unchecked conversion to a generic array of bytes, and output that using Stream_IO (the wrong way).
It's never been feasable. People swear it's possble, they drop all sorts of tantalyzing numbers, but the fact that it hasn't yet happened is a testament to the impracticality of the idea.
Basically, it comes down to this: icebergs can last over a year in artic waters, but in 0C waters they last about 90 days, and in 10C waters a few weeks. This will be amplified if you tow it through the water, because moving water will melt the berg much faster than if it were stationary. Combine that with their tendancy to break apart (really, can you afford to chase every little piece that breaks off?), and you can easily lose most of the berg before you get it into port.
See here:
http://www.wordplay.com/tourism/icebergs/
According to this video that's almost 10 times farther than a person could walk on a gallon of gasoline... if a person could metabolize gasoline, of course.
Of course, that's why we invented the bicycle. Humans with mechanical advantage are quite competitive, as with a bike we can travel 5 times faster on the same amount of power (vs walking).
That's not 10x as efficient, but it is close.
I don't imagine you'd need SLI if the boards are working separately. In other words, have GPU1 crunch PROBLEM1, and GPU2 crunch PROBLEM2. There's no conflict, because they both have independent PCIe x16 connections.
What, am I the only one here who can think outside the SLI box? You only need something like SLI if you want to combine the results, or if you have to resolve dependences. And while I'm sure there are ways to use SLI with CUDA, you don't necessarily have to.
I'm sure somebody clever out there in the game design world will make some must-have title that has multiple monitor support.
Yeah, they did this when Matrox released the G400 and brought multiple-monitor gaming to the world. No, it didn't catch on, except for flight simulators.
The fact is, for most games, multiple monitors add very little immersion and questionable utility. Basically, unless your platform makes it standard (like the Nintendo DS), you're not going to see wide support.
You're not asking too much, you're simply over-valuing what 3-year-old tech is capable of. The GeForce 6800 Ultra was the best Nvidia card in existence 3 years ago, and soon, you will be able to purchase the 9500 GT, which will have more performance.
The card features %20-30 more performance than the 8600GT (plenty to top GPUs from 3 years ago), and with a 65nm process, should consume around 30w or less at-load.
I have to agree, I'm seeing less and less use for a higher-resolution screen for home/gaming use.
For games on the desktop, the maximum resolution you have to push (realistically) is 1920x1200 (really, anything larger at 2-3 feet away is overkill), and the maximum resolution you have to push on a television (if you're into that) is 1920x1080. Funny, midrange $150-200 cards can do that today, with high quality, in all games except Crysis.
So yeah, I can see the slowdown in graphics tech coming around. The fact that you can play any modern game in medium settings at 1280x1024 with a $75 add-in card shows us exactly why we're hitting the developmental wall. Most people are happy with our current level of graphics, and the cost of new graphics architectures rises exponentially with every new revision; so, if you don't have the demand, you're not going to rush production on the next-generation of GPU architectures.
Unfortunately, this leaves the %1 of hardcore gamers bitching, and they tend to bitch the loudest, so Nvidia and ATI are trying to placate them with stop-gap SLI solutions.
It's not necessairly a limit of the board design, but a limit to what game engines can be optimized for. Most game engines do not scale well beyond two cards, as can be seen here:
http://www.xbitlabs.com/articles/video/display/zotac-9800gx2.html
While there are a few key games that get no boost out of 2-way SLI, the vast majority of games do see improvement. 3-way, on the other hand, can actually cause WORSE performance.
It probably has to do with limitations on how the SLI/Crossfire drivers can fake-out the game engine. There are probably limits to how many frames the game engine allows to be in-flight at once, limiting how much performance boost you can get from AFR SLI. And although you can get around game engine limitations with split-screen rendering, this mode needs specific game support, and shows less potential performance increase. Plus, split-screen rendering and has to be selected explicitly in Crossfire (AFR is the default).
I feel obligated to explain the above joke, because nobody with mod points got it in over a day of posting.
Without ab, I'd just be normal.
ab-normal?
IT'S FUNNY, LAUGH!
It's not much of a stopgap if you many millions of lines of code written against it. Which I expect Adobe have.
Yup. Apple, welcome to Windows's world. Microsoft didn't create and make 32-bit Vista the primary OS just because they were sadistic; they did it because vendors would have a hissy-fit if certain 16 and 32-bit legacies weren't supported.
You can't hope to compete with Windows if you don't offer the same legacy support. Apple has a habit of uprooting and tossing processors and operating systems whenerver they feel like it, and compatibility support is usually very limited. I think, in this case, Adobe is being a lazy, fat beast, but at the same time, Apple is being a pretentious prick that doesn't want to meet in the middle with the needs of developers.
Both companies are acting like children, and in the end, only the consumers will be hurt. Apple will save the money it would have cost to port Carbon to 64-bit, and Adobe will probably get some of their Mac users to convert to Windows just to get more memory support (more software sales). This leaves the Photoshop users willing to stay on OS X stuck with a castrated version (but they will buy it anyway), all because each company was busy being a hardass.
Oh, sure, you can see the overall advantages of an IDEAL fully-digital system. But the fact was, this system had shortcomings: the kind of design compromises and limitations you normally see with the lowest bidder. Imagine a system where you can't easily correct mistakers or go out-of-order because there wasn't enough money for such niceties Imagine instead, jumping through menus just to go back a page). Now throw onto the heap a mix of myriad bugs that may cause partial or complete loss of data, often without any indication to the user. There are tons of real-world examples of this, so why is it so hard to imagine for a custom hardware/software device having such teething problems?
Wireless? Sure, if you can get the infarstructure to be reliable, which is almost impossible out the gate. Even if you use commercial wireless carriers, their coverage is still spottry in many parts of the country.
Eventually, they will make a digital data collection system that works almost as well as it's advertised on paper...but until that point, you have to weigh the disbenefits of using early-revision digital versus paying the cost of staying with paper. Although it is easier to stick with paper for 2010, I expect that paper will be gone by the time the 2020 census rolls around. They just need more time to get more things right.
Although I certainly agree that if somebody is driving right at, or just above, the speed limit, should move to the right lane when possible, I don't quite understand why they would be 'assholes' for staying on the left.
The reason said driver is an asshole is simple: by matching speed with drivers in the right lane, the driver in the left lane is creating an unsafe situation. The left-lane driver is essentially boxing-in the driver in the right lane, giving him one less option if he gets into trouble and needs to avoid an accident. Further, some of these assholes in the left lane not only match speed, but also ride inside the blind spot of the other driver! This means that if that other driver needs to avoid an accident, they may go for the left lane (unknowingly occupied), and hit the asshole.
As a courteous speeder like yourself (I like to speed as long as conditions are good, I don't see any cops, and traffic allows it), you know that safe driving practices are essential. I make it a point to not box people in or drive in blind spots, and I tend to keep a sharp eye out for idiot drivers, because it makes driving safer for me and everyone else. In my book, if you box others in, block the passing lane, and just ignore those around you, then you're a liability and an asshole.
Yeah, here in Maryland, not only are the unmarked interceptors getting impossible to spot, and I've found that an increasing number of speedtraps are using LIDAR, which makes any radar detector utterly useless. The last two times I've gotten pulled over, it's been laser, so there's really no use for detectors these days. Luckily, I'm observant, I'm over 25, and I had a few years between these traffic stops, so I got off with warnings.
I've also noticed they've created revenue-generators like the 40mph limit areas approaching the tunnel and Key Bridge toll booths. Example: the cops sit at the bottom of Key Bridge, hidden amongst the cars, and laser you right as the speed limit drops from 55 to 40. Since most people are going 60-65 anyway, the ticket is guaranteed to be over $100.