Calcolo del Pi greco, dalla Svizzera un nuovo record del mondo

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/scienz...ndo_99906.html

In Svizzera dicono di aver stabilito un nuovo record mondiale nel calcolo del Pi greco. Con oltre 62.800 miliardi di decimali è stato superato il precedente record di ben 12.800 miliardi di cifre.

Click sul link per visualizzare la notizia.

[omerook]

ma quanto pesa un file ti testo con 68 miliardi di caratteri?

[turcone]

dovreste specificare che il record del 2020 è stato fatto da un utente con hardware casalingo senza sovvenzioni mentre questo e quelli precedenti erano tutti fatti da grandi aziende con moltissime risorse

[nonsidice]

Originariamente inviato da turcone

dovreste specificare che il record del 2020 è stato fatto da un utente con hardware casalingo senza sovvenzioni mentre questo e quelli precedenti erano tutti fatti da grandi aziende con moltissime risorse

Sarebbe curioso sapere che hw ha usato l'utente e quanto ci ha messo

[MikTaeTrioR]

ottimo chia farming setup...

[Qarboz]

Originariamente inviato da omerook

ma quanto pesa un file ti testo con 68 miliardi di caratteri?

Se in ASCII puro o in UTF-8 occupa esattamente 68 GB. Ma il numero trovato ha 62.800 miliardi di cifre, quindi parliamo di 62.8 TB di pi.txt (mi piacerebbe vedere "la faccia" del blocco note quando si tenta di aprire un file del genere, penso preferisca suicidarsi... ) Ma se espresso in numero (non in testo) occorrerebbe un long-long-long-(da ripetere n volte)-real, ed occuperebbe molto meno dei 62.8 TB

[omerook]

serviranno 108 giorni anche per aprire il file di testo!
potrebbe essere una nuova competizione da WR

[WarSide]

Originariamente inviato da omerook

serviranno 108 giorni anche per aprire il file di testo!
potrebbe essere una nuova competizione da WR

Gli editor solitamente non caricano in memoria tutto il file. Sarà rimasto solo notepad.exe a caricare tutto il file in memoria prima di visualizzarlo

[Unrue]

Mi piacerebbe tanto sapere come cavolo fanno a gestire un numero con così tanti decimali, dal punto di vista dei tipi di dato usati, dal momento che oltre il double non conosco altri tipi di dato con più precisione.

Avranno usato una cosa customizzata immagino.

[WarSide]

Originariamente inviato da Unrue

Mi piacerebbe tanto sapere come cavolo fanno a gestire un numero con così tanti decimali, dal punto di vista dei tipi di dato usati, dal momento che oltre il double non conosco altri tipi di dato con più precisione.

Avranno usato una cosa customizzata immagino.

Per avere un'idea, dai una occhiata a https://en.wikipedia.org/wiki/PiHex . Il programma è vecchiotto, ma i sorgenti sono open source e puoi vedere come hanno implementato l'algo di Bellard per il calcolo delle cifre.

[Sp3cialFx]

Originariamente inviato da Unrue

Mi piacerebbe tanto sapere come cavolo fanno a gestire un numero con così tanti decimali, dal punto di vista dei tipi di dato usati, dal momento che oltre il double non conosco altri tipi di dato con più precisione.

Quadruple, octuple, extended precision, arbitrary precision decimal...

Prendila come occasione per approfondire. Se hai a che fare con i soldi ad es. dovresti usare un arbitrary precision decimal al posto che un double.

[Unrue]

Originariamente inviato da WarSide

Per avere un'idea, dai una occhiata a https://en.wikipedia.org/wiki/PiHex . Il programma è vecchiotto, ma i sorgenti sono open source e puoi vedere come hanno implementato l'algo di Bellard per il calcolo delle cifre.

Ottimo, grazie

[acerbo]

Originariamente inviato da omerook

ma quanto pesa un file ti testo con 68 miliardi di caratteri?

compresso pochi Kb

[GabrySP]

il pi greco non si può comprimere per definizione

un file di testo composto di sole cifre casuali lo comprimi al massimo di un fattore:log2(10)/8

68 miliardi di caratteri -> 28 miliardi di byte

[randy88]

Originariamente inviato da nonsidice

Sarebbe curioso sapere che hw ha usato l'utente e quanto ci ha messo

C'è scritto.
L'attuale record è stato 3,5 volte più veloce di quello del tizio provato nel 2020

Quindi a grandi linee, 108 x 3,5 = 378

Ci ha messo un pò più di un anno.
Sull'hardware, leggendo in giro ho scoperto che il tizio si chiama Timothy Mullican, e questa è la sua lista hardware:

HP PROLIANT DL580 Gen8
This server (Ubuntu 18.10) performs the Pi computation. The final compressed Pi digits will be transferred to the Dell R720xd via a cifs-mounted directory (/drives/main_output).
(4) Intel Xeon E7-4880V2 2.5GHz 15C/30T CPU
320GB DDR3 PC3-8500R ECC RAM
(5) 2.5” 100GB SATA MLC SSD (RAID 6)
(4) 6Gb LSI 9207-8e Dual Port SAS HBA
Connected to each HPE D3600 disk shelf via single SFF-8088 to SFF-8644 cable 2m
Intel 10-Gigabit X540-AT2 Dual Port Ethernet Adapter
Dedicated link to Dell R720xd for Veeam backups
Intel 1-Gigabit I340-T4 Quad Port Ethernet Adapter
Connection to the Internet
(4) HP StorageWorks D3600
These drives are used to perform computations in lieu of server memory (known as y-cruncher Swap Mode7) to provide the resources required to calculate Pi (mounted on the DL580 as /drives/1 - /drives/48). I originally used HP StorageWorks D2600 disk shelves, but I didn’t realize the SATA backplane was limited to 3Gb/s. I upgraded to the D3600 disk shelf which supports 6Gb/s SATA in June of 2019.
(12) 3.5” 6TB SATA 7.2K HGST Ultrastar He8 HDD (JBOD)
Dell PowerEdge R720xd
This server (Windows Server 2016) serves two primary purposes. First, it is connected to the HP tape library. A Veeam job is manually run each month, which backs up data from the 48 drives running the Pi computation directly to tape. Second, it has an additional RAID6 storage volume (see Dell PowerVault MD1200) which will contain the 50 trillion compressed Pi digits.
(2) Intel Xeon E5-2670 8C/16T CPU
128GB DDR3 ECC RAM
(2) 2.5” 600GB SAS 10K Seagate HDD (RAID1)
Emulex LPE 12002, Dual Port 8Gb Fiber Channel HBA
Connected to tape library using (2) LC-LC OM3 2m fiber cables
Dell PERC H810 Adapter 6Gb RAID Controller Card
Connected to Dell MD1200 disk shelf
Dell PowerVault MD1200
These drives will contain the compressed Pi digits that y-cruncher generates at the end of the computation.
40TB (RAID6)
(7) 3.5” 4TB 7.2K SAS HGST Hitachi
(5) 3.5” 4TB 7.2K SAS Seagate Constellation ES.3
HPE StoreEver MSL4048 Tape Library
This tape library will contain monthly backups of the forty-eight computation drives.
LTO-5 FC Tape Drive
(47) LTO Ultrium 5 Tape Data Cartridge 1.5TB

[AlPaBo]

Originariamente inviato da GabrySP

il pi greco non si può comprimere per definizione

un file di testo composto di sole cifre casuali lo comprimi al massimo di un fattore:log2(10)/8

68 miliardi di caratteri -> 28 miliardi di byte

È più interessante calcolare quanto sarebbe lungo in forma di testo scritto.
Con circa 6800 caratteri per pagina (in realtà spesso un po' di meno), sarebbero 10 miliardi di pagine. Con tomi da 500 pagine (piuttosto grossi), si avrebbero 20 milioni di volumi, paragonabile alle più grandi biblioteche attuali.

Non male, direi.

(l'unico scopo di questi esercizi è testare l'hardware e il software, è inutile in fisica e ingegneria: per stimare la circonferenza dell'universo noto con una precisione migliore della lunghezza di Planck basterebbe sapere le prime 60 cifre decimali di Pi greco...)

[Blackxx]

chiunque può battere il record aggiungendo numeri a caso tanto per verificare se siano corretti o meno qualcun'altro dovrà fare i calcoli e nel frattempo ti godi il "primato" fake

[randorama]

mi domando lo scopo.

[joe4th]

Mi sembra un'esagerazione lo storage. Per quel che sapevo esistono degli algoritmi in grado di calcolare l'n-esima cifra decimale di pigreco, senza dover calcolare tutte le altre. Quindi in teoria anche noi lettori di hwupgrade, oragnizzandoci un po' e distribuendo i calcoli, potremmo partecipare al contest e partire calcolando dalla 62800 miliardi e 1 esima cifra decimale. Poi in qualche modo si fa il "paste" dei risultati.

[TheAle]

Originariamente inviato da Qarboz

Se in ASCII puro o in UTF-8 occupa esattamente 68 GB. Ma il numero trovato ha 62.800 miliardi di cifre, quindi parliamo di 62.8 TB di pi.txt (mi piacerebbe vedere "la faccia" del blocco note quando si tenta di aprire un file del genere, penso preferisca suicidarsi... ) Ma se espresso in numero (non in testo) occorrerebbe un long-long-long-(da ripetere n volte)-real, ed occuperebbe molto meno dei 62.8 TB

E se avessero codificato solo le cifre da 0 a 9? Per ottenere 10 valori basterebbero 4 bit per carattere ossia 31,4 TB totali.