clavigne

> However, when an entire program consists of a single chain of dependent instructions, which may happen e.g. when computing certain kinds of hash functions over a file, you are doomed. There is no way to increase the performance of that program.

Even in that case, you would probably benefit from having many cores because the user is probably running other things on the same machine, or the program is running on a runtime with eg garbage collector threads etc. I’d venture it’s quite rare that the entire machine is waiting on a single sequential task!

The Nissan versa is like the last cheap car.

The Chevy Spark is dead.

The Mitsubishi Mirage is dead.

etc.

Car thieves have been using antennas to remotely trigger the keyless entry to great success here in Canada. Many people leave their keys on their doors so you just need to put a range extender against the door and scan cars in front until one of them opens.

> I'm not talking about whether the scheduler can block the task on IO. This is trivial.

The whole point of coroutines is that they are trivial to block and resume, right? So the way to deal with limited resources... is to block on them.

So when you need a connection, you await until one from the pool becomes available. From the point of view of the consumer it's very natural because grabbing a connection is just a standard async call, and returning it to the pool can be done the same way you would usually close it. If anything, it's a lot easier to manage them like this because unlike in a non async program you don't have to worry too much about blocking progress.

We use it at work to send FSMs over the network for distributing tasks. Admittedly we always do this with continuations that haven't started yet, but there is no technical reason we couldn't serialize the already started ones (although you'd have to make sure you also send the coroutines you are currently awaiting on.)

Scala async coroutines build FSMs that are just standard objects. They aren't very commonly used, but the same approach could probably be adapted to C.

Basically the compiler compiles async function to a very simple FSM object where each assignment to a local variable that lives longer than a yield point becomes a member of the FSM object. This is done after the transformation to a simple normal form, at which point the function basically looks like bytecode. The compiler generate a new class for every async coroutines.

The generated FSM classes are statically sized so they could in principle be stack allocated, and their instances can be manipulated like any other JVM object.

At $work we have a system using scala async that has all of these features (arrays of FSMs, serialization, distribution by sending to network etc.) Of course there are complications (file handles for example) and it's easier with a GC.

For context, I came across this because I was interested in how they came to acquire the Twitter four-letter twitter handle @meta, which I wrote about here

https://twitter.com/cyri77e/status/1453886080789405707

Turns out it's harvested from the Meta company linked here that the Chan Zuckerberg Initiative acquired. Before that the @meta handle was held by an early twitter user fro. Turkey.

This is basically the unremarkable story of the "been on Twitter since 2010" profile with handle @meta.

I don't think it would be a good idea, given that you'd have to claim the winnings. It might work once or twice but not over and over again.

Additionally in most cases I'd think the lottery odds would be lower than the cost of traditional laundering (smurfing, through crooked banks, using cash based businesses like taxis etc.) Especially if you have to pay people to buy tickets.

The more renewable energy that is built, the cheaper it gets.

We now know that there is a cartel of US miners trying to create "clean" bitcoins (in part to appeal to Tesla and Musk) that will sell at a premium.

https://www.bbc.com/news/technology-57240090

This could increase the pricing differential between clean and dirty electricity sources. However, most utilities don't care and so will buy the cheaper electricity, which means that there won't be a significant push to decrease fossil fuel based generation.

Unless demands from bitcoin mining start to strain clean electricity generation, there isn't really much reason to build more renewable capacity either. The kind of thing described in the OP (the repurposing of existing facilities) is likely to be the main result for the foreseeable future.

"Clean" bitcoins are just "greenwashed" bitcoins.

which is basically admission that they will API it, not release the models... again.

The original version on github can only compute the specific systems in the paper.

https://github.com/deepmind/deepmind-research/tree/master/al...

I don't know why scientific publications keep doing PR work for them.

Here is pattern matching as a library that is not built using statements,

https://github.com/santinic/pampy

Clearly it's possible. It's also more ergonomic than PEP 622.

I guess it comes down to whether one does the cost benefit analysis for society as a whole or for individuals.

While decentralized permissionless markets can (and have) helped some individuals escape economic restrictions (capital controls, sanctions, etc.) it's not at all clear to me that they have had an overall positive effect, or ever will.

At the end of the day, the rise in the price of bitcoin, scams like AfriCrypt and OneCoin, the new Salvador laws etc are all just new means of extracting capital from the Global South. I'm of the opinion that the benefits to individuals are not balancing the overall societal harms, but I could see how someone with a more individualistic ideology would disagree.

So first, investing in DEFI is not exactly simple. If I am reading it properly, you lose 20% in fees at least if you buy bitcoin with Madagascar dollars on paxful,

https://paxful.com/buy/bitcoin/madagascar

How many more hoops do you then have to jump through to acquire fake stocks?

Second, you then have to make sure you avoid pyramid schemes (like OneCoin), rug pulls, exit scams, bad exchanges and bad "smart" contracts (like the Parity bug).

This is not easy even for highly informed tech workers in the Global North. Now if you happen to speak another language (as I do) I recommend you go and Google "how to invest in Defi" or whatever in it. In my case (French), you get just articles after articles that are sponsored content from very dubious sounding wallet and exchanges, especially if you add "Madagascar" or "Congo" or whatever to your search.

So frankly, I think the idea that "crypto markets are great for the Global South" is more of a convenient story.

The majority of people have wealth in real estate and generate income from wages, both of which are inflation neutral.

In contrast, the rich are much more likely to have bonds or cash holdings. They are the ones for whom inflation is a real problem. Why else would all this political pressure for a 2% inflation target exist? It's because that's low enough for the rich, not because it's high.

Printing money and redistributing it would severely impact capital holders, like it did in the post WWII boom which created the middle class.

Here is an entire book on this topic :

https://en.m.wikipedia.org/wiki/Capital_in_the_Twenty-First_...

That's been the problem with the Google result too, even though they did have "controlled" operations. They basically showed that a quantum computer doing random operations has an output that is difficult to predict with classical simulation.

It also solves no problem at all. They tried to shoehorn into the paper a "CSRNG" application but it's dubious at best if you have any kind of cost constraint.

Yeah that's what I mean. This is the case for both commercial software (eg Q-Chem) and free software.

This is not to say that the boot time is always a problem, there are plenty of applications in which it doesn't matter at all (as you point out). However that's not always the case (by a long shot) which is why tools like GNU Parallel and snakemake exist.

why? I commonly do things like screen 10,000 molecules for some property by calling a Fortran program 10k time. If each run takes 60s of compute, the 10s boot from Julia (over the nfs disk) would be pretty significant.

Using Julia in this case basically means having to rewrite all of the other programs into it and getting rid of eg snakemake or gnu parallel or any number of other very common HPC workflows.

In fact I'd venture that doing a sequence of things many times is just as common an HPC workload than single jobs running for very long times.

The wavefunction of an n qubit system is representable by a 2^n vector of complex numbers [1]. Using single precision floats [2], a 10 qubit wavefunction is 8 KB, 20 qubit = 8 MB, 30 qubit = 8 GB and 40 qubit = 8 TB.

Hence a run-of-the-mill laptop can easily simulate a perfect 30 qubit computer, provided you are using a sufficiently performant simulator (such as https://github.com/qulacs/qulacs ).

[1] This is actually a pessimistic upper bound for the classical simulation because current quantum hardware is not fully connected and not fully coherent.

Most problems of interest (optimization, chemistry etc) also do not ever generate fully entangled wavefunctions and so can be simulated with significantly less resources.

So for any applications (beyond simulating quantum advantage experiments built specifically to make classical simulation hard), classical computers are crushing quantum computers.

[2] Because QM is a linear theory, numerical precision isnt an issue, as it would be in a chaotic classical simulation of eg fluid dynamics.

> One guy went on for like fifteen minutes about how much he hated open office plans.

Does this guy have a patreon?

Correct.

There is a lot of arguments around that quantum computing will scale in a Moore's Law way (wrt qubits, so doubly exponential in compute power) and thus will be useful in the near future.

These are extremely optimistic.

Quantum computing hardware just came out of academic lab in the last few years and was subjected to actual engineering, hence the massive growth in capabilities. However these were mostly the result of solving all kind of low hanging fruits. To give an example of what I mean, I talked to a physicist doing superconducting qubit work at a conference in 2015 and at the time the cavities used to hold qubit wavefunction where machined by the Dept machine shop, using a mill. He told me they would just keep making them until they had enough that were of sufficient quality for computation. If I remember properly something like 1 was kept and 20 thrown. Using proper manufacturing can get you a lot farther but...

It's unclear how far, and modern (non quantum resistant) encryption would require thousands of time more qubits to solve on QC than are currently there.

https://www.technologyreview.com/2019/05/30/65724/how-a-quan...

re-running is definitely too much work for most scientific papers, at least in ML and computational sciences were experiments might take 1000s of core-hours or gpu-hours, but that's usually not necessary. In addition, just running the code can spot really bad problems (it doesn't work) but easily miss subtle ones (it works but only for very specific cases).

I think it's more important for reviewers to read the source, the same way one would read an experimental protocol and supplementary information, mainly checking for discrepancies between what the paper claims is happening and what is actually being done. In the above example, a reviewer reading the code would have spotted that the model isn't there at all, even though it runs fine.

So I guess LLVM has rather poor fortran support, but zig fortran compilation would be really neat for all kind of scientific programming purposes.

Being able to call fortran code from zig as easily as one can call C libraries would also make it a really nice way to wrap fortran libraries into lightweight static programs.

see the (current) top comment

https://news.ycombinator.com/item?id=27244810

it's a very clever use of symmetry.

I did peer review for a number of scientific papers that include code. Almost every time, I was the only reviewer that even look at the code.

In most cases, peer reviewers will just assume that authors claiming the "code is available" means that a) it is reproducible and b) it is actually there.

As a counter example, this recent splashy paper

https://www.nature.com/articles/s41587-021-00907-6

claims the code is available on github, but the github version ( https://github.com/jameswweis/delphi ) contains the actual model only as a Pickle file, and contains no data or featurization.

So clearly, the peer reviewers didn't look at it.