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.
