On Mon, 30 Aug 2010, Jay A. Kreibich wrote:
> Date: Mon, 30 Aug 2010 12:04:25 -0500
> From: Jay A. Kreibich <[email protected]>
> To: General Discussion of SQLite Database <[email protected]>
> Cc: [email protected]
> Subject: Re: [sqlite] Is there a design doc for the virtual machine re-write?
>
> 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
Thanks, Jay. I'll check the links, and look further afield for what I
seek. I've been reviewing the Lua design doc recently, and the decision
to move from a stack to a register based VM is well supported there.
(http://www.lua.org/doc/jucs05.pdf)
Cheers,
Rob Sciuk.
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
