Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dark Silicon Problem and What It Means for CPU Designers (2013)

informit.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#41

Post by saagarjha »

frozenport wrote: post #38
Cybiote wrote: post #37

Earlier quoted context omitted.

The temperature of the sun at its surface is ~5772 Kelvin. To get power per unit area, use Stefan-Boltzman: σ * T^4, σ * (5772 K)^4 ≈ 6294 W/cm^2. Dividing the sun's luminosity (power) by its surface area will also give a similar value. A 815 mm^2, 250 W GPU will be 250 W / 8.15 cm^2 ≈ 31 W / cm^2.

Doesn't that only include radiated heat? If I touched it, it would be hotter.

It wouldn't be hotter (the temperature wouldn't change), but it would transfer more heat to you.

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#42

Post by phkahler »

bogomipz wrote: post #40

I had a couple of question about this bit of history mentioned in the article. I'm hoping someone could shed some light on this: >"You can emulate floating-point arithmetic by using integer instructions—but taking 10–100 times as long." Exactly how is/was floating point arithmetic emulated using only integers? Why is that range given an order of magnitude? Is this dependent on the precision I'm guessing?

We had floating point when programming in BASIC on old 6502 8bit computers. There were software routines for doing the math. You know, multiply the mantissa, add the exponents... If someone gave you pointers to a couple 4-byte chunks of data and told you to write code to do floating point multiply on the contents using only C-char variables, what would you write? That's why it's 100 times slower than a nice modern fmul. It wasn't quite that bad, they could use the carry flag which isn't available in C.

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#43

Post by sehugg »

phkahler wrote: post #42
bogomipz wrote: post #40

I had a couple of question about this bit of history mentioned in the article. I'm hoping someone could shed some light on this: >"You can emulate floating-point arithmetic by using integer instructions—but taking 10–100 times as long." Exactly how is/was floating point arithmetic emulated using only integers? Why is that range given an order of magnitude? Is this dependent on the precision I'm guessing?

We had floating point when programming in BASIC on old 6502 8bit computers. There were software routines for doing the math. You know, multiply the mantissa, add the exponents... If someone gave you pointers to a couple 4-byte chunks of data and told you to write code to do floating point multiply on the contents using only C-char variables, what would you write? That's why it's 100 times slower than a nice modern fm…

Yep, here's the old Woz/Roy Rankin 6502 code for log, exp, conversions, and basic math: http://www.6502.org/source/floats/wozfp1.txt

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#44

Post by nine_k »

namibj wrote: post #21
a_wild_dandan wrote: post #15

Earlier quoted context omitted.

(Intensity) = (Power) / (Unit Area) (Sun's Radius) = 695 x 10^6 m (Sun's Power) = 4 x 10^26 W (CPU Output) = 75 W (Die Size) = 37 mm x 37 mm (Sun Intensity) = (4 x 10^26 W ) / (4 x pi x (695 x 10^6 m)^2) ~ 66 x 10^6 (CPU Intensity) = (75 W) / (0.0014 m^2) ~ 53 x 10^3 I'm getting a several orders of magnitude higher W/m output for the sun. Perhaps I made an algebra mistake?

Yes. You can handle 100W on a 300mm^2 chip. Or 300W on a large one, compare AMD Ryzen/ Nvidia Volta (MXM/V100).

this gives 3.46e+5, probably comparable to brown dwarf figures in the tread.

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#45

Post by kabdib »

bogomipz wrote: post #39

I had a question - the author states: >"The most obvious is the instruction decoder, which is near the start of the pipeline, and is responsible (in the loosest possible terms) for passing the inputs to each of the execution units." Why would it "in the loosest possible terms"? Isn't this "precisely" the job of the decoder?

IIRC in many chips the decoder stage translates native instructions into micro-ops, which are RISC-like and the main food for execution units. The translation is not necessarily a simple one (one native instruction is often more than one micro-op, and it's possible to collapse multiple native instructions -- especially stuff like prefixes -- into one or more micro-ops).

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#46

Post by burnte »

blackflame7000 wrote: post #2

Why don't they start making CPUs 3 Dimensional like a cube with 6 "processors" each with multiple cores as its "sides" with the pins on the opposite sides of the cube wall. Seems to me more internal volume might allow for more cleaver head distribution channels

Just the reverse. As volume increases, the relative amount of surface area decreases.

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#48

Post by brandmeyer »

bogomipz wrote: post #40

I had a couple of question about this bit of history mentioned in the article. I'm hoping someone could shed some light on this: >"You can emulate floating-point arithmetic by using integer instructions—but taking 10–100 times as long." Exactly how is/was floating point arithmetic emulated using only integers? Why is that range given an order of magnitude? Is this dependent on the precision I'm guessing?

If you have a copy of Knuth's Art of Computer Programming, the section on seminumerical algorithms covers software floating point.

Another source is the Handbook of Floating Point Arithmetic, which covers both hardware and software methods in detail.

An implementation in source code may be found in libgcc. IIRC their ARM assembly code versions are some of the fastest routines available anywhere for software floating point emulation. While they are in assembly, ARM assembly is fairly intelligible.

Finally, you can probably come up with 90% or more of the correct solutions yourself if you start with the definition of a floating-point number as (-1)^s * 1.m * 2^(e - bias) and grind through the algebra with the bias as a constant. The theorems that prove the minimum number and nature of the guard bits to get correct rounding are another matter, but you can start off by computing the equivalent infinite-precision terms and then rounding.

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#49

Post by pkaye »

bogomipz wrote: post #40

I had a couple of question about this bit of history mentioned in the article. I'm hoping someone could shed some light on this: >"You can emulate floating-point arithmetic by using integer instructions—but taking 10–100 times as long." Exactly how is/was floating point arithmetic emulated using only integers? Why is that range given an order of magnitude? Is this dependent on the precision I'm guessing?

A floating point number consists of 3 parts: mantissa, exponent and sign. These are usually packing into a 32-bit or 64-bit value. So you can split them back into 3 integers and do the integer adds, multiply and shifts to get the result and pack them back. It is not hard to implement a basic version but to make it fast and comply with the standard is a bit more work.

Re: The Dark Silicon Problem and What It Means for CPU Designers (2013)

#50

Post by agumonkey »

deepnotderp wrote: post #29
tormeh wrote: post #22

Earlier quoted context omitted.

The heat can be tackled in part by pumping water through holes in the CPU. I believe it was IBM that came up with this. Can't tell if it's feasible or not.

Yes but microfluidics limits how thin each die can be.

What about stacked heat vias ?
Post reply on HN