Slashdot Mirror
Intel and Micron Unveil 128Gb NAND Chip
ScuttleMonkey writes "A joint venture between Intel and Micron has given rise to a new 128 Gigabit die. While production wont start until next year, this little beauty sets new bars for capacity, speed, and endurance. 'Die shrinks also tend to reduce endurance, with old 65nm MLC flash being rated at 5,000-10,000 erase cycles, but that number dropping to 3,000-5,000 for 25nm MLC flash. However, IMFT is claiming that the shrink to 20nm has not caused any corresponding reduction in endurance. Its 20nm flash uses a Hi-K/metal gate design which allows it to make transistors that are smaller but no less robust. IMFT is claiming that this use of Hi-K/metal gate is a first for NAND flash production.'"
I love SSDs, especially for development work. Nothing like having a dev VM per client each on their own little SSD isolated from your non-work related default operating system. But SSD's are dangerous...
SSD's are like crack to bad applications. The magically make them feel better, while masking the underlying problem. I'm worried what the future is going to hold when the average desktop comes with an SSD drive. Already I've already seem some development companies demo financial software on striped SSD's as if that's what everyone runs these days. I guess it's no difference then an abundance of RAM and an abundance of CPU power. < Insert in my day rant here >
-Malakai
A Dragon Lives in my Garage
Well, that's the problem, isn't it? Lazy programmers aren't writing efficient code, they're just relying on Moore's Law to push them through. Of course, I don't think the average consumers understand much about efficiency, seeing as eyecandy is so popular, even a selling point.
This moralistic spin ("lazy" programmers) is absurd. The tradeoff between development cost and hardware requirements is obviously affected by cheaper yet higher-spec hardware. If you want to run WordPerfect for DOS at insane speeds on modern hardware, go right ahead. That piece of that software cost $495 in 1983 (cite) and was written in assembly language for speed. (I hope the connection there is not lost on anybody).
There are some of us who are quite proficient with assembly language. We also had some very sloppy compilers back then, so the two went hand-in-hand.
Back then, I would build a first prototype in straight C (or whatever), then identify the bottlenecks and rewrite those functions in assembly. Heck, in school I wrote a few QBasic games/apps that linked in some assembly calls. Sometimes I'd get cocky and copy the assembled code directly into a QBasic variable, then execute it. For common stuff like blits and mouse calls, I could type those opcodes from memory. You wouldn't think a QB game could handle 3D graphics as 320x200 on a 386, with sound effects and digital (MOD) music, but with a modest application of hand-tuned code, you can write the script-like glue in whatever language you want with only a minimal impact on final performance.
I'm not saying we need to write all apps in raw assembly, that's absurd. We rarely did that back in the day, except for extreme situations and bragging rights. Today's compilers seem to do a good-enough job, but the faster they get, the more our so-called developers push into truly wasteful practices like nested script interpreters - most PHP and Ruby frameworks fall into that category. Do we really need 16-core machines with 48gb of Ram to push a few pages of text ? Not if we were writing actual computer code, and not this navel-gazing techno poetry that's more for humans than machines.
-Billco, Fnarg.com