Slashdot Mirror

Two words: Tick Tock.

Intel's development model is Tick (die shrink), Tock (new features). It's been this way for many years. Honestly, I'm not sure why you expected a Tick to have any new features. They did call Ivy Bridge a "tick plus," but even then I wouldn't expect any major overhaul in features or performance. Tick is a manufacturing process improvement, not an architecture improvement.

As far as heat packaging, I believe others have covered that sufficiently.

Taiwan is to circuitry what Japan was to radio technology. http://www.intel.com/jobs/china/students/

While a 22nm fabrication process is all well and good, why haven't Intel bothered to release their 80-core, teraflop chip that they touted some 6-7 years ago and said that we would have in our computers by 2011? http://techresearch.intel.com/ProjectDetails.aspx?Id=151

Yes. And let's not forget that Moore's law is not related to the maximum transistor density achievable at a given time, but to the transistor density achievable at the lowest cost (see Moore's original paper, the emphasis on cost is very clear).

So far every shrink reduced costs too, but the cost reduction may stop before shrinking stops. Smaller processes would then only be used due to higher performance, but would be more expensive. As a practical example, 28nm today is still more expensive than 40nm, and people go to 28nm for performance (lower power / higher frequency or ability to integrate bigger functions), not (yet) for cost reduction. In time 28nm will become cheaper than 40nm, but strictly speaking in term of Moore's law, the reference today should still be 40nm (I'm taking TSMC as a reference BTW, YMMV with other fabs).

I expect that as we shrink further, the gap between the date a smaller process is introduced and the date it becomes cheaper than the previous node will increase, and maybe at some point cost will just increase. That will be the end of Moore's law.

There's a lot of interest riding on the continuation of Moore's law, particularly from companies that gain a competitive advantage from being among the first to get access to a smaller node. This means Intel of course, but even a lot of big fabless companies have better access to a smaller node compared to smaller fabless ones for example. The day Moore's law, then shrinking, stops, we can expect laggards in process to catch up eventually and this advantage would disappear. That would be quite a change. So let's not expect candid assessments on Moore's law status, there's just too much money involved. But among the less impacted players there's some noise starting to be heard. I noted recently the ARM CTO saying we should expect big changes, and sooner then most people expect. I wouldn't be surprised if it was related to this.

I think these days technically ALL of us do overclocking thanks to Turbo Boost and similar such technologies which up the frequency of the processor when only some cores are loaded.

Remember a year ago Intel was bragging about their new 3d tri-gate process would be 50% more power efficient: http://www.intel.com/content/www/us/en/silicon-innovations/standards-22nm-3d-tri-gate-transistors-presentation.html.

Yes, the slides are unambiguous: "Greater than 50% reduction in active power going from 32nm to 22nm". Now, Intel tells us they have been predicting modest efficiency gains all along. For the last few months mabe. The truth is, Intel realized months ago the process would not meet expectations and already fired up the spin machine back then.

Remember a year ago Intel was bragging about their new 3d tri-gate process would be 50% more power efficient: http://www.intel.com/content/www/us/en/silicon-innovations/standards-22nm-3d-tri-gate-transistors-presentation.html.
Comparing the i7 3770K against the 2600K, which is clocked at the same frequency it's only 17% more power efficient: http://www.anandtech.com/show/5771/the-intel-ivy-bridge-core-i7-3770k-review/20
Also you have to bare in mind some of the power saving is due to the DDR controller power gating

Haswell should be a Tock - a BIG performance improvement.

Don't expect a raw BIG performance improvement. Not like p4 vs core2. But Haswell DOES implement a breaktrough - Transactional Synchronization Extensions. It translates to "transactional memory for threads". An addition of couple of new instructions (may even be available on current CPUs, as they are already documented in the development manuals) to control thread context. Check http://software.intel.com/file/41604 for details.

ZankerH, I appreciate the comment, but you've actually got it backwards. The tick is a new shrink, the tock is a new architecture: http://www.intel.com/content/www/us/en/silicon-innovations/intel-tick-tock-model-general.html

