Now if only we had a way to use all this goodness to reflect on structs/enumerate members...
On the actual topic: I wonder how much memory it takes to compile a single round of tetris?
1,388 karma · joined May 22, 2011
Now if only we had a way to use all this goodness to reflect on structs/enumerate members...
On the actual topic: I wonder how much memory it takes to compile a single round of tetris?
I guess this really doesn't matter from the user's point of view, just for the sake of curiosity, want to work out that/if there seems to be a fundamental difference (FWIW) between what rubah is doing which I understand as "hot patch the code within the running process and have some kind of 'trampoline'/dispatch code within that process to switch between new and old version, regardless if it is actual explicit code or just implicit in the rewritten bytecode, but never actually leave that original process" vs. what you'd do in native code on linux which is more like "tell the kernel to start a proper new process and then pass all open fd's and programm state to the new process" (which obviously requires that process to be written in a way that allows it to "continue where it left off") --- and the latter is not possible to do when running on the stock jvm if I understand correctly, because the jvm doesn't allow you to implement the part where you pass the filedescriptors, right?
PS: Under which license is the PixSQL code available?
To make my question more precise; I was trying to ask specifically about a "moving window aggregation" (e.g. a moving average over a timeseries). This is more like asking the question "Please give me every minute an aggregate based on all values in the last N minutes". To do that you need each input row to end up in more than one bucket (or have a special type of aggregation function like postgres does).
For example, if you were doing a moving aggregation with a 1-minute interval ("bucket size") and a 5 minute window ("lookback"), you would need to place each row into 5 buckets: The bucket into which it belongs based on it's timestamp and the 4 previous buckets. And a vanilla SQL GROUP BY can't do that.
Hope that makes sense.
EDIT: Looks like I stand corrected and this is NOT the case even if you are just dynamically linking a GPLed .so; check parent's links/ask a proper lawyer/please don't sue me ;)
The query language and concepts which are explained in the documentation are an exciting/novel (at least to me) contribution and "out in the open" for everybody to see/discuss/adapt/improve upon. Let's not dismiss that because we can't read the source.
Are you planning on adding that and which syntax are you planning to use? Have you looked at postgres "OVER PARTITION"? While it seems powerful it's also fairly unintuitive IMHO. I was experimenting with adding a GROUP BY clause that allows each input row to appear in more than one group in the result set. Something like:
SELECT time, mean(value) FROM mymetric GROUP OVER TIMEWINDOW(time, 60); ldd kerf-unpacked
linux-vdso.so.1 => (0x00007fff5e7f1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff1833aa000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff1830a4000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007ff182e5d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff182a99000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1835d1000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007ff182870000)
So using NSS shouldn't be an issue; and the binary actually does use it open("/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3Also did you roll the SQL engine from scratch or does it built on some existing parser/runtime? Would love to learn more.
You misunderstood my comment then. The scheme I described is used to do "full table scans" on the data. Also this is not something I came up with; there is a ton of research on this and it's how a number of fairly well known DB/analytics products work.
> But on a single machine the problem is checking what's in your own memory fast enough using CPU. That's where GPUs come in.
You can already scan these data volumes in millisconds on traditional hardware without doing too much fancy stuff or using GPUs. My original point was that I have a hard time coming up with an "interactive analytics" usecase where you'd want to process TB/s on one node that can keep only a few gigs around -- the improvement of doing this on GPUs instead of the old fashioned way on general purpose hardware seems to be that a query over the same dataset returns a few milliseconds faster. I reckon a user running interactive sql queries doesn't really care if their queries return in 10, 50 or 100ms -- I am not even sure I would be able to notice that difference myself. However, if you actually had a usecase for this you could still use the approach I described and make it as fast as you desire by scaling it out [tweaking the shard size] on conventional/commodity machines.
> you can just throw more boxes at it. But on a single machine
The linked article is discussing a setup with at least 8 distinct processing units, too.
> Even apart from the name of your company, the idea seems very interesting. I suppose I'm not the only one curious, so could just say a few more words? Are you working on some new technology
We are focused on delivering actionable insights as well as solving some very specific data problems for our customers right now. IMHO the hard part of doing that is making sure we understand the customer's domain, gather/track the right data from their systems and then work with them to slice and dice and visualize this data to discover "signal" from the "noise" which we can then feed back and use to optimize their website/app. The technical part of being able to handle the relatively large volumes of (non-preaggregated) source data is really just the means to that end. We do not currently offer an "off-the-shelf" version of our product, but again if you or somebody else would like to talk more, please ping me.
Also I hope I not coming across too negatively here. The linked research (compiling SQL to LLVM IR) sure is exciting stuff. I just couldn't help but feel that the hyperbole PR speak was a bit too strong with this one.
I understand the part where they "map the result set to opengl primitives" as that they write the output/result set of the sql query into some datastructure that allows them [after executing the query] to easily use it from opengl to render pretty stuff. This part shouldn't be much different from other texture/vertex data that you'd bring in e.g. from files on disk or a MySQL database into opengl specific buffers so that you can subsequently use it for drawing in your program.
We wrote our own code that does "the heavy lifting" but it's pretty much the same that everbody seems to be doing right now and comes down to minimizing the # of bytes read at query time; we index all data into a columnar format (so we only need to load a subset of the data and can pack it tightly for most queries) and then slice the query up into lots of individual shards that we compute in parallel (again, being bound mainly by the 200megs/sec disk read we get out of each machine).
Without being completely serious now but regarding your question; "a simple WHERE" (scanning each row and applying a predicate fn with no shared state/shuffle/merge phase) is pretty straightforward to run on a huge dataset as you can split the execution up into as many pieces as you want and run them individually. Since this allows you to basically choose the problem size per shard you could scan those 750m rows on a ginormous cluster of tamagochis if you can fit a single row onto one ;)
If you or somebody else would like to talk more, please shoot me an email: paul@deepcortex.io
Also, while it's absolutely amazing that they are able to scan 240B rows/sec, I wonder what one would use this capability for if they can only keep a few hundred million records around at a time? The difference between taking 10 or 100ms to scan the dataset should hardly matter to a user that is running "interactive analytics queries".
http://www2007.org/papers/paper570.pdf
EDIT: I see you changed your comment to include "no full graph recalcuation". Incremental recos are possible to do with minhash but I think you can't solve decay of old data easily.
My understanding is that one of your main ideas is to encrypt the data so I am honestly wondering where you would even start to check if a user was randomly flooding you or legitimately storing lots of keys.
Not trying to pick nits here... My original point was that -- in my opinion -- it comes across slightly dishonest if you insist that there is no limit even when it's obvious there must be one. (I mean seriously, how many machines is this running on right now? Even if it's running on amazon/google you can only scale my backend up so much with 20$/mo)
So since it's quite obvious that there must be some limit and/or expiration policy I think you should really just spell it out on the page.
- SQL based query and charting frontend (ChartSQL), so you don't have to learn yet another DSL
- ships with a a wire compatible StatsD API
- supports pluggable backends
- renders charts to SVG
- will probably not scale to petabytes of data out-of-the box
- single c++ binary, deploy it in 5 minutes using docker
- includes an interactive query editor
Here is an example that connects to a MySQL database on localhost: https://github.com/paulasmuth/fnordmetric/blob/master/fnordm...
Note that the IMPORT statement might be a bit misleading. The IMPORT statement only creates a "virtual table", it doesn't actually copy any data. As much of the query as possible is pushed down into MySQL/the external data source and the charts will be generated from the query result that is returned by the external data source.