HN user

flgr

256 karma
Posts3
Comments74
View on HN

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.

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.

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.)

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.

Alexa for Business 9 years ago

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.

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.

Time.gif 9 years ago

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?

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.

Sensible Defaults 9 years ago
  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.

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.

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.