To be sure that no misunderstands your post, RdRand doesn't just use noise in the general hardware, it has its own dedicated hardware to generate that noise and the subsequent random numbers.

From one of Intel's software blogs:

Mostly, Bull Mountain follows the Cascade Construction RNG model, using a processor resident entropy source to repeatedly seed a hardware-implemented CSPRNG. Unlike software approaches, it includes a high-quality entropy source implementation which can be sampled quickly to repeatedly seed the CSPRNG with high quality entropy. It represents a self-contained hardware module that is isolated from software attacks on its internal state resulting in a solution that achieves Random Number Generation objectives with considerable robustness: Statistical quality, highly unpredictable random number sequences, high performance, protection against attacks.

And an article (with pictures!) from IEEE Spectrum Magazine: Behind Intel's New Random-Number Generator They go through some of the history and theory of RNG including the lava lamp generator.

Network on chip design has *absolutely nothing* to do with a shared system/cpu bus. Specialised processing units are already making use of these new types of architectures. e.g. http://techresearch.intel.com/ProjectDetails.aspx?Id=151 The cores are architected as a 2d mesh with each core having a 5port message passing router. This allows a ~3Ghz clocked CPU to deliver a 1 teraflop performance while consuming 62W power.

The seminal paper proposing the use of switched/routed interconnection networks on-chip (NoCs) was published by Dally and Towels 11 years ago in DAC'01: Route packets, not wires: On-chip interconnection networks. The idea of associating a router to each core and replicating it in "tiles" is not new either; Tilera was (IIRC) the first company to sell processors based on a tiled design, which was an evolution of the RAW research project. A related research project, the TRIPs, replicated functional units on each tile, rather than full cores. Intel has used a tiled design in the Polaris, SSC and MIC (which includes the forthcoming Knights Corner).

So no, the idea of using routed interconnects is not new at all. In fact, after reading the linked article, turns out that 2/3ths of the text are introducing the idea, and the last section details the contributions: Two ideas developed by the group of Li-Shiuan Peh seeking to improve performance (by using virtual bypassing, a form of routing precomputation) and reducing power consumption (using low-swing signaling).

The seminal paper proposing the use of switched/routed interconnection networks on-chip (NoCs) was published by Dally and Towels 11 years ago in DAC'01: Route packets, not wires: On-chip interconnection networks. The idea of associating a router to each core and replicating it in "tiles" is not new either; Tilera was (IIRC) the first company to sell processors based on a tiled design, which was an evolution of the RAW research project. A related research project, the TRIPs, replicated functional units on each tile, rather than full cores. Intel has used a tiled design in the Polaris, SSC and MIC (which includes the forthcoming Knights Corner).

So no, the idea of using routed interconnects is not new at all. In fact, after reading the linked article, turns out that 2/3ths of the text are introducing the idea, and the last section details the contributions: Two ideas developed by the group of Li-Shiuan Peh seeking to improve performance (by using virtual bypassing, a form of routing precomputation) and reducing power consumption (using low-swing signaling).

Fabricating the level of density without leaking is very hard.

It's impossible. There is always leakage. Yes, as you scale, the leakage does grow, both empirically and as a signal/noise problem. But there are ways to minimize this. This has been foreseen for some time, and a lot of research goes into ways to mitigate it. Despite all the improvements made sub-surface - that is, how the semiconductor itself is altered - to allow scaling and improve efficiency, and how the tools and methods to make the devices have improved... the industry really hasn't had any radical changes in many years. It has been all planar designs that date back to the 70's. Sure, the materials have improved, and it's not entirely silicon any more... but still planar, and subject to some fundamental limits of the planar design and the substrate choice. That's why Intel is pushing into 3d designs. Do some reading on FINFETs, and the benefits of them, especially with respect to leakage and control. And that can still be silicon based, and doesn't push at all into heterogeneous semiconductor systems.

  Fabs are very ex[pensive to built.
Add to the the consumer need for faster clocks has tapered off, it's not worth the expense of massive retooling.

Oh, really? Why are the industry giants doing it, then? Smaller die - this improves speed and potential clock, can improve power efficiency, means more die/wafer or more advanced designs. Ability to do different etches, deposit different films, etc., to improve device characteristics.

Clockspeed isn't everything anyway, or we'd still be using the Pentium 4 chips that were pushing 4 GHz from the manufacturer, and not the 2 GHz-range Core 2/iX chips. Smart design can trump clockspeed. (I use Intel as an example here because they had the more recent significant architecture change which illustrates this point very well.) We could, y'know, go back to making Pentiums... with current manufacturing technology, we might make them, what, 1/8 the size? Could probably clock them at several GHz.

When they can get the metal well below 1 part per billion in the fabs, and create a process to minimize wafer breakage for wafer being cut so precisely, then we may see a doubling of clock speed 2 more times. Then that will be it.

What makes you think metal contaminants and wafer breakage are the limiting factors to clockspeed scaling? And from where do you get a "doubling of clock speed 2 more times" from? What are you considering the base clockspeed that you are multiplying? Seems like you're pulling it out of your ass. Think about it. We're doing 3 GHz+ already. Doubling that puts us in the 6-8 GHz range. Doubling again puts us in the 12-16 GHz range. That's what people above are claiming as the fundamental limit in a synchronous chip by the limit of the propagation of a signal in a metal. The speed of light in metal is in no way the limiting factor in clockspeed. That would be the case for a single wire in isolation. There are other effects, namely capacitive coupling, in a chip where you are wiring up billions of transistors, which are much more limiting. And we're tallking wires of non-negligible resistance here - if you want to put a bunch of small transistors close together, you need to be able to make really thin metal wires to connect to make the right connections. Assuming metal is the only interconnect, of course, and completely ignoring all the research into optical interconnects...

Yes, but consumer-level drives are more prone to failure than their enterprise counterparts. It's a known fact that enterprise-level hard drives are built more reliably. If you don't believe me, then check this out.

However, with proper redundancy one can still get away with using consumer-level drives with an acceptable level of risk.

When you start involving vendor supplied hardware, the source code is only half the information. You still need to know what the hardware is doing. Similar to the laptopn anti-theft products, if there is a chip in the hardware that is independent of the software supplied, it is difficult to notice. Yet this would allow the manufacturer to still have some control of the system. In order to fully know there is no espionage involved, you would have to examine down to the chips themselves.

You don't get 80 lanes by multiplying the lanes per processor by the number of processors.

http://download.intel.com/newsroom/kits/xeon/e5/pdfs/Intel_Xeon_E5_Factsheet.pdf

That's not a sandy bridge die shot. See those 2 bars that say QPI? It's nehalem. http://download.intel.com/pressroom/kits/corei7/images/Nehalem_Die_callout.jpg

I have an Intel CPU and run RHEL6[*], but I suspect it's handled similarly. You can see it loading firmware at boot time. If I run dmesg I see a boot-time record containing, among a bunch of other lines:

    platform microcode: firmware: requesting intel-ucode/06-2a-07
    microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x18 ...

once for each core.

I'm not sure where it gets the data file, but if you go to this download page at Intel, choose "Processors" in column 1, "Desktop" in column 2, and "Intel Core i3 Desktop Processor" in column 3, it takes you to a new page where you can enter "Linux" in column 1; column 2 will automatically be set to "Firmware" Download Type, and the first line of the results will be "Linux Processor Microcode Data File, 12/12/2011". If you go there, you can press "Download" and end up with tarball named "microcode-20111110.tgz", which extracts to a single big text file "microcode.dat". Actually, regardless of what you entered along the way, it appears the file covers every Intel x86 processor (server, desktop, and mobile).

The file contains a big bunch of hex numbers and some unilluminating comments and tags.

I assume the distro packager gets updates periodically from the same underlying source.

~~~~~
[*] Actually a free repackaging, PUIAS.

I have an Intel CPU and run RHEL6[*], but I suspect it's handled similarly. You can see it loading firmware at boot time. If I run dmesg I see a boot-time record containing, among a bunch of other lines:

    platform microcode: firmware: requesting intel-ucode/06-2a-07
    microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x18 ...

once for each core.

I'm not sure where it gets the data file, but if you go to this download page at Intel, choose "Processors" in column 1, "Desktop" in column 2, and "Intel Core i3 Desktop Processor" in column 3, it takes you to a new page where you can enter "Linux" in column 1; column 2 will automatically be set to "Firmware" Download Type, and the first line of the results will be "Linux Processor Microcode Data File, 12/12/2011". If you go there, you can press "Download" and end up with tarball named "microcode-20111110.tgz", which extracts to a single big text file "microcode.dat". Actually, regardless of what you entered along the way, it appears the file covers every Intel x86 processor (server, desktop, and mobile).

The file contains a big bunch of hex numbers and some unilluminating comments and tags.

I assume the distro packager gets updates periodically from the same underlying source.

~~~~~
[*] Actually a free repackaging, PUIAS.

I have an Intel CPU and run RHEL6[*], but I suspect it's handled similarly. You can see it loading firmware at boot time. If I run dmesg I see a boot-time record containing, among a bunch of other lines:

    platform microcode: firmware: requesting intel-ucode/06-2a-07
    microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x18 ...

once for each core.

I'm not sure where it gets the data file, but if you go to this download page at Intel, choose "Processors" in column 1, "Desktop" in column 2, and "Intel Core i3 Desktop Processor" in column 3, it takes you to a new page where you can enter "Linux" in column 1; column 2 will automatically be set to "Firmware" Download Type, and the first line of the results will be "Linux Processor Microcode Data File, 12/12/2011". If you go there, you can press "Download" and end up with tarball named "microcode-20111110.tgz", which extracts to a single big text file "microcode.dat". Actually, regardless of what you entered along the way, it appears the file covers every Intel x86 processor (server, desktop, and mobile).

The file contains a big bunch of hex numbers and some unilluminating comments and tags.

I assume the distro packager gets updates periodically from the same underlying source.

~~~~~
[*] Actually a free repackaging, PUIAS.

A single Data Translation Look Aside Buffer (DTLB) error can incorrectly set the Overflow (bit [62]) in the MCi_Status register. A DTLB error is indicated by MCA error code (bits [15:0]) appearing as binary value, 000x 0000 0001 0100, in the MCi_Status register.
Implication: Due to this erratum, the Overflow bit in the MCi_Status register may not be an accurate indication of multiple occurrences of DTLB errors. There is no other impact to normal processor functionality.
Workaround: None identified.
Status: For the steppings affected, see the Summary Table of Changes.

There are others that are more severe in their effects ("processor hangs"). AMD has similar errata, that's not news. Processors have bugs. The FDIV one just happens to be the most well known because it came along at the right time (as personal computers were becoming widely used) to make the general public aware that computers aren't perfect. That's what makes it a candidate for comparison.

Intel AppUp center is an ...

A bloated front end for ftp://intel.com/pub/win .

Also, even Vista isn't officially supported.
http://communities.intel.com/docs/DOC-4664#Q_Why_is_Microsoft_Windows_Vista_not_supported_with_Intel_AppUpSM_center/

firstly, I wish I was using VC6 still - the IDE was the best there ever was, fast, simple, didn't flicker or use up all your RAM.

However, you can use a different IDE if you must keep the old compiler for backwards compatibility.

Alternatively, you can replace the compiler in the IDE.

Advertised latency of SSDs are Much Lower than 5ms, in the order of 70-ish MICROseconds, not MILLIseconds.

The fine article misrepresents the facts. The EU case was decided by a commission without legal process. As for the US cases, you can read the FTC decision at http://www.ftc.gov/os/adjpro/d9341/101102inteldo.pdf . Quoting:

The Respondent, its attorneys, and counsel for the Commission having thereafter
executed an agreement containing a consent Order, an admission by Respondent of all the
jurisdictional facts set forth in the complaint, a statement that the signing of said agreement is for
settlement purposes only and does not constitute an admission by Respondent that the law has
been violated as alleged in such complaint, or that the facts as alleged in such complaint, other
than jurisdictional facts, are true and waivers and other provisions as required by the
Commission's Rules.

The NYAG settlement can be read at http://download.intel.com/pressroom/legal/nyag/NYAG-Intel_Final_Signed_Settlement_Agreement.pdf As stated there, the settlement was to avoid further litigation costs, once the NYAG found that its case had "been eviscerated".

In none of the cases to date has Intel admitted any culpability. In none of the cases has Intel been compelled to change its business practices or modify its products. What can one conclude from this?

The part about the legal fine print being put in a GIF file just to make it harder to discover through search engines is truly special.

http://www.agner.org/optimize/blog/read.php?i=49#184

http://software.intel.com/sites/products/web2010/prod-images/opt-notice-en_080411.gif

I know you're trying to be funny, but Linux originally didn't support anything older than a 386, which was fairly new at the time.

"Fairly". Linux: 1991. 80386: 1985, so "fairly new" presumably means "within the past 5-6 years". (Oh, and 80486: 1989.)

I know you're trying to be funny, but Linux originally didn't support anything older than a 386, which was fairly new at the time.

"Fairly". Linux: 1991. 80386: 1985, so "fairly new" presumably means "within the past 5-6 years". (Oh, and 80486: 1989.)

Still need to know if you've passed the six month mark yet. ^_^

Fair enough, I should have been more specific there. I've been using the system I'm writing this on (and mentioned in my previous post) since April 2011, and it was a replacement for another Intel GPU notebook which I had been using since August 2009. So that's a bit over 2 years on Intel GPUs, now. :)

And how is the OpenCL support on those GPUs?

I haven't had a reason to look very hard for it, but as far as I can tell the answer is "nonexistent". According to Intel's relevant FAQ entry they don't support running OpenCL code on any of their IGPs, including the newest and fanciest Sandy Bridge chips. They do have an implementation to run OpenCL on the CPU instead. I have no idea if using that approach gets you any performance benefits over just running equivalent x86_64 code on the same CPU.

Intel was the top contributor to Linux 3.0 (by lines) (source)

IBM is in there, too at #8

Google pushed the Linux kernel and WebKit into an uncountable number of handhelds

Apple deploys Webkit, too, on a smaller number of handhelds

Amazon deploys Android, too (just without Market support), and they use Linux in their cloud offerings.

If you hate Microsoft, give in to your anger and join Oracle (there are a lot of angry JCP and OpenSolaris fans but hey, they made that Linux list, too!)

Remember those handhelds that run the Linux kernel and/or WebKit?

• Broadcom
• Atheros (are they are part of Qualcomm now? You can check out Qualcomm, part of "Qualdroid")
• Marvell

all made the top Linux contributor list, too.

I'll assume that other posters will cover the Red Hat and Novell bases.

Intel on Sunday acknowledged that a bug could cause its SSD 320 solid-state drives to fail, and said a firmware upgrade is on its way to address the problem.

In some instances, a power loss may cause Intel's SSD 320 drives to crash and lose data. On rebooting the system, the system BIOS could report the SSD as having only 8MB of storage capacity. Intel two weeks ago said the error was possibly a bug, and that the issue was being investigated.

"Intel has reproduced 'Bad Context 13x Error' utilizing strenuous testing methods. This 'Bad Context 13x Error' can be addressed via a firmware update and Intel is in the process of validating the firmware update. A future update will define the schedule to deliver the firmware fix," an Intel spokeswoman said in an e-mail statement.

It's ironic that a power failure triggers this problem, since Intel had marketed the 320 as especially resilient to them:

http://www.anandtech.com/show/4244/intel-ssd-320-review

Intel always prided itself on not storing any user data in its DRAM cache. The external DRAM is only used to cache mapping tables and serve as the controller's scratchpad. In the event of a sudden loss of power, Intel only has to commit whatever data it has in its SRAM to NAND. To minimize the amount of data loss in the event of a sudden power failure, Intel outfitted the SSD 320 with an array of six 470F capacitors in parallel.

Some posters say it can happen without a power failure:

http://communities.intel.com/message/133499

Intel said they found the cause and released a firmware update, but applying it seems to have actually triggered the bug in previously problem-free drives for many posters:

http://communities.intel.com/thread/24121?start=0&tstart=0

Intel has not acknowledged any problems with the fix, nor told anyone which serial numbers were affected. Nobody has reported on the bug since Intel said they fixed it, including Anand.

This issue was enough to convince me to buy something else (even though the 320 series would otherwise have been my first choice) when I had to shop for an SSD last month. I found a used "like new" (according to the SMART data, at least) X25-M G2 on amazon instead.

Interestingly, X25-M G2 prices have held steady ($2/GB or so) and only gone up over the last year. Yeah it's probably because of dwindling supply, but I can't help but suspect that lack of confidence in the 320 series may have contributed to an increase in demand for the G2.

Intel on Sunday acknowledged that a bug could cause its SSD 320 solid-state drives to fail, and said a firmware upgrade is on its way to address the problem.

In some instances, a power loss may cause Intel's SSD 320 drives to crash and lose data. On rebooting the system, the system BIOS could report the SSD as having only 8MB of storage capacity. Intel two weeks ago said the error was possibly a bug, and that the issue was being investigated.

"Intel has reproduced 'Bad Context 13x Error' utilizing strenuous testing methods. This 'Bad Context 13x Error' can be addressed via a firmware update and Intel is in the process of validating the firmware update. A future update will define the schedule to deliver the firmware fix," an Intel spokeswoman said in an e-mail statement.

It's ironic that a power failure triggers this problem, since Intel had marketed the 320 as especially resilient to them:

http://www.anandtech.com/show/4244/intel-ssd-320-review

Intel always prided itself on not storing any user data in its DRAM cache. The external DRAM is only used to cache mapping tables and serve as the controller's scratchpad. In the event of a sudden loss of power, Intel only has to commit whatever data it has in its SRAM to NAND. To minimize the amount of data loss in the event of a sudden power failure, Intel outfitted the SSD 320 with an array of six 470F capacitors in parallel.

Some posters say it can happen without a power failure:

http://communities.intel.com/message/133499

Intel said they found the cause and released a firmware update, but applying it seems to have actually triggered the bug in previously problem-free drives for many posters:

http://communities.intel.com/thread/24121?start=0&tstart=0

Intel has not acknowledged any problems with the fix, nor told anyone which serial numbers were affected. Nobody has reported on the bug since Intel said they fixed it, including Anand.

This issue was enough to convince me to buy something else (even though the 320 series would otherwise have been my first choice) when I had to shop for an SSD last month. I found a used "like new" (according to the SMART data, at least) X25-M G2 on amazon instead.

Interestingly, X25-M G2 prices have held steady ($2/GB or so) and only gone up over the last year. Yeah it's probably because of dwindling supply, but I can't help but suspect that lack of confidence in the 320 series may have contributed to an increase in demand for the G2.

And in the soon to be most advanced fab in the world.

http://newsroom.intel.com/community/intel_newsroom/blog/2011/02/18/intel-to-invest-more-than-5-billion-to-build-new-factory-in-arizona

You are welcome Chandler, AZ.

Look up the processor's voltage VID range -- it should be on the Intel spec sheets, such as the one for the i7-980X. In the case of that processor, anything between 0.800V and 1.375V is considered 'safe'.

As far as how high a boost in speed you can get out of a processor without changing the voltages, it depends on your specific chip and how close to overvolting you get. Most of the time you can get 1-1.5 GHz extra (sometimes more) out of the chip before overvolting it (rarely do any overclockers actually overvolt chips -- there's little need, unless you're going for some sort of record), and an easy 0.5 GHz or more without even touching the voltage at all.

Although generality is good, we might ask what the "ideal" abstraction for a particular application is. In my opinion, it is a programming language that is designed precisely for that application: one in which a person can quickly and effectively develop a complete software system. It is not general at all; it should capture precisely the semantics of the application domain - no more and no less. In my opinion, a domain-specific language is the "ultimate abstraction".

One approach is not to directly program the GPU, but to use library provided (domain-specific) high-level parallel primitives (map,fold,reduce,..) to describe the computation. The library in question then compiles the final low-level code. These libraries are often implemented as domain-specific embedded languages. Topic is a subject for active research, but some more or less mature implementations already exist, some of which are:

• thrust provides STL-like algorithms for C++ while targeting CUDA and OpenMP as backends.
• ArBB implements a parallel array programming library for C++ built on a general purpose virtual machine targeting SSE, AVX and possibly MIC in the future.
• accelerate is an embedded language for array computations in Haskell and at the moment implements backends for CUDA and ArBB.

This was a demonstration project...I would be glad to be contradicted with sound arguments.

Have you seen our work? Prepare to be "glad." http://www.intel.com/content/www/us/en/home-users/unfold-whats-possible.html I'm rather proud of it. Those four vignettes were rendered in one week, which is the point of TFA, but it was months of blood sweat and tears. The cloud just made the deadline possible.

At work I have a quad core Q6700 with 4GB of RAM. At home I use an older single core Athlon 64 3500+ with 2GB of RAM. Both machines run Windows XP.

Both machines run FF 3.6 because I keep reading that later versions have worse memory use and UI performance characteristics.

On both machines, I experience two problems with FF memory usage (all figures were reported as "private bytes" by Sysinternals process explorer):

1) Memory usage keeps growing until it reaches a threshold (1.5GB on my home machine) after which FF locks hard with close to 100% CPU use and never recovers. Closing tabs did not bring the memory usage down in a perceptible way.
This used to require daily restarts of FF but lately the problem does not seem to happen that often. A restart can still cut the memory use by half (same tabs courtesy of session restore), which helps with problem #2 below, but it takes much longer to go over 1GB.

2) Periodic "stuttering" where FF will pause for a short period every once in a while with CPU usage spikes approaching 100%. The duration of the pauses seem directly related to the amount of memory that FF uses. That, and the periodic nature of the "hiccups", lead me to believe it is related to garbage collection.
Unfortunately, it makes viewing videos when FF is running (even using an external viewer) impractical, so I have to close FF and start IE8 each time I go to youtube,
There's a bug report that was opened almost 3 years ago (and still unassigned).

The responses that I get are:

* You're using an old version.
True, but according to the comments, bug 490122 is still present in the newer versions (up to v10) and people say that 3.6 is more responsive (especially on older HW) than the newer versions.

* It's the plugins/addons/extensions.
Perhaps, but the reason I use FF at all is because of the extensions and I would expect such an "extension-centric" product to help me figure out which one is misbehaving (for example, by reporting the memory usage of each tab).

Now, reading the article and the slides, I am getting hopeful that these issues are being addressed.

Yeah, companies sure never support FreeBSD.

Oh, wait...

http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17509

As far as emulators, everyone recalls the PC emulators available for the PPC Macs. They did work, but the system they were emulating was slow by standards of the time. You could in principle emulate any processor on any other processor - but would it be worthwhile?

Rosetta didn't suck too badly - it ran Quicken 2007 adequately on my MacBook Pro. ("Ran" because I dumped it in favor of Quicken Lite^WEssentials when Q2007 couldn't manage to avoid corrupting one of my credit card accounts.) Unlike the PC emulators, it didn't have to implement the raw hardware - it just had to run usermode code, and it translated system call arguments and results. Dunno how hard it'd be to translate x86 machine code to ARM machine code; if I remember correctly, ARM processors aren't guaranteed to support unaligned accesses, so sufficiently-safe translations of x86 memory-reference instructions might be complicated code sequences. (I'd look it up, but the fine folks at ARM have decided to make their instruction set architecture manuals only "available in [PDF versions] to registered ARM customers". Intel are a bit nicer, as are AMD.)

