flgr

I really adore the demo scene vibes I'm getting from https://block.xyz/.

You can say what you want about megaholding corporate conglomerates, but this has so much more style than abc.xyz.

If you have fond memories of Clonk give this a quick try: http://webclonk.flgr.me/ (WASD + Mouse)

Sadly I never got around to implementing more of it though.

Hm, unless I miscalculated the bit rate they use for the Simpsons demo is about equivalent to YouTube's 240p rendition (which uses 257 kbps; they use 250 kbps).

Looking at https://www.youtube.com/watch?v=a1nmZq1KEHk at 240p I think their Simpsons rendition looks better. But that's probably because of the low resolution. Makes me wonder how well H264 would perform with the same bit rate but a higher resolution.

I think it'd be best to have a 1 to 1 comparison between the two right on the vectorly site. I'm thinking that they'd have done that if they believed they were already ready to outperform, but that's a bit of speculation.

Having spent a lot of time working on making the backend compute this with very low latency, you wouldn't believe how happy finally seeing this become a reality on the actual site would make me. :)

Thank you /a lot/ for working on this!

Looks like the underlying logic came from this blog series, which made me originally buy that particular device: https://hackaday.io/project/5301-reverse-engineering-a-low-c... :)

There's also software to read the measurements it makesover USB, but I haven't personally used that: https://github.com/huhamhire/co2-monitor-exporter

This one has worked really well for me and friends who are also using it: https://www.amazon.de/TFA-Dostmann-AirCO2ntrol-CO2-Monitor-K...

Notably, they previously had issues were "View as" allowed you to view notifications and messages of the user you were viewing as.

If they'd done a proper post mortem and corrected the fundamental issue, and made sure it wouldn't have re-occured, this should not have happened.

I'm impressed by how well http://webclonk.flgr.me/ runs in Firefox on my 5 years old MBP, even when zooming out quite a lot.

This used to run much much better in Chrome than in Firefox. Mozilla must have done a ton of optimization to their JavaScript engine.

There's some context missing here. AFAIK the author of the repositories was specifically doing micro-benchmarks here to inform the design of his https://github.com/cornelk/hashmap library. I think for that use case (designing a high-performance lock-free data structure), that kind of micro-benchmarking makes a lot of sense.

That hash map looks good and I'm thinking we'd probably benefit from using it on the hot path of some code we have that needs to be highly scalable.

(Both links were submitted to HN, but only this one seems to have landed on the front page.)

Or phrased differently: There are different kinds of art. You might not like each and every single type of art, but they're still part of art.

There are different categories for speedruns. This is any%.

There's usually a "no major glitches" category, which shows more of the main game. In SMW this is called either 96 exits or 11 exits. Those are actually the default categories that are most heavily run from what it looks like.

See http://speedrun.com/smw

I think that's not any more fair than a direct charge. Or am I missing something?

From what I've heard well off families in Beijing will then just have multiple cars, one with an odd license plate and one with an even one.

Another use case I had was embedding this into a graph heavy MediaWiki with convenient markup. That means the graphs are very easy to edit and will be updated after each edit with no backend magic required.

I found TradingView to be very good. I.e. https://www.tradingview.com/chart/?symbol=BITSTAMP:BTCUSD

They also have regular stock symbols.

That image next to "Alexa helps you at your desk" is 17.5 MB as of now at at a resolution of 5720 x 3240. Pretty impressive to see an image loading line by line like back in the days.

It will be interesting to see what WeWork ends up using this for.

I was wondering if they might not be baiting Google into doing that. If they start removing content critical of them from Google Docs that's another big story.

> Das ist nicht gute.

Should be "Das ist nicht gut".

I don't know; personally I feel like the scale here is much too low to be relevant. Also I think not investing the time to tune sort and dist keys makes the comparison meaningless.

But maybe that just becomes meaningful at larger data sizes and maybe most people work with less data most of the time.

This sounds super interesting; a bunch of questions:

