Hacker News Reader

Hacker News

Comment by JumpCrisscross | Hacker News Reader

Parent Full thread

JumpCrisscross

Out of curiosity, what fraction of the Bitcoin network’s computing power would solve this computation wall?

View on HN

Zero. All the Bitcoin network can do is compute SHA-256 hashes. It's literally useless for anything else.

I think they might mean the raw computational power (excluding ASICs).

Dunno, how much memory and storage does the network have?

The CERN grid currently[1] has 1 EB of storage and 750k of CPUs, and that pushes out 2 million jobs per day. From own experience of one of the 162 sites, you have something like 6 GB of ram per CPU core, and often jobs need more than that so that in practice you are memory bound.

[1]: https://indico.cern.ch/event/466934/contributions/2524828/at...

They also have 0 GPUs. (I visited there a couple of weeks ago and talked to them, among other things, about this challenge).

Maybe they could issue Cerncoins, one issued for each particle traced. Then if they went up in value the miners could switch to that.

Is there even a bound on the computational power we'd need to make an advancement here?

> Although these techniques would be able to work out the paths even after the upgrades, “the problem is, they are too slow”, says Cécile Germain, a computer scientist at the University of Paris South in Orsay. Without major investment in new detector technologies, LHC physicists estimate that the collision rates will exceed the current capabilities by at least a factor of 10.

Sounds like the LHC’s physicists have an idea.

No, but CERN Is known to be careful with their PR. Presumably, and this is just my intuition speaking, a big enough cluster of computers would solve this, but they're taking an opportunity to experiment with different techniques and methods for this experiment, and that's pretty much it.

If CERN had an unlimited budget, I suspect they'd do it however they did it before.

This is not a problem that can be solved just by throwing more compute resources at it. It's not as simple as simply having too much data to process, the real issue is that each detector has a time resolution that goes down to about a nanosecond. If you get one collision per nanosecond then it's pretty straight forward to associate every one of the (possibly) million detector hits to a single event and reconstruct it accordingly. The issues arises when you have more than one event (i.e. collision) within each nanosecond window. You end up with detector readings for each event overlapping each other without a simple way of disambiguating them. This is called "pile up".

When I last worked there in 2015 a typical pile up situation was having about 50 collisions per detector reading. It is no simple problem to simultaneously reconstruct 50 collisions from the same set of overlapping detector measurements.

From what I've heard, the amount of pile-up ATLAS and CMS can handle is limited by the CPU time it takes to reconstruct events, which can be alleviated by throwing more resources at it, but it is much better to develop quicker reconstruction algorithms.

Towards the end of last year, they had to start levelling the instantaneous luminosity to 75% of what they could achieve,† primarily to reduce the load on the grid.

† Edit: the maximum peak luminosity is still 200% of the design value, so the performance is beyond initial expectations.

To be fair, 50 PU is above design peak luminosity, much less mean. And I'm sure I've seen plots from both ATLAS and CMS at the end of LS1 that show improvements in the processing time at 100 PU by factors of roughly 10.

Just to insert the usual analogy, if a single collision is the proverbial smashing of two clocks, and then trying to discern their makeup from the wreckage, this is akin to smashing dozens of clocks at the same time. How can you tell where one gear fragment was meant to fit when it’s such a mess?

One thing that might help is that the collision vertex is slightly different each time. If you already had all of the tracks reconstructed, you'd find that you could point them together into n different centers of mass from which they originated.

Vertex finding is the first step in most track reconstruction algorithms. But it's still very difficult. The number of trajectories that can be formed from discrete points blows up combinatorically. When you have hundreds of thousands of points you usually don't end up with a few easy to find vertices.

This is already what happens. The problem is that forming tracks and vertices becomes much harder as the number increases.

Reply on news.ycombinator.com