Hacker Newsnew | past | comments | ask | show | jobs | submit | more phpnode's commentslogin

The US Air Force ran a war game. While the war game was in progress the Chinese Military ran a war game of their own, simulating a series of attacks on Taiwan. The timing appears to be unrelated, I suppose the article mentions them to draw attention to the escalating tensions in the area.


Huh. Makes me think about two adversaries agreeing to run a simulated conflict in order to correct any of the opponents misconceptions that could lead to accidental escalation.


All it takes is for the US and EU to ban cryptocurrency itself and the problem goes away. It doesn't matter if mining is done in countries beyond their borders because the demand will go through the floor and those countries will have no incentive to keep wasting energy on it.

The idea that cryptocurrency is beyond government control is fundamentally wrong. Most people don't want to be criminals.


Yes, they could block the fiat pipes out instead of the crypto pipes in. Even if it wasn’t a perfect plug, it would devastate the prices and might cause the whole industry to unravel.


The problem with making this bet is that the value of the underlying crypto can move by far more than the possible 15% return while the result is pending.

2 months is more than enough for the price to double or halve and people want to be able to exit to fiat at a moment's notice when they think things are heading south.


Poly.Market which he mentions (and where I bet on the US election) just uses a stablecoin (USDC) pegged to the US dollar. Same situation for the DAI he mentions he used. So this is an already solved issue.


I've used Poly.market a few times and been pretty happy with it - they use a second layer network, so after depositing, trades are fairly cheap (you just pay a market maker fee, no crypto miner fee as far as I can tell). Downside is that the outcome is provided by the poly.market creators, but your actual bets are non-custodial.


The fees were quite expensive before they started using Matic.


Pretty much all the crypto betting protocols use stablecoins (mostly pegged to the $), people arent betting in eth/btc. Vitalik placed bets on https://catnip.exchange/ so would have been in dai.

Also on the topic of stability, Rai launched this week so we now have non-pegged stable assets backed by eth -> https://www.reflexer.finance/


I mean for anyone who wants to use BTC any anything other than an investment vehicle this is how it’s gonna be. BTCs value to non-currency speculators is as a settlement layer of last resort for people that can’t access or don’t want to use foreign exchange markets. You want to get in, do your transfer, and go back to fiat as fast as possible specifically because of the volatility.


There are cash-based markets like Predictit where you could've made a similar bet. Predictit charges 5% withdrawal fees + 10% of profits, but if you expect a 15% ROI, it's still profitable.


The fiat-based prediction markets tend to limit the number of people in a particular markets, the size of positions in the market, and a number of other aspects of the market in a way which make it difficult to seize apparent opportunities and to limit the possible returns from doing so, even before considering the way that their fees eat up returns.


These limits are because the ones you're thinking of are research projects, not in fact betting markets (even though as an individual you can treat them as betting markets just fine). This makes them accessible (legally) to US residents.

Betfair is a British gambling firm, and isn't a research project, when Betfair's "Did Donald Trump win the US presidential election?" and "Did Joe Biden win the US presidential election?" closed it had hundreds of millions of pounds of bets across those two questions.

I got paid, as in I put cash in and a couple of weeks later more cash was paid out to my bank account when BetFair closed it, for knowing that Donald Trump did not win that election in December.

It was even possible (though of course risky) to buy the lows and sell the highs as MAGA rallied when they thought the Kraken had been released, or when Rudy was going to prove everyone wrong, or whatever other nonsense.

I was actually underwater for more than 50% of the two weeks between placing my "bet" and the cash returned, because MAGA were bidding up the "Donald Trump won" position even as it became increasingly obvious that they'd lose everything.


PredictIt didn't have this anomaly where Trump had a 15% chance of winning. After Georgia called the election the percentage went above 95%.


Oh, it definitely did. Maybe not to the same degree as the crypto markets (never looked at them), and there were certainly spikes this way and that, but you could get Trump NO cheaper than 90c well into December.

The Texas v. Pennsylvania case getting swatted down by SCOTUS was probably the last of the cheap shares where it was worth depositing money just to play, but if you already had some money in your account it was worth taking the obvious bets all the way to the end.

edit: went back and checked one of the markets to refresh my memory. Yep, check the 90-day chart. Dec 6 "NO" on a Republican win was only 84c!

https://www.predictit.org/markets/detail/2721/Which-party-wi...

edit2: here's another hilarious one.

https://www.predictit.org/markets/detail/5554/Will-Donald-Tr...

Yep, "Will Trump win the popular vote" closed on Nov 24th while still trading at 8 cents. The popular vote. Jesus Christ. For reference he lost the popular vote by 7 million.

I'd actually be curious to know if there was a crypto-market equivalent to that one, because I want to believe most of that pricing was due to PI's limits. For example, one Trump bettor maxing out his $850 limit of 7c shares, requires 14 Biden bettors maxing out $850 of 93c bets to be his counterparty. With a 5,000 trader limit that means that there might be just a handful of Trump-won-landslide bettors vs a few thousand No-he-didn't bettors with a lot more invested, all maxed out and unable to move the price further. But I don't know if that shook out differently in the crypto space with no limits.


You are correct, thanks for providing those sources.


The V8 team experimented with "Strong Mode" which was approximately this - a fast subset of JS [0]. The experiment was ended [1]

[0] https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp...

[1] https://groups.google.com/g/strengthen-js/c/ojj3TDxbHpQ/m/5E...


From a quick glance this looks like a further subsetting a la strict mode, which isn't really what I meant

I clarified in another thread, but what I meant to convey is a way of giving very specific hints about specific pieces of one codebase:

"Function X will only ever take two arguments, they will be of types Y and Z"

"This object will only ever have these properties; it will never have properties created or deleted"

"This prototype will never be modified at runtime"

This could guarantee ahead-of-time that certain optimizations - packing an object as a struct instead of a hashmap, for example - can be done, so that V8 doesn't have to spend time speculating about whether or not to JIT something


The problem is less about the annotations (you can already infer most of this from a single pass over the code) than it is about the calls. If you have a reference to a function, you need that data handy. Unless you're copying it around with your function reference, you don't have that data (and it's prohibitively expensive to try).

JS is heavy on function references (closures are one of the most popular JS idioms), so it's not easy to know at call time how you can optimize your code.


>"This object will only ever have these properties; it will never have properties created or deleted"

>"This prototype will never be modified at runtime"

You can already give these hints with Object.freeze/Object.seal

Not really hints though, they enforce a certain behavior. Because hints aren't enough. A JS engine may already assume you'll never change the objects, but it still has to support cases where you then do so anyways.

I don't think these alone would enable any substantial speedups, since the performance issues arise where unknown objects are used.


> You can already give these hints with Object.freeze/Object.seal

You can but my understanding is the performance tradeoffs aren't great unless you have a workload that especially benefits from it. Those calls are expensive.


OK let's say you have f, it only takes arguments a:Y, and b:Z.

I call f(Z, Y). What happens? Does the machine segfault? Probably not.... so you're in "check the types at the callsite" territory. And honestly those kind of boundary checks are the problem, so to speak.

Are we doing static analysis of the entire codebase (a sort of closed-world theory?) You could maybe do something like this for non-exported functions, though at the V8 level that's tough.

I think that there would be possibilities to somehow get systems to be set up in a way to do more cleverness along these lines, but so long as you're taking in stuff from the outside world you end up needing to set up relatively costly checks, relative to the cost of the "default" JS semantics that you're trying to avoid paying.


Isn't that what asm.js did?


Maybe from a certain perspective. But it worked by conforming the bundle to a particular subset of JS that the authors knew to be optimized, instead of expressing information to the interpreter outright. That seems like a comparatively limited channel for communication.


From what I understand, in Safari at least they tried to make many of the optimizations general. So if you use asm.js-style type indications in your code even without following the full spec, you might see some performance benefit.

I have sometimes found a speedup when adding apparently an superfluous |0.


The highly optimizable, explicit and precise code for the interpreter is WASM.

JS VMs don't need more hints from the code. They need guarantees. They already analyze and profile JS, but as long as JS is allowed to be dynamic (and it has to, it won't be JS without it), then they have to keep the complexity and cost of all the extra runtime checks and possible deoptimizations.


AFAICT the v8 JIT collects such information form code's behavior, and uses it to generate efficient machine code.

If v8 could accept Typescript directly, it probably could pass this kind of information to the JIT directly, too. But the input language is ES6 or something like it, and it has to follow the calling conventions of it. I'm afraid that adorning ES6 with this information would be either brittle or backwards-incompatible.


> I'm afraid that adorning ES6 with this information would be either brittle or backwards-incompatible

Like I said above, it could be shipped as separate (optional) metadata files associated with source files, the same way that source maps already work


It can't trust that all the metadata is correct, otherwise security issues can happen. And if you need to do that, why not just gather / regenerate the same information at compile time.

Also, what do you do about code loading? e.g. scripts loaded from other files at runtime, or eval? Does it throw an error if a third-party script uses a function incorrectly? Or do we assume that metadata is local-use only?

There are a lot of things in JavaScript and also the "browser environment" (e.g. ads, third-party scripts) that can limit the utility of traditional compiler techniques.


There are already stepped levels of optimization going on in the JS engine; it goes to great lengths to reverse-engineer whether something can probably be optimized or not, and to handle all the edge cases where it needs to bail out into a less-efficient mode when some assumption is violated. All I'm talking about is a way to give it extra hints about what to eagerly optimize and how. All of that other robustness can stay in place.


Pretty much all that buys you is a small reduction in an already-small warm-up phase before the jit chooses a late-stage optimization (possibly with an increased cost for loading that phase, so even that small gain may be reduced). Only for code that uses this. And performs worse if it proves incorrect, as bail-out logic is generally a bit costly.

Browsers have experimented with hints quite a lot. Nearly all of them have been rolled back, since adding the general strategies to the jit is vastly more useful for everyone, and perform roughly as good or better since they identify the optimization everywhere, rather than only in annotated code.

---

The only ones I'd call "successful" so far have been 1) `"use strict";` which is not really an optimization hint, as it opts you into additional errors, and 2) asm.js, which has been rolled back as browsers now just recognize the patterns.

asm.js did at least have a very impressive run for a while... but it's potentially even more at risk of disappearing completely than many, since it's rather strictly a compiler target and not something humans write. wasm may end up devouring it entirely, and it could happen rather quickly since asm.js degrades to "it's just javascript" and it continues working if you drop all the special optimization logic (which is to its credit - it has a sane exit strategy!)


Missed that, thanks. That could indeed work. It could even nicely dovetail into the Typescript (or Reason, or Elm) compilation process.


it's not named after it, it's just amazon is so massive they have to reuse brand names. AWS has exhausted not only the supply of IPv4 addresses but also the supply of 3 letter initialisms.


I'm wondering how many people are working on Sea Shanty Tech right now


A lot!

FTR, I just re-rendered this Sea Shanty MIDI file into looped video[0] with a 240BPM (original is 120BPM) using MuseScore 3.6[1] app.

Enjoy the song and sing along! ;)

[0] https://twitter.com/app4soft/status/1350904572450123778

[1] https://musescore.org/en/3.6


Blockchain where the proof-of-work is shanties.


it's not "unlearning" anyway, it's just "learning". I'm trying to imagine how many other things this person would have had to "unlearn" in tech since BBC Basic came out.


My very first interaction with a computer was with the BBC Basic command prompt, 30 years ago when I was 7. If it hadn't been so accessible I doubt I'd be a programmer now, so I feel like I owe it a lot!


Just the media


in addition to counting dependents you can also run the graph through pagerank to find the most impactful files to convert first. This strategy is useful when converting codebases from JS to TS too because it's common to incorrectly type a file when it has a bunch of untyped dependencies, so getting the translation order right saves a lot of rework.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: