Yes, but then you just got into those performance critical routines and hand code in the bounds checks and remove the automatic checking. Still a lot less work.
> On Jan 11, 2019, at 2:50 AM, Nigel Tao <nigel...@golang.org> wrote: > >> On Fri, Jan 11, 2019 at 5:46 PM Nigel Tao <nigel...@golang.org> wrote: >>> On Fri, Jan 11, 2019 at 4:22 AM robert engels <reng...@ix.netcom.com> wrote: >>> Again, what is wrong with the bounds checking/memory protection >>> library/technique for C I referred you to? Even a decrease in performance >>> will probably still be on par or better than the equivalent Go program. >> >> Quoting from https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html >> >> "Matrix multiply (ikj, using array subscripting): Execution time: >> slowdown of around 30 compared to unoptimised." > > That page also links to a "recent re-implementation" MIRO, dated 2007, > whose project report > (https://www.doc.ic.ac.uk/~awl03/projects/miro/MIRO.pdf), section 6.2, > says "gzip took considerably longer to compress when instrumented with > MIRO than when using Mudflap or when uninstrumented: on average about > 400 and 2,000 times slower respectively" and for the benchcpplinux > suite, "our bounds-checker is much slower that Mudflap or unchecked > code. This matches the results of the gzip benchmark". > > They also say that some of that could theoretically be clawed back by > (complicated) caching, but still, starting from 2000x slower is a long > way back. -- 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. For more options, visit https://groups.google.com/d/optout.
