Calculating a record-breaking 31.4T digits of Pi with GCP • Hacker News Board

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#61

Post by frutiger » Thu, Mar 14, 2019, 1:47 PM UTC

klohto wrote: post #46

WilliamEdward wrote: post #34

Earlier quoted context omitted.

Whether there's a use for 40 digits or 40 trillion digits, needing more accuracy is not why we find these numbers. There's no 'need' for this at all. The same way there's no 'need' to find bigger prime numbers. We're just seeing how far we can go, maybe seeing a new pattern emerge.

> The same way there's no 'need' to find bigger prime numbers. From cryptography standpoint, there is always a need to find bigger prime number. I wouldn't compare this with a Pi.

How does finding a bigger prime help or hinder cryptography? And with many forms of cryptography (e.g. DH kex, ECC) primes only enter as the modulus of the modular arithmetic where being larger is usually not particularly helpful.

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#62

Post by shawabawa3 » Thu, Mar 14, 2019, 1:53 PM UTC

YayamiOmate wrote: post #26

dcow wrote: post #6

Earlier quoted context omitted.

That’s not quite how it works.

Why not? It is. Calculating pi is trivially parallelizable. If you wrote good kernels, calculation distribution could be exactly the same.

Blockchains that perform computation (e.g Eth), aren't doing parallel computation as we think of it.

They perform the same computation on every node, there's no way to split up the work between nodes

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#63

Post by yjftsjthsd-h » Thu, Mar 14, 2019, 1:55 PM UTC

triodan wrote: post #16

geekuillaume wrote: post #9

I'm curious, did someone estimate how much it would cost to replicate this experiment on GCloud with the same infrastructure?

Using GCP's pricing calculator and the specs described in the blog, it's around 170,000 USD to run it for 3 months. https://cloud.google.com/products/calculator/#id=ef2329f6-f1...

If you can break it into appropriate jobs that can handle interruptions, you should use interruptible instances to save money. And you really need to be able to handle that anyway in case an instance fails midway.

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#64

Post by yjftsjthsd-h » Thu, Mar 14, 2019, 1:57 PM UTC

dekhn wrote: post #58

megaremote wrote: post #42

Does pi compress? It must if it is only numbers, but only by a half?

pi is effectively randomly distributed (I don't know if this is proven) which means it would be effectively impossible to compress is using conventional entropy or dictionary based techniques. However, there are compact formulas which can generate pi to arbitrary precision, trading off compute time with space. So it;'s effectively compressible, I guess this relates to Kolomogorov complexity in some way.

If it's stored as ASCII/UTF8 text, then it will be compressible because it's just numbers. On the other hand, if they somehow have a number format that spans that many digits then it'll already be perfectly efficient.

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#65

Post by benchaney » Thu, Mar 14, 2019, 1:58 PM UTC

klohto wrote: post #46

WilliamEdward wrote: post #34

Earlier quoted context omitted.

Whether there's a use for 40 digits or 40 trillion digits, needing more accuracy is not why we find these numbers. There's no 'need' for this at all. The same way there's no 'need' to find bigger prime numbers. We're just seeing how far we can go, maybe seeing a new pattern emerge.

> The same way there's no 'need' to find bigger prime numbers. From cryptography standpoint, there is always a need to find bigger prime number. I wouldn't compare this with a Pi.

Finding bigger prime numbers has no impact on cryptography at all.

The large prime numbers needed for cryptography are a few hundred digits long. The are generated by picking a random numbers and checking it’s neighbors for primality.

The largest prime numbers that have been discovered have millions of digits. Finding a larger prime would have no effect whatsoever on our ability to quickly generate primes with a few hundred digits.

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#66

Post by maxst » Thu, Mar 14, 2019, 1:58 PM UTC

Are the some PI-like constants, but much harder to calculate? Like even a million digits would be hard to calculate?

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#67

Post by dekhn » Thu, Mar 14, 2019, 2:00 PM UTC

yjftsjthsd-h wrote: post #64

dekhn wrote: post #58

Earlier quoted context omitted.

pi is effectively randomly distributed (I don't know if this is proven) which means it would be effectively impossible to compress is using conventional entropy or dictionary based techniques. However, there are compact formulas which can generate pi to arbitrary precision, trading off compute time with space. So it;'s effectively compressible, I guess this relates to Kolomogorov complexity in some way.

If it's stored as ASCII/UTF8 text, then it will be compressible because it's just numbers. On the other hand, if they somehow have a number format that spans that many digits then it'll already be perfectly efficient.

Um, sure. But I don't think anybody really cares if pi is compressible because it's ASCII representation of numbers. At best, you'd be getting some constant factor improvement due to the unused bits, but there's nothing specific to pi in that.

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#68

Post by yjftsjthsd-h » Thu, Mar 14, 2019, 2:01 PM UTC

isostatic wrote: post #29

s_gourichon wrote: post #22

Earlier quoted context omitted.

Yes. ISO chooses year-month-day, which puts largest component first and smallest last. This has the nice benefit that treating it as a string and doing alphanumerical sort matches the actual day sort. Ref. https://en.wikipedia.org/wiki/ISO_8601

There are benefits to both little endian and big endian

Yes, but the US uses middle endian.

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#69

Post by fghtr » Thu, Mar 14, 2019, 2:01 PM UTC

StreakyCobra wrote: post #25

smarx007 wrote: post #7

How Many Decimals of Pi Do We Really Need? (NASA/JPL): https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimal...

In short 40 is already crazy too many digits for most if not all applications. Yet in the original article they say «Granted, most scientific applications don’t need π beyond a few hundred digits, …». Is there scientific applications where they would really need more than 40? Or is it just the author making some guess?

>Is there scientific applications where they would really need more than 40? Or is it just the author making some guess?

It is still not clear whether Pi is a normal number or not [0]. Such calculations could in principle give an insight here.

[0] https://en.wikipedia.org/wiki/Pi#Irrationality_and_normality

Re: Calculating a record-breaking 31.4T digits of Pi with GCP

#70

Post by ousta » Thu, Mar 14, 2019, 2:07 PM UTC

aaaaaaaaaaab wrote: post #32

Meh, throwing raw power at the problem is not that impressive. Bellard's [1] 2009 record was much more impressive, because he used a clever formula to break the existing record with a mere (albeit beefy) desktop computer: https://bellard.org/pi/pi2700e9/ The record he broke with his desktop PC was made using a supercomputer cluster. [1] If somebody is not familiar with him, he is also the original author of QEMU, ffm…

I struggle to see any complexity into google approach - unlike bellard's one that is an amazing feat.

They basically pulled more machine to compute more. nothing really impressive. pretty much any dev with that computing power could have done it