tryp

The density of helium is less than 1/7 of the density of nitrogen, which is a good approximation for air.

Two ways that this is helpful come to mind:

1. Aerodynamic effects like drag and vorticity are largely governed by the Reynolds Number, which holding all else constant, varies linearly with density. Changing the density of the fluid can drastically change the aerodynamic situation. See http://www.grc.nasa.gov/WWW/k-12/airplane/dragsphere.html for an interesting and accessible example.

2. "Flow-induced vibration" is caused by the swirling gases crashing like stormy seas, making platters vibrate and heads flutter. Switching to helium cuts the momentum in these turbulent flows to a seventh of what they would be with air.

I did a quick skim of the source for xxHash and CityHash. They appear to rely heavily on 32- and 64-bit multiply operations, and are likely "fast" to the extent that these operations are vectorized. The benchmarks I noticed are all run on recent x86_64 processors with big vector units and caches.

It would be interesting to see how they stack up on other platforms like ARM with and without NEON, PPC with and without Altivec, and MIPS. Without that data, the algorithms look pretty tailored for SSE3, and so I'd hesitate to build them into any application or protocol that needs to be portable or implemented in embedded devices.

The "solder RAM into place" step is handled by the pick-and-place machine at board manufacture time. Human hands are required only to load the machine.

Soldering DRAMs to the board saves height and improves ruggedness. It can also improve memory power a tiny bit because you can dial down the signal drive strength and dial up the termination impedance since you don't have reflections at the socket connector. If you only have 1 rank, you can also improve memory latency by maybe a cycle by virtue of not having to accommodate parts at different distances from the memory controller. These additional benefits assume that Apple is one of the half-dozen or so companies with whom Intel is willing to open their memory controller documentation.

The counter-intuitive thing to me about using memory-down (at scale orders of magnitude smaller than Apple) is that it can end up being way more expensive over the lifetime of the product. Module vendors can constantly shop and swap between DRAM manufacturers in order to lower their costs and module competition is fierce.

I meant this more as a data point for realistic mental comparison to an ASIC, or anyone thinking they might use one. It's cool that it's achievable, and saying "This (big-n) gate count part is available today!" is nice and gee-whizzy for the press release and trade mags, but divorced from it's cost doesn't mean much to someone who would put it to work, as I'd expect at least a few here on HN to be.

High-end Virtex 4 parts from 2004 still cost over $10k. These aren't the devices you design into products unless your market is low volume, high margin, and long life-cycle. This is the part you buy to prototype your own ASIC design.

Bear in mind that a the current generation of these, the Virtex 6, starts at about $800 for the smallest parts and I believe goes well over $20k for the larger ones. Expect the Virtex 7 to be priced in this ballpark.

edit: I was off by an order of magnitude on the high end. $2k -> $20k

Many embedded compilers and assemblers are terribly buggy. Having worked with dozens, my impression is that the compilers targeting 8-bit microcontrollers are generally of similar quality to 80's x86 compilers. Emission of incorrect assembly given correct code is rare, but optimizations are incredibly weak and the compilers segfault relatively often.

Some of the DSP tool suites have solid compilers that optimize insightfully for their target architecture but whose in-circuit debuggers are tied to flaky IDEs. I'm currently working with an XDP debugger on a Sandy Bridge board that requires the debugger software to be restarted nearly hourly, often corrupting the project file requiring me to enter the memory map again.

Lately I've been thrilled to spec in ARM micros because I can just use GCC, an el-cheapo universal USB JTAG adapter through OpenOCD, and expect everything to work.

Perhaps not for you and your colleagues, but for the folks at the state department charged with enforcement, it often seems to depend on their personal interpretation on a given day.

I think your example here undermines your point. There's not much understanding to be had of the (roman/english) alphabet. You memorize 26 characters as a foundation from which to build words. It's essentially an arbitrary set without underlying logic.

A better example to express your point would be multiplication tables. Why memorize a list of multiplicands and their products rather than learn what multiplication means so that you can generate them on the fly and only memorize as a by-product of common use?

