Live data from Hacker News

Parallel Parentheses Matching

williamdue.github.io

11–20 of 21 posts

Re: Parallel Parentheses Matching

#11
post #7

This is an interesting read. You can solve the same problem with Range Min Query Tree. The query for balanced or unbalanced parentheses is O(log N). A two or three level RMQTree can represent billions of parentheses already (a two-level tree of 65536 branch factor = 4B parentheses). The query is O(65536 + 65536) or effectively O(1). For a four-level tree of 256 branch factor, the query is O(256 + 256 + 256 + 256) or…

> or effectively O(1)

I've heard that phrase couple of times, and cannot stop noting that then every real-world algorithm is "effectively O(1)", because in real world we have bounded inputs and RAM. E.g. every integer is O(2^64) = O(1).

If we need to say that something is really fast, let's just say that. E.g if a CPU needs to iterate something 65536 + 65536 times, we can just say that it would take about 0.1ms on 1GHz CPU, no need to involve asymptotic.

E.g. Scala boasts that their Vector implementation is "effectively constant", while in doing up to 5 non-consecutive RAM accesses, that screws up the CPU cache. But if we can bound something to "no more than 5 operations", then I can say that any array in 32-bit arch is "no more than 2^32 operations", which is equal to O(1).

Re: Parallel Parentheses Matching

#12
post #11
post #7

This is an interesting read. You can solve the same problem with Range Min Query Tree. The query for balanced or unbalanced parentheses is O(log N). A two or three level RMQTree can represent billions of parentheses already (a two-level tree of 65536 branch factor = 4B parentheses). The query is O(65536 + 65536) or effectively O(1). For a four-level tree of 256 branch factor, the query is O(256 + 256 + 256 + 256) or…

> or effectively O(1) I've heard that phrase couple of times, and cannot stop noting that then every real-world algorithm is "effectively O(1)", because in real world we have bounded inputs and RAM. E.g. every integer is O(2^64) = O(1). If we need to say that something is really fast, let's just say that. E.g if a CPU needs to iterate something 65536 + 65536 times, we can just say that it would take about 0.1ms on 1G…

I lost count of the number of times I've seen a junior dev call qsort on an array that is guaranteed to only have a few hundred members at most.

Re: Parallel Parentheses Matching

#13
post #11
post #7

This is an interesting read. You can solve the same problem with Range Min Query Tree. The query for balanced or unbalanced parentheses is O(log N). A two or three level RMQTree can represent billions of parentheses already (a two-level tree of 65536 branch factor = 4B parentheses). The query is O(65536 + 65536) or effectively O(1). For a four-level tree of 256 branch factor, the query is O(256 + 256 + 256 + 256) or…

> or effectively O(1) I've heard that phrase couple of times, and cannot stop noting that then every real-world algorithm is "effectively O(1)", because in real world we have bounded inputs and RAM. E.g. every integer is O(2^64) = O(1). If we need to say that something is really fast, let's just say that. E.g if a CPU needs to iterate something 65536 + 65536 times, we can just say that it would take about 0.1ms on 1G…

[deleted]

Re: Parallel Parentheses Matching

#15
Petition to have the question added to leetcode. Two variants one with a single type of parens such as () and one with mixed parens (),{},[]. In each problem implement the map method which takes a chunk sequence of the overall input, the reduce method which takes an array of map method output for each chunk and returns the overall answer.

Re: Parallel Parentheses Matching

#16
post #11

Earlier quoted context omitted.

> or effectively O(1) I've heard that phrase couple of times, and cannot stop noting that then every real-world algorithm is "effectively O(1)", because in real world we have bounded inputs and RAM. E.g. every integer is O(2^64) = O(1). If we need to say that something is really fast, let's just say that. E.g if a CPU needs to iterate something 65536 + 65536 times, we can just say that it would take about 0.1ms on 1G…

I lost count of the number of times I've seen a junior dev call qsort on an array that is guaranteed to only have a few hundred members at most.

If the implementation of qsort doesn't switch over to another algorithm for sufficiently small arrays (or when the recursion gets to a sufficiently small chunk) it could be improved.

Re: Parallel Parentheses Matching

#18

Also see Fast GPU bounding boxes on tree-structured scenes[1] (unpublished paper) and notes toward a blog post[2]. This is a highly tuned GPU implementation of parentheses matching. It's actually used in Vello (the classic version in which we offload basically all the work to the GPU, not the newer CPU-GPU hybrid version in which tracking the blend stack is done on the CPU). Earlier versions of the work were featured…

emailed :)
Post reply on HN