A key statement in the link “ The JIT-generated code is significantly faster than the ahead-of-time-generated code for small matrix sizes.”
Which is what you were arguing was not possible... you can’t have it both ways. > On Mar 3, 2020, at 3:55 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > > >> On Friday, February 14, 2020 at 6:57:08 PM UTC+1, ⚛ wrote: >>> On Friday, February 14, 2020 at 6:46:51 PM UTC+1, Robert Engels wrote: >>> Yes, and then the access and iteration is slower as it needs indirection to >>> find the correct page. There is no free lunch. >>> >>> The caveats about using mutable objects, sharing, and concurrency still >>> apply. >>> >>> A virtual machine environment has nothing to do with preventing direct >>> memory access. You can do direct memory access in Java. I think what you >>> are referring to is a "managed memory", or "safe memory" environment. >>> >>> Honestly, this stuff is CS 101 (maybe 201), and we've strayed so far off >>> the topic. I didn't write the code. Take it up with those Googlers if you >>> think it's bad. I was using the code as a baseline to demonstrate >>> improvements in JVM/GC technology, nothing more - and for that it was >>> appropriate. >> >> You seem to believe that no further improvements in C++ compiler technology >> are possible. Within the next 100 years mankind is surely going to develop a >> C++ compiler which will automatically replace std::map with >> std::unordered_map in this particular benchmark, will automatically redirect >> relevant new/delete expressions to a fast memory pool allocator and will >> automatically use 24/32-bit addresses instead of 64-bit ones if it makes >> sense from performance viewpoint. >> >> Of course, JVM/GC technologies are going to improve over time as well. The >> belief that C++ will not is false. > > A link related to a potential step in the evolution C++: > http://wg21.link/p1609 > -- > 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/1b451260-96aa-4e19-b432-f47001a32e0c%40googlegroups.com. -- 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/2503DDF2-A0A5-46A1-A566-C35ECDE65B34%40ix.netcom.com.