Slashdot Mirror

I found the Google estimate site and used the highest RAM servers available. 25 servers at 24/7 comes to over $277,000 if paid by a customer. Estimate variables below.

That's over $1.1 million USD for the 4 month period.

I'd call this exercise a massive waste of electricity. How much coal was used in this exercise? How many tons of CO2 did this add to the environment?

Site: https://cloud.google.com/produ...

Estimate Details: 25 x Calculating Pi. 18,250 total hours per month VM class: regular Instance type: n1-ultramem-160 (160 CPUs, 3844GB RAM) Region: Iowa Total available local SSD space 8x375 GB (3,000GB per server) Commitment term: 1 Year Estimated Component Cost: USD 277,868.11 per 1 month

That's far beyond what the record page shows. It appears the record was broken with a single dual-socket Xeon machine. Which is in line with how the previous record (a single 4-socket Xeon machine using older processors) was broken.

In terms of electricity.

Or how much would it have cost someone who doesn't work at Google.

25 servers, 121 days, 170 terabytes of data.

And then the real question, was it really WORTH it?

25 virtual machines (they say). The record page shows that the hardware was a single dual-socket Xeon machine. That screengrab doesn't show anything about virtual machines, and it is unclear to me that you would need such an arrangement since the software is fully multi-threaded.

It isn't really anything earthshattering, Peter Trueb used a 4-socket Xeon system with E7-8890 v3's to get the previous record. Emma took 16 more days (15% more) than Peter to do the calculation, and I assume the processors were 2 years newer. Based on that, I don't believe it would require anything radical to get ~50% more digits.

In terms of electricity.

Or how much would it have cost someone who doesn't work at Google.

25 servers, 121 days, 170 terabytes of data.

And then the real question, was it really WORTH it?

25 virtual machines (they say). The record page shows that the hardware was a single dual-socket Xeon machine. That screengrab doesn't show anything about virtual machines, and it is unclear to me that you would need such an arrangement since the software is fully multi-threaded.

It isn't really anything earthshattering, Peter Trueb used a 4-socket Xeon system with E7-8890 v3's to get the previous record. Emma took 16 more days (15% more) than Peter to do the calculation, and I assume the processors were 2 years newer. Based on that, I don't believe it would require anything radical to get ~50% more digits.

Update: it seems that the software itself is not new. The programmer mentioned the use of y-cruncher.

The Japanese page cited does not actually have any further details. It does have some general information about Pi and describes the man's earlier 5 trillion digit record, which was done with software called the y-cruncher. It is extremely likely that the new 10 trillion digit record is computed with y-cruncher as well, which seems to be corroborated by the fact that the author posted on the xtremesystems.org forums about it.

While Shigeru Kondo (ja0hxv) is a programmer, the author of the pi calculating software is actually Alexander Yee.

APL rocks when your floating point addition latency exceeds your main memory fetch latency and your programmers don't mind that the trig operators are selected by manifest constants on the left side of the circle operator.

Itanium is trying to fit the niche where SIMD is not applicable, yet arithmetic instruction density is high relative to memory transactions.

I spent too much time last night reading about big constants. y-cruncher is sick. It's also not open source, and the core algorithm (Hybrid NTT multiplication, which finds a nice niche between FFT and SS) hasn't been published. There are, however, some highly-tuned Linux binaries for common architectures.

Announcing 5 trillion digits of Pi!

From the FAQ:

Unlike the majority of compute-intensive applications, y-cruncher does not exclusively use floating-point. As of v0.5.4, only about 30% of a Pi computation is floating-point bound. The remainder of the time is spent on integer operations and stalling on memory access. [my bold] So cutting that 30% in half yields little overall speedup. Speeding up the code in this manner exposes more memory bottlenecks - which ends up reducing the speedup to only 10%...

Integer operations can be largely be emulated using floating-point (albeit with overhead). But most of the integer work involves carry-propagation, so it is not very vectorizable. For now, integer operations are still faster using the normal integer instructions.

I'm sure the program would find some love the 54MB on-chip cache, but the Itanium instruction set would only be a burden, and stalls would be horrendous.

Why does y-cruncher create more threads than I tell it to use?

[] Because of the nature of some of the algorithms, I find it necessary to spam threads in order to maximize multi-core efficiency.

The cool thing about this program is that it scales nearly linearly in number of cores, and overscheduling doesn't impact it much if the aggregate memory bandwidth can be supported.

Can you make a CUDA version?

The memory bandwidth between the GPU and main memory will almost certainly be a bottleneck. This isn't a problem for small computations that will fit entirely into GPU memory, but small computations isn't the point of y-cruncher.

Cancel the love for 54MB of on-chip cache. That about cancels the love for the entire architecture. What might rescue the iBerg someday is an optical memory interconnect, if they're looking to blow another $4b burning a hole in the other pocket.

Better still:

• Sze's announcement (greater longevity version [possibly])
• Previous 1 quadrillionth (lone-)digit record
• New 5 trillion consecutive digits record (additional details

Better still:

• Sze's announcement (greater longevity version [possibly])
• Previous 1 quadrillionth (lone-)digit record
• New 5 trillion consecutive digits record (additional details

Anyone else notice what seems to be the legs of a skirt-clad girl at the top of the screenshot in the article? The researchers must have been awfully lonely those 90 days.

If you want to prove that all the digits are correct, you only have to check a few things:
1. There is a sound mathematical proof that the algorithm used in fact does generate the digits of pi, and
2. The algorithm was coded correctly. This should be even easier to check, though likely more tedious.

No, that isn't practical or sufficient, and it's not how they actually did it. Proving nontrivial pieces of software to be correct is basically impossible, and really you'd also need to prove that the compiler was correct, the CPU was correct, etc. -- in fact, computation of pi is often used as a test of new hardware.

Some typical methods that give good confidence in such a calculation:

1. You're calculating pi using a series approximation. These series approximations typically come in families, with different series in the same family being implementable with the same algorithms and having similar performance. You calculate it using two different series, and verify that both series give the same result.

2. You verify an identity. A typical example (which would not be practical for the actual calculation described in the article) would be to calculate tan(pi/4) using the Taylor series for tan(x), and verify that it equals 1.

3. There are algorithms that can compute the nth digit without computing digits 1 through n-1. You can check selected digits against that.

They actually used method 3 plus some other methods.

Direct link to the hardware (with photos)!

Also, anyone else also notice the partially cropped off friend, it's not Clippy, on the final result screenshot?

This page has more details, what I find interesting is that he needed 96.0 GB of ram to do the number crunching.