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.