This looks very interesting, but the it's a bit difficult to figure out what it actually is from the website. My impression is that it's like a more featureful take on Unison ("two-way rsync" iirc) with a central server to facilitate NAT traversal.

I suppose they probably haven't figured out their eventual pricing model, but I'd certainly pay a few bucks a month just for coordinating NAT traversal, papering over dynamic IPs and a web interface to set sync policy. For the most part, when my computers are sync'd peer-to-peer, I really don't need or want a copy of my data in the cloud -- my boxes _are_ the cloud. That means that their typical incremental cost per user would be practically zero.

Except now your fonts are rendered like trash because the subpixel rendering and hinting assumes each RGB pixel triplet is in a horizontal line.

I don't know about juniper specifically but most multiport routers are built on packet processing asics with content addressable storage in local ram and built-in macs for each port. When a packet is encountered that requires more complex interaction than the asic can handle it's kicked up to a CPU for processing.

It's _textbook_ HR. You don't want your staff to hate their new manager because their first day was spent handing out pink slips. You make the old manager carry out the reduction, then you get to fire the bad guy.

I'll agree that helvetica looks nicer, but I don't think all the iPhone style gloss and huge spacing looks /better/. Looking at those side-by-sides and knowing that the iPhone versions came first just makes me think that the android versions could be much more information-dense and interactive than they are if they hadn't been limited by the preconceptions of what the existing iPhone version does.

If passing the test requires some specific skill or knowledge then passing the tests demonstrates that one possesses that skill or knowledge.

Right. Just plug it into a usb slot.

I found that adopting the native idioms meant never having to notice the 1- based indexing. Everything is a hash table, and if you find yourself using literal numeric keys, there's probably a nicer way to do it.

The lua users wiki is full of interesting ideas for tackling the basics in ways that leverage lua's simple flexibility.

AMD has a decent share of the current 'Wintel' market. In the recent past IDT, cyrix and transmeta also dabbled in x86 processors.

While it's certainly true that android is happy to run on mips, there is currently a Renaissance of arm-based SOCs with interesting silicon coming from freescale, ti, marvell, phillips, qualcom, and samsung to name just a few. Most of these have thier own combination of differentiators like video codecs, signal processing cores, and analog interfaces.

I see mips running mostly in set top boxes that use the discreet codec/drm devices and routers with external 802.11 radios and switches, and some network-centric processors... but there doesn't seem to be nearly the level of diversity present in the arm ecosystem lately.

I hope that android's architecture agnosticism allows more payoff on investments in other interesting architectures like mips, sh, and openrisc.

It would be much easier to read the NAND IC's than it is to read a magnetic disk out of a hard drive, but you'd need to figure out the block format the drive used in order to reconstruct your files.

I think this is an area where legacy support is really holding us back. I'd love to see us get to the point where we can just have a simple NAND controller attached to the PCIe bus. But doing that requires a flash-aware filesystem like UBIFS, and if you want to boot from it, bootloaders/BIOS that know how to read it.

We're currently stuck with PCIe->SATA controller->SATA attached NAND controller devices that implement their own wear leveling and bad-block management with degree of effectiveness widely varying among manufacturer's implementations. We have to use post-hoc benchmark results to attempt to reverse-engineer the the performance/price/longevity tradeoffs that were baked into the device.

I suspect that no mass-market ASIC company will be willing to get this on the market until Microsoft ships an OS with a native NAND controller driver and flash-aware filesystem and a system OEM contracts with their BIOS vendor to allow booting from the thing.

I'm generally frustrated by articles on this site - and this one is no exception. It seems like there's some juicy rumor-mill news there, but the writing is so poor that it takes a great deal of effort to extract it. A conversational style can be fun when it employs good grammar and appropriate idioms. These articles always leave me wondering whether I just read something interesting or simply incorrect.

Saving trees is great, but think of all the dinosaurs that died to make the DVDs.