Did you just sent multiple images concatenated into the output stream, including file headers? And Mosaic would actually replace the first image with the second and so on? Was the CGI script referenced in an <img> tag?

What image format was this?

> and a non-constant factor that varies between 1 and 6 is small

Wouldn't the 6 in O(((n^1000)^n)^6) be a non-constant factor that makes a big difference in asymptotic performance though?

Sounds like the author did — http://www.lihaoyi.com/post/BenchmarkingScalaCollections.htm...

Notably Vector index access takes 4,260,000 ns for a vector with 1,048,576 elements instead of measured 0 ns for native arrays. is about +4 ns extra per element and hints at the whole data set still fitting into L2 cache.

If the process ends up accessing more working memory than fits into L2 (32 or 64 MB or so) and lookups aren't nicely bundled together, the overhead will approach about +80 ns per element access. Or +0.08 seconds per million element accesses.

It does seem unlikely that every element access would end up causing a cache miss since I'd expect lookups to happen close together, but this can be significant for intense workloads such as OLAP.

This is why I've never liked stating that something has "run-time of O(log(n))" since that's rarely true — the assumption for that is that all machine instructions take pretty much the same time, which is not the case. CPU instructions involving cache misses are multiple orders of magnitude more expensive than others.

I think it makes much more sense to talk about concrete operations (or cache misses) instead. Sounds like their implementation has O(log(n)) cache misses.

  Expanded mode in psql is a way to output the results of a
  query if the output is too wide to fit in the screen when
  shown as a table. This can be toggled by \x on or \x off.
  
  [...] In pgcli, we have the ability to do this but this is
  not enabled by default. It has to be enabled via the config
  file (~/.config/pgcli/config) by the user.
  
  I don't think we'll change this behavior.

Why not? Seems quite sensible a thing to do when the output otherwise wouldn't fit.

Original author here; was quite surprised to find this on the front page today.

Let me know if you have any questions. Happy to answer them!

Twitch Berlin is hiring. We're looking for data scientists and distributed systems engineers working on one of the largest live video CDNs in the world at a huge scale that makes things interesting.

Posted this as a top level comment already before I saw this one. Sorry about that: https://news.ycombinator.com/reply?id=14713062&goto=item%3Fi...

To the many able people who worked for SoundCloud in Berlin:

Twitch Berlin is hiring. We're looking for data scientists and distributed systems engineers working on one of the largest live video CDNs in the world at a huge scale that makes things interesting:

* Data Scientist, Fraud/Video: https://jobs.lever.co/twitch/17b5882c-6be0-41cd-a6ac-45b948e...

* Distributed Systems Engineer - Live Video CDN: https://jobs.lever.co/twitch/8929e219-138d-473c-8acd-4fcc3e0...

* Senior Software Engineer - Live Video CDN: https://jobs.lever.co/twitch/2fae3239-fe4d-4582-bfdf-7d43727...

Primary language is Golang so DSEs from SoundCloud are likely to be a great fit!

The latter two positions say "San Francisco", but we have a growing engineering office in Berlin with people working on the live video CDN and fraud detection. These positions can be filled in Berlin and we'd be very happy to do so (helps us grow the Berlin office).

Happy to answer any questions you might have. Hope this will help some of the folks affected by the lay off.

Twitch Berlin is hiring a Data Scientist for fraud detection:

https://www.linkedin.com/jobs/view/317384829/

I think in order to really reap the benefits of this you'll want to actually reorganize the in-memory layout of the trees in order to make sure all elements needed for the comparison end up in the same cache line.

I haven't been following this closely, but the last time I checked scatter-gather loads were really really slow.

Chapter 3.3 from page 27 (PDF page 43) on of this be interesting: https://www.researchgate.net/profile/Florian_Gross/publicati...

Also contains a survey of some other related data structures and algorithms.

> One of the main benefit of LRU is that it only needs one extra bit per cache line.

This might be well known, but why's that? I've recently seen a Go implementation of LRU and it uses a lot of memory. Maybe this would allow us to save some of that in a better implementation.