The results should still be the same, assuming you have structured your systems meticulously and accounted for any errors. Intel has an interesting article about deterministic parallelization.

As I said, if you introduce any deliberately random elements, you will obviously not get the same results. But if both systems have been developed to produce entirely deterministic results, and use adequate data validation to ensure no errors creep in, the results would be identical.

You guys telling me it's not possible to write a program that behaves the same way and produces the same results on more than one system? Might as well toss out the entire field of Computer Science, then. :-p

I admit it's not easy to do this, the more complex a program gets, but it is by no means impossible.

Here's what I know:

If I'm Dell, and I buy a lot of 1,000 CPUs, I take them in OEM packaging without a warranty from the manufacturer. Why? Simply because it's cheaper that way, from start to finish.

Meanwhile, Intel has a lovely little FAQ about their processor warranties that you can amuse yourself with once get done imagining things.

Microsoft doesn't offer a 64-bit compiler that cross-compiles to 32-bit. Fine, I can accept that. But there are other compilers one could use:

http://software.intel.com/en-us/articles/intel-compilers/ is still reputed to produce the tightest, fastest WinXX executables available.

http://www.embarcadero.com/products/cbuilder (formerly Borland C++)

The venerable http://gcc.gnu.org/

http://www.ghs.com/products/optimizingC++EC++Compilers.html (though it looks like GHC might no longer target Windows at all)

