electrical power draw by x86 assembly language instructions

Can't be quantified. For example consider that you execute "NOP". Not much happening, right? But what if that NOP is at the end of a cache line, and it causes a cache fill?

Or simplify the assumptions, say you have no cache and no MMU, just a simple core executing instructions. Same NOP. Execute it at address

0x00000000 and PC is incremented to 0x00000001. One flip-flop changes state. But what when you execute the same NOP at address 0xFFFFFFFF? PC is incremented to 0x00000000; 32 flip-flops change state!

Power consumption in processor cores is expressed in MIPS/mW typically (with a "reference" instruction mix being executed). It's not broken down into the J/instruction level. Oddly enough you are the third person in the last two weeks who has asked this kind of question in my hearing. Are you, too, trying to quantify the power consumption difference between traditional and quantum computers?

1. Long while ago I measured current consumtion of i486 motherboard when executing different test sequencies. I don't remember exact results, but:

• There is no big difference between different instuctions.

• It is a misconception that floating point math draws a lot of energy.

• CPU bus activity takes considerable amount of power.

1. With AD DSPs like 21xx or BlackFin, the difference in power consumption when executing different instructions can be as much as 4 times. Multifunction MAC instructions draw the highest current, any other instruction draws about 4 times less then that.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

I found that there is no big difference in the power consumption of i486 wrt what it is doing (except HALT, of course). Bus activity does matter.

This is a global warming issue: they want to make "green" compiler which uses only "preferred" instructions.

VLV

When you say "totally different requirements", I think you are wildly overstating the case in an x86 system. Excluding instructions that have clear power implications (like "halt"), I would not expect the power consumption in an x86 to vary by more than a fraction of a percent dependent on the instructions used. Bus and cache activity will have a far greater impact.

When you take into account the motherboard, chipset, memory chips and other devices in even a small x86 system, any instruction-dependent power variations are going to be totally undetectable.

It's a different matter for other processor architectures that are more efficient and have fewer parts. Then there may be measurable differences, and blocks (such as floating point or vector units) with independently controlled clocking which can reduce power when they are unused. But you would need to get down to a very simple microcontroller before it would be feasible to measure power consumption for different instructions (and even then, the values would vary greatly).

If you want to reduce power consumption on a processor, try to do the required work in the shortest possible time - then the processor can spend more time in sleep or halt modes.

Compared with the draw of everything else on the motherboard - definitely.

It has lots of FFs both from complexity and pipelining, so it should draw more. Just like the DSP MACs you described. Again, depends on compared to what.

Seconded.

Probably again their comparative complexity, roughly times the pipeline stages.

BF keeps damn cool, I wish they fix the insane core errata and release the 51x family.

FPU operations take many clock cycles. While FPU is operating, the rest of a processor does nothing as it has to wait for the result. Yes, I know that CPU and NPU can operate in parallel, but in realistic code the CPU will immediately run into the next FPU instruction. DSP MACs are performed in one cycle, and they combine arithmetic operation with code fetch and data fetches over two buses. However this is a speculation no better then yours. From what I saw, there is no significant difference in i486 power consumption while performing FPU commands. If you want to present the facts, take a meter and see for yourself.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

If you're determined to measure it, it's feasible. The security community got a serious scare when it turned out to be possible to detect instruction sequences and even data values from secure processors - microcontrollers or more complex parts like PCI crypto accelerators. That meant the crypto on your bank card or mobile phone SIM could be cracked by simply putting a resistor in the power supply, recording the voltage across it with a scope, then a bit of statistical crunching to extract the crypto keys being used by the instructions (and therefore steal money).

This is a big research field - Google 'differential power analysis'. There's lots of effort gone into securing against DPA. Most of the examples are on microcontrollers or FPGAs - I'm not sure how far it has been extended into more complex processors.

But this doesn't really apply if all you care about is saving the battery.

Theo

I had thought of mentioning differential power analysis in cryptography, but it's not really the same thing. Basically, with differential power analysis you are trying to see if the processor is doing something different dependent on the inputs you give it. For example, you measure the current fluctuations when trying different parts of a key. If every combination gives the same fluctuations except for one particular try, then perhaps that is because the key part matched and therefore the code ran a different sequence of instructions.

The fact that such analysis can be made to work shows that there can be a measurable difference in the power taken by these devices depending on the code path. But it's a very big leap to go from there to identifying the power requirements of different x86 instructions. First, you are talking about a different class of devices - more like the small and simple devices I mentioned rather than an x86. Second, you are talking about code sequences - which could well be as simple as a wrong key causing a "sleep" after a short sequence, with the right key running a longer sequence first. Thirdly, you are not in any way identifying the power requirements of particular instructions.

Interesting ! Are you working on some kind of mobile or handset technologies ?

Karthik Balaguru

Good illustrative example :-)

Interesting !

Karthik Balaguru

e

ller

unity

tion

s or

to on

ope,

ed by

w far

ry.

e y g

Yes,it seems that Differential Power Analysis does not help in identifying the power requirements of particular instructions and deals only with analyzing power consumption measurements.

Karthik Balaguru

Why would you actually want to do this " per instruction level power consumption" list & analysis ?

Karthik Balaguru

~ Well, I used to work in a project which next step was going to be a wireless implementation so I read quite a bit on Symbian programming (some time ago) and as I remember therewere ways to know to a great extent the actual physical taxing of single instructions in those small processors ~

~ As I explained above. Isn't coding thinking on sparing some energy honorable and even appealing? ;-) ~ Thanks lbrtchx

What kind of ways are available in those small processors ? Any links / documents ?

But, i think Handset technologies do not use x86. Is there any handset that uses x86 ?

I think, nowadays they mostly use ARM & DSP processors. Sometimes, only one processor that encompasses both. I think, your query should be even more specific towards it. Can you tell the exact processor and OS platform you use ?

Karthik Balaguru

For old TTL and ECL processor boards, the power consumption was independent of calculations.

For any CMOS logic, the power consumption is directly proportional to the operating frequency and to the square of the operating voltage.

Unfortunately, these days, most of the gates are clocked at the clock frequency, thus the power consumption is constant, unless some halt/wait instructions are used to disable the clock from most gates.

For the x86 case, probably yes - I never had to get intimate with x87 and the horde of heirs.

In the general case, many FPUs are coprocessors which execute their pipeline async to the CPU up to a stall. I know at least one which had bit to select sync/async operation.

Two or more buses. I think most MACs have pipeline longer than one, which is covered by the penalty of branching.

Anyone who designed similar things may jump in and correct us. :-)

o

I believe your meter readings. My comment was whether you compared it to the i486 VCCint consumption only (harder to setup) or the whole board.

The real interesting case is not x86 but MCUs. And since I don't deal often with FPU-blessed MCUs, I will keep your MACs-have-higher- consumption observation in mind, because it is very logical, too.