On Mon, Aug 30, 2010 at 03:59:51PM +0400, Max Vlasov scratched on the wall: > > That is *EXACTLY* what I'm reffering to. Is there any design info, > > rationale or pointers to what changes were made, and why the switch from a > > stack to register machine?? Also, is there any performance data? > > There's a video where D. Richard Hipp talks about sqlite (interesting in > many other aspects also): > http://video.google.com/videoplay?docid=-5160435487953918649 > > He mentioned (about 30:00) that with register based engine is much easier to > generate instructions.
There's also this comment, on a bug that was filed in November of 2007 (less than 90 days before the release of the register based VDBE): http://www.sqlite.org/cvstrac/tktview?tn=2767,39 "I have long wanted to switch the VDBE from being a stack-based VM to being a register based VM. Notice that were the VDBE register based, this bug would have never come up...." > Below is my observations about the aspects that makes register-based engine > a better choice: > - vbe codes points to columns, tables and so on while actual data is placed > in the tables (persistent or temporal) so there are actually not so many > cases when you really need much data temporary available so several > registers should be enough I think that's key. The SQLite VDBE is extremely specialized. Most of the "instructions" are very high level abstractions. If you wanted to write a procedural language for database manipulation, it isn't difficult to imagine a nearly one-to-one mapping between PL/SQL like commands and VDBE instructions. I've not spent a ton of time studying the VM, other than trying to track down query performance issues, but in my own experience the registers don't tend to carry values from instruction to instruction. Frequently the registers have immediate values, and are used more as instruction parameters, rather than state carrying containers that are passed from instruction to instruction. As Max said, most of the manipulated data (i.e. database values and table or index references) is held in non-register containers. The registers are used as index references into those stores, and in many cases those index values are static for a specific VM instruction in a specific VDBE program. Because of the nature of the SQL language, this works out very well. SQL commands tend to be self-contained and follow specific formats. I'm sure a "parameter based" VM makes code generation much simpler and much faster and is a very good fit for the needs of SQLite. I'm less convinced it could be expanded to deal with more generic programming abstractions, such as recursive function calls-- but I don't have an extensive amount of VM experience, so I wouldn't put much into that opinion. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