From Intel's AppUP website here is a writeup/guide about how to create a multi-boot environment on the Atom based ExoPC

http://appdeveloper.intel.com/en-us/blog/2011/07/07/creating-multi-boot-exopc-tablet

This shows how to multiboot Ubuntu, Windows, MeeGo on the ExoPC.

NOTE: the ExoPC is exactly the same h/w as the European WeTab tablet. BOTH are made by a subsidiary of ASUS.

My L2400 from Q1/2006 is "Max TDP 15 W" and I got 313227 on BrowserMark.

http://ark.intel.com/products/27229/Intel-Core-Duo-Processor-L2400-(2M-Cache-1_66-GHz-667-MHz-FSB)

All ARM devices I have suck in benchmarks (especially those involving math) comparing even to old x86 gear.

Oh, I don't know... electrostatic ion propulsion is already proven to be more efficient than ordinary chemical propulsion (once you get out of the gravity well).

As long as you have fuel, you'll keep accelerating, albeit at a very small rate. It might take ten or twenty years, but I reckon that if an ESI probe was launched tomorrow it'd overtake Voyager and still have propellant to go faster.

The bonus is with computer technology; that while it's gotten thousands of times faster in practically every respect, it's also gotten a lot smaller - a non-hardened computer package these days weighs no more than 3lb, with terrestrial ruggedised coming in at little more. The advantage of this is obvious: with the single biggest non-fuel component of the spacecraft now the size of a paperback, you have far less mass to push.

