So many of my books only work on certain platforms :|

I can't read a bunch of my books on my glorious 4k screen because Amazon's treating Windows 8 like a second class citizen. Peter Thiel's new book? Nope. Half my machine learning books (eg Blondie24?) Nope. Most of my typesetting books? Nope.

Even stuff that works on Windows 7, or on Windows 8 Phone, ffs.

Hasn't made mine hurt.

You realize, of course, that a 26" 1920x1080 monitor is only 85 DPI, so the same font size (in pixels) on a 26" 1920x1080 monitor would actually look about 40% larger. And, you'd get more text on the screen to boot.

1280x720 at 120 DPI makes for a small screen: 10.7" x 6", which is approx 12" diagonal. Do you do all your coding on a subnotebook or MacBook Air or something?

Well, they don't magically get cheaper to build just by building more. They get cheaper to build as the manufacturer refines the process, improves the technology, and scales the production lines to amortize the fixed costs of a production facility over a larger number of vehicles. That is, it takes work to make them cheaper, above and beyond just making more.

As long as there's sufficient demand, producers will have enough reason to scale up the production and work to bring the production cost down. Eventually, if all goes well, this begins a virtuous cycle where decreased price increases demand, and increased demand drives further cost reduction and innovation.

This works great if there's enough demand to kick-start the process. Unfortunately, the price of EVs today is too high to drive sufficient demand. Hence the carrot-and-stick incentives to try to jumpstart the virtuous cycle. On the carrot side are tax breaks and government subsidies / loan guarantees. On the stick side are fleet-wide fuel economy standards, price caps and quotas.

Right now, it seems as if most traditional auto manufacturers treat their electric cars either as halo cars, or as tasks they're required to do by law/regulation/whatever but would rather not. I doubt anyone at GM is staking the quarterly numbers on Chevy Volt sales, for example, but it doesn't stop them advertising it. The only competition at this point, though, is positioning, posturing and establishing a brand. That is, competition on the marketing front. The market's still too small to have meaningful competition driving the product development. At least, that's how it seems to me.

Eventually they'll figure out how to bring the costs down. Meanwhile, the early adopters hopefully help build interest and therefore demand in the future. When that happens, I'd expect the real competition to start. You'll see Toyota or GM or someone get into the mega-battery business, like Tesla is currently. Or some other major, bold move like that.

In the meantime, the carrot-and-stick will push both the supply and demand curves to the right, elevating the total units shipped to a modest number until the market can sustain itself.

Toshiba is not legally required to honour OCZ's warranties

Who cares? If you buy a company that performs fraud, admit that the fraud happened, and refuse to make right, it is legitimate for the victim to warn other people away.

you can file a complaint with the state attorneys generals office allege fraud

Not worth my time. It's far more cathartic, besides, to steer tens of thousands of potential customers away with public recitation.

There was none. They simply refused.

My RevoDrive failed in three weeks of light use, and they refused to honor the warranty.

Toshiba also refuses to honor the warranty, despite that they admit that the purchase was real and that the existing warranty was not honored, and despite that I am a standing Toshiba customer.

Therefore nothing has changed, and you do not want a RevoDrive.

Yikes. And you think *he's* dumb?

Ah, your one data point throws off his entire asinine argument! (Seriously, the OP is a moron, but I can't find anywhere in his drivel that he stated only boys can have ADHD.)

Ugh. The only thing worse than lectures are questions from the audience. Well, actually, I have no problems with questions per se, but anybody who interrupts with a question that is going to be answered within the hour as part of the material, or asks a question that was already answered should be subject to some kind of punishment.

i did give a proviso for run-time alias checks in my comment above. Our compiler will also generate a run-time check for that as well, with a small codesize and runtime cycle penalty.. The FORTRAN equivalent doesn't need the alias check.

I'd expect ICC to be very aggressive, given that Intel has one of (if not the) largest paid, full-time compiler team in the world.

So how about all of FORTRAN's other nifty features, such as array slices? To get the same functionality in C / C++, you have to put explicit strides and bounds everywhere, and sometimes checks to reverse loop directions. In FORTRAN, you can write things like "A(1:100,1:200:2) = B(101:300:2,51:150)", and the compiler is free to choose the best way to do it.

In C / C++, you leave it to the programmer to dictate the loop explicitly and hope the compiler can figure out what you're doing. In my experience, real world programmers get unusually creative with this task, creating awful code. If you write clearly enough and pay enough attention to compiler vectorization reports or other feedback, maybe the compiler + user eventually figures it out. Realistically, most programmers aren't that sophisticated. And even among the ones who are, not all have the time or inclination.

Looking back to my array slice example: Now take those slices across function call boundaries in both languages and see how much work the programmer has to do in each language...

My point is, the more work the programmer has to do to help the compiler succeed, the more evidence it's a poor fit for the problem domain. FORTRAN can make it easier for compiler writers because they start with a higher level specification of what the programmer is trying to achieve. FORTRAN also makes it easier for programmers because they stop at that higher level specification of what they're trying to achieve.

I'd argue that if you're programming in processor-specific intrinsics, you're not really programming in C++ any more. Standard C and C++ semantics for pointers and arrays really get in the way of autovectorization. So, you have to go to language extensions and kludges (like C99's restrict keyword) to throw the compiler a bone.

Sure, tricks such as whole-program analysis and run-time alias tests can help the compiler find the guarantees it needs to have in order to vectorize. The fact of the matter (and I heard this straight from the mouths of my employer's vectorizing compiler team members) is that stock FORTRAN is simply much friendlier than stock C/C++ for this due to those semantic differences.

Our compiler will autovectorize C code if you pass it enough hints such as minimum loop trip counts, pointer alignment, pointer aliasing guarantees (aka. restrict) and so forth. Even then, there are limits to what it can do. We offer processor specific intrinsics so you can vectorize the code yourself.

Once you start coding in vector intrinsics, you're taking the vectorization out of the compiler's hands and doing it yourself. Each of those intrinsics usually maps directly to an instruction or small sequence of instructions, so there's little left for the compiler to figure out. The compiler then just schedules and register-allocates the code, and handles the non-vector bits around the edges. Sure, you still compile with the C++ compiler, but the C++ compiler is no longer providing the vectorization: You are.

I wasn't actually thinking of DoS'ing, but I guess that's actually a valid concern. If a particular write pattern could crap a server, then you may have to worry about a user doing that to your server. I was just putting my "DV engineer" hat on, and trying to think of how I'd break an SSD in the minimum number of writes. It's the kind of analysis I'd hope the engineers that come up with lifetime specs use to give a bulletproof lifetime spec. For example, X years at YY MB/day even if you're writing like an a**hole. ;-)

I don't have a formalized attack against any particular drive, manufacturer or filesystem.

For a multi-user system, just a thought: Could you address it with quotas? If a given user can't write to more than X% of the filesystem, you can bound the "badness" of their behavior.