Fantastic work! And this will be super useful to the community. I have used sqlite memory dbs for unit tests in the past, and this always caused me portability pain.
Just one question. How will you track upstream changes in the original C sqlite? On Thursday, 27 August 2020 14:24:23 UTC+1, Jan Mercl wrote: > > On Thu, Aug 27, 2020 at 2:46 PM Nick <golan...@njw.name <javascript:>> > wrote: > > > I took a little tour around the code, am I correct in thinking that > > it's mostly a clever translation of the C code to Go, using > > generator.go? What is 'ccgo' that seems to be doing all this? > > ccgo is a C compiler producing Go code. It's a work in progress and its > code is so far the only documentation available, sadly. The project is > modernc.org/ccgo/v3 hosted currently here: > https://gitlab.com/cznic/ccgo/-/tree/master/v3 > > > I see > > that lib/sqlite_linux_amd64.go is created by the makeSqlite() > > function, but is the capi_linux_amd64.go file generated from the > > same command? Sorry, but I don't yet understand this ccgo thing. > > ccgo produces a capi_$GOOS_$GOARC file automatically for non main C > programs. This file simply has a map of extern symbols the Go package > defines. ccgo uses this information for linking via, for example - > lmodenrc.org/sqlite/lib. Similarly to a standard C compiler, libc is > "imported" automatically as if the last item to ccgo is -lmodernc.org/libc. > This can be overridden by the -ccgo-crt-pah flag. (The libc project is a > continuation of the earlier modernc.org/crt project.) > > > Am I correct in thinking that this implementation, now it passes all > > the tests, should be essentially a drop-in replacement for something > > like github.com/mattn/go-sqlite3, with similar performance as it's > > just translated-from-C? > > Mattn's package exposes much more above the sql/database driver and adds > custom URL parameters for various options specific to that project. > However, it should be possible to create a drop-in replacement package as > everything in modernc.org/sqlite/lib is exported and "consumable". What > would be needed is to write manually a client Go <-> ccgo produced Go > bridges for the functions that mattn's package uses from sqlite3.c > (probably just a few dozens of them). The ccgo produced Go has an "ABI" > that's quite distinct from usual Go functions. And it's not documented yet. > But I can provide the info to anyone who would like to turn it into the > proper documentation in a series of questions and answers, held on the > issue tracker, for example. > > Wrt performance, I expect the Go port to be definitely slower on average. > It's a long story to explain why and there's a lot of different reasons. > However, the slow down depends on what C code is measured. On a set of 24 > benchmarks from ComptCert, the average ratio was about 1.25 (times slower > than gcc -O) for the same C code in an earlier (still crt based) version. > But then you can find some other C code where addresses of local variables > are taken or where closures are used and it gets the highest performance > hit. Correctness and completeness is so far the priority. I hope some > performance improvements are still possible afterwards. For example, the > current libc does not yet buffer stdout. Here are the current numbers on a > rather old machine where you can see how it (I guess) hurts binarytrees.c: > > === RUN TestCompCert > === RUN TestCompCert/gcc > === RUN TestCompCert/ccgo > === CONT TestCompCert > all_test.go:1165: compiler test T comp exec > match coef > all_test.go:1167: gcc aes.c 70.965ms true true > true 1.000 * > all_test.go:1167: gcc almabench.c 253.403ms true true > true 1.000 * > all_test.go:1167: gcc binarytrees.c 33.907ms true true > true 1.000 * > all_test.go:1167: gcc bisect.c 81.671ms true true > true 1.018 > all_test.go:1167: gcc chomp.c 237.238ms true true > true 1.000 * > all_test.go:1167: gcc fannkuch.c 174.135ms true true > true 1.000 * > all_test.go:1167: gcc fft.c 67.835ms true true > true 1.000 * > all_test.go:1167: gcc fftsp.c 40.645ms true true > true 1.000 * > all_test.go:1167: gcc fftw.c 66.590ms true true > true 1.000 * > all_test.go:1167: gcc fib.c 45.877ms true true > true 1.000 * > all_test.go:1167: gcc integr.c 28.862ms true true > true 1.000 * > all_test.go:1167: gcc knucleotide.c 130.633ms true true > true 1.000 * > all_test.go:1167: gcc lists.c 60.898ms true true > true 1.000 * > all_test.go:1167: gcc mandelbrot.c 106.127ms true true > true 1.000 * > all_test.go:1167: gcc nbody.c 149.378ms true true > true 1.000 * > all_test.go:1167: gcc nsieve.c 134.007ms true true > true 1.000 * > all_test.go:1167: gcc nsievebits.c 99.903ms true true > true 1.000 * > all_test.go:1167: gcc perlin.c 38.010ms true true > true 1.000 * > all_test.go:1167: gcc qsort.c 91.263ms true true > true 1.000 * > all_test.go:1167: gcc sha1.c 59.152ms true true > true 1.000 * > all_test.go:1167: gcc sha3.c 29.127ms true true > true 1.000 * > all_test.go:1167: gcc siphash24.c 87.284ms true true > true 1.000 * > all_test.go:1167: gcc spectral.c 168.282ms true true > true 1.022 > all_test.go:1167: gcc vmach.c 59.304ms true true > true 1.000 * > all_test.go:1167: ccgo aes.c 82.205ms true true > true 1.158 > all_test.go:1167: ccgo almabench.c 349.994ms true true > true 1.381 > all_test.go:1167: ccgo binarytrees.c 240.471ms true true > true 7.092 > all_test.go:1167: ccgo bisect.c 80.192ms true true > true 1.000 * > all_test.go:1167: ccgo chomp.c 316.546ms true true > true 1.334 > all_test.go:1167: ccgo fannkuch.c 231.494ms true true > true 1.329 > all_test.go:1167: ccgo fft.c 79.481ms true true > true 1.172 > all_test.go:1167: ccgo fftsp.c 103.185ms true true > true 2.539 > all_test.go:1167: ccgo fftw.c 93.375ms true true > true 1.402 > all_test.go:1167: ccgo fib.c 73.022ms true true > true 1.592 > all_test.go:1167: ccgo integr.c 32.963ms true true > true 1.142 > all_test.go:1167: ccgo knucleotide.c 295.192ms true true > true 2.260 > all_test.go:1167: ccgo lists.c 72.562ms true true > true 1.192 > all_test.go:1167: ccgo mandelbrot.c 152.969ms true true > true 1.441 > all_test.go:1167: ccgo nbody.c 149.822ms true true > true 1.003 > all_test.go:1167: ccgo nsieve.c 157.365ms true true > true 1.174 > all_test.go:1167: ccgo nsievebits.c 113.934ms true true > true 1.140 > all_test.go:1167: ccgo perlin.c 67.065ms true true > true 1.764 > all_test.go:1167: ccgo qsort.c 105.136ms true true > true 1.152 > all_test.go:1167: ccgo sha1.c 82.178ms true true > true 1.389 > all_test.go:1167: ccgo sha3.c 70.727ms true true > true 2.428 > all_test.go:1167: ccgo siphash24.c 108.887ms true true > true 1.248 > all_test.go:1167: ccgo spectral.c 164.702ms true true > true 1.000 * > all_test.go:1167: ccgo vmach.c 78.095ms true true > true 1.317 > all_test.go:1174: Considered tests: 24/24 > all_test.go:1182: ccgo 3.301562213s 1.426 > all_test.go:1182: gcc 2.314496632s 1.000 > --- PASS: TestCompCert (46.13s) > --- PASS: TestCompCert/gcc (16.60s) > --- PASS: TestCompCert/ccgo (29.48s) > > > What happens if one (erroneously) tries to > > build a project that uses this library, using a non-supported > > architecture? Will go complain? > > Yes, all of the os/arch specific code is by guarded like in > foo_$GOOS_$GOARCH.go, so the compiler targeting other GOOS/GOARCH should > definitely fail the build. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/eb5b35c8-0097-4ebd-b228-bff6b0d59d77o%40googlegroups.com.