Of course, you don't need a screen or a keyboard in deep space, so cut the weight in half and you've got something a smidge lighter than the several hundred pounds of GE custom machine that went up with Voyager, that has its own battery, that pulls about ten Watts rather than over a hundred, that uses solid state storage, and in most cases can automagically govern its own power load (this would be why the later Shuttle missions used self-contained laptops rather than a room full of mathematicians and radio that meant data moved at the speed of speech) - I've metered my netbook off the line and found it runs on between 3-35W, averaging 11, including the screen on minimum brightness.

That said, you do need to protect the computer against hard radiation. That will obviously push the weight up, but not so much as to make it unmanageable. A couple or three pounds of lead and a steel cage to protect against EMI/RFI I think is all that is needed. The major part of the probe is then going to be propulsion systems and fuel, and the science package.

That's typically not how MTBF is calculated at least in the industry I work in. The MTBF for the system is from the calculation of the MTBF of all subcomponents factoring in redundancy (if it exists), load, etc. A quick check of the X25M data sheet verifies they used parts stress method to do their calculation.

See X25M Datasheet Section 3.5.2 and Reliability Calculation

Don't know about the others, but for the 350 it's 76 degrees Celsius.

http://ark.intel.com/products/61272/Intel-Pentium-Processor-350-(3M-Cache-1_2-GHz)

Comparing a 65w TDP to a 15w TDP is such a stretch its not even funny.

Im sorry, I love AMD, how cheap they are, their graphics, the competition they bring to intel, etc; but theyre so uncompetitive right now its not even funny. For $200 I can get an intel processor that can do over 1GB/sec of AES encryption (thats around 10gbit vpn tunnels, if youre keeping score) in a 20w package. They seriously need to get their act together, especially as regards power draw.