Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: Power consumption vs architectural bit-width  (Read 366 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9483
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Power consumption vs architectural bit-width
« on: November 25, 2020, 01:34:05 AM »

Take say the original MC68000 and compare it to its crippled child the MC68008 or the fine 68030/68040, or compare the 8086 to the horrid 8088. Do we think that the versions that have a compromised address or data bus width use more energy because they have to execute twice as many fetch cycles to get the work done?

What about x86 32-bit vs AMD64 / x86-64 ? If you really need 64-bitness in your data would 64-bit help the energy consumption? Iím wondering if 64-bit addresses vs 32-bit addresses would hurt energy consumption too? The AMD64 architecture is much more efficient because it has a lot more registers so less faffing about with the stack, so that improvement alone might mess up the comparison, so maybe sticking to exactly the same code in both might be an idea and then trying a comparison with fully optimised code designed for each x86 architecture, 32 or 64-bit.

Same could be asked about ARM 32 vs 64-bit. It has been a long time since I looked at it and Iíve forgotten much, but from a quick glance AArch64 code looks rather cleaner, but I would need to read up on the differences.
Logged

Alex Atkin UK

  • Kitizen
  • ****
  • Posts: 1871
    • My Broadband History
Re: Power consumption vs architectural bit-width
« Reply #1 on: November 25, 2020, 03:42:38 AM »

It gets even more complicated when were seeing some things running on the new Macs using x86 translation as fast as they do on native x86_64 chips that use MORE power.  But I guess at that point its apples to oranges due to wildly different architectures.  Even ARM 32 to 64 is apples to oranges, as its unlikely you would have an implementation that is identical in all other ways.

If were talking identical architectures but different bus widths, then I'd suspect the answer is yes, but the cost may be offset in power savings from the support infrastructure needing less power due to the lower bus width?  Its certainly argued that an identical CPU at a lower clock rate ends up using more power in many cases, so long as you remain in the sweet-spot for clock frequency power efficiency.

I'm no engineer, this is just based on years of building PCs and reading/watching tech reviews.  So it would be interesting to hear from someone more knowledgeable of the actual specifics.
Logged
INTAKE (ECI) Zen: Home Hub 5A OpenWrt Plusnet: VMG-3925-B10B Three 4G: Hauwei B535-232 Router: pfSense (i5-7200U) WiFi: Ubiquiti nanoHD
Thinkbroadband Quality Monitors

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9483
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Power consumption vs architectural bit-width
« Reply #2 on: November 25, 2020, 04:08:26 AM »

Alex, when you mentioned the Mac, were you referring back to the days when Apple did PPC to x86 translation on the fly, at load-time? (Or for all I know, earlier than JIT, because they may have cached stuff beforehand on an earlier run? You can also compile MSIL to native x86 code can you not ? And I presume it puts the result into a cache so it can remember whether or not a particular module has already been compiled. DEC did VAX to Alpha code translation too in the early 1990s iirc. )

Youíre right, need to rule out the effects of availability of better instructions and stick to truly identical code. Allowing for code differences that take advantage of instructions set and register set size improvements means answering a different but also interesting question.

And Iím not interested in power, just total energy consumed by a particular truly CPU-bound job, regardless of how long it takes. Machines that are truly static, which I think might be rare, [donít know ? thatís a very good question], can get a job done quicker on machines with a higher clock rate and then sleep sooner with the clock turned down to literally 0 Hz for longer (Like all of Psionís machines 35 to 20 years ago) so the total energy consumed may remain roughly the same pari passu.
« Last Edit: November 25, 2020, 06:07:36 AM by Weaver »
Logged

Alex Atkin UK

  • Kitizen
  • ****
  • Posts: 1871
    • My Broadband History
Re: Power consumption vs architectural bit-width
« Reply #3 on: November 25, 2020, 04:46:12 AM »

Alex, when you mentioned the Mac, where you referring back to the days when Apple did PPC to x86 translation on the fly, at load-time? (Or for all I know, earlier than JIT, because they may have cached stuff beforehand on an earlier run? You can also compile MSIL to native x86 code can you not ? And I presume it puts the result into a cache so it can remember whether or not a particular module has already been compiled. DEC did VAX to Alpha code translation too in the early 1990s iirc. )

The new Mac Mini, Macbook Air and Macbook Pro are M1 ARM based with an x86 translation layer.  Like they did before only I'd think x86_64 is way more bloated than PPC was.
https://www.macrumors.com/2020/11/15/m1-chip-emulating-x86-benchmark/
Logged
INTAKE (ECI) Zen: Home Hub 5A OpenWrt Plusnet: VMG-3925-B10B Three 4G: Hauwei B535-232 Router: pfSense (i5-7200U) WiFi: Ubiquiti nanoHD
Thinkbroadband Quality Monitors

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9483
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Power consumption vs architectural bit-width
« Reply #4 on: November 25, 2020, 06:23:07 AM »

What are you thinking about x86-64? About code density? The x86 is very good on code size because it has byte-oriented variable length instructions, which are very difficult and expensive to decode, but short and the whole thing acts as a short of approximate data compression, with frequent instructions being short, so history has made it.

Or am I missing the point?

Itís like a VAX in this respect; variable length byte oriented instructions but those are very logical and well organised. The MC68000 on the other hand has long instructions where even common instructions can be 16-bits long with no shorter alternative options. We once at work wrote some stuff in assembler for the 68000 and it was just to long, so instead the whole lot had to be rewritten by hand in an interpreted virtual machine code of our own invention; Sinclair did this in their ROM in places and we were very much influenced by DECís TABL iirc virtual machine interpreted language for the VAX. We had to write a compiler for this VM language, so the whole thing was a huge waste of time and a nightmare but it successfully got the code size down massively because the MC68kís code density was soo bad. This was in the mid 1980s when RAM and ROM sizes were very often ridiculously inadequate.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: Power consumption vs architectural bit-width
« Reply #5 on: November 25, 2020, 09:32:35 AM »

Take say the original MC68000 and compare it to its crippled child the MC68008 or the fine 68030/68040, or compare the 8086 to the horrid 8088. Do we think that the versions that have a compromised address or data bus width use more energy because they have to execute twice as many fetch cycles to get the work done?

What about x86 32-bit vs AMD64 / x86-64 ? If you really need 64-bitness in your data would 64-bit help the energy consumption? Iím wondering if 64-bit addresses vs 32-bit addresses would hurt energy consumption too? The AMD64 architecture is much more efficient because it has a lot more registers so less faffing about with the stack, so that improvement alone might mess up the comparison, so maybe sticking to exactly the same code in both might be an idea and then trying a comparison with fully optimised code designed for each x86 architecture, 32 or 64-bit.

Same could be asked about ARM 32 vs 64-bit. It has been a long time since I looked at it and Iíve forgotten much, but from a quick glance AArch64 code looks rather cleaner, but I would need to read up on the differences.

Hmm bus width vs power this is something I have ever thought about, or that I am in any way qualified to offer a definitive answer.

I can certainly see the argument that a wider bus might save on clock cycles.

Iím thinking of the cost of driving each bit of the bus repeatedly high, and low, with an energy loss on each transition.   I would assume that the faster you want to pull the lines up and down, the more energy youíll use in the process, overcoming the capacitance thatís trying to keep the bits as they were.   And to get the same data bandwidth through a bus half the width, the individual bits must be twitching faster?

Playing Devilís advocate,  Iím also thinking that the input and output gates on the bus will consume a quiescent current which would be greater for more bits, but my hunch is that is probably insignificant vs the switching losses.

If there is  a black and white answer, Iíd be interested too. :)
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9483
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Power consumption vs architectural bit-width
« Reply #6 on: November 25, 2020, 03:22:34 PM »

For a wider data bus, you are pulling those twice as many bits up and down half as often, so things equal out, no?

Very wide address buses are just guzzlers as you point out.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: Power consumption vs architectural bit-width
« Reply #7 on: November 25, 2020, 07:48:38 PM »

I think what I was thinking was (does that parse?) that with a narrower bus, not only do the bits need to twiddle more often, but the rise and fall times need to be faster too, making the comparison non-linear.  Iíve never been sure I understand the expression Ďpolynomial equationí and so I avoid using it,  but it might be what Iím getting at.

But my head thinking capacity overflows easily these days, happy to believe thereís a flaw in my reasoning. :)
Logged
 

anything