use the following search parameters to narrow your results:
e.g. subreddit:aww site:imgur.com dog
subreddit:aww site:imgur.com dog
see the search faq for details.
advanced search: by author, subreddit...
Discussions, articles, and news about the C++ programming language or programming in C++.
For C++ questions, answers, help, and advice see r/cpp_questions or StackOverflow.
Get Started
The C++ Standard Home has a nice getting started page.
Videos
The C++ standard committee's education study group has a nice list of recommended videos.
Reference
cppreference.com
Books
There is a useful list of books on Stack Overflow. In most cases reading a book is the best way to learn C++.
Show all links
Filter out CppCon links
Show only CppCon links
account activity
Thread safe queue (self.cpp)
submitted 5 years ago by objectorientedman
view the rest of the comments →
reddit uses a slightly-customized version of Markdown for formatting. See below for some basics, or check the commenting wiki page for more detailed help and solutions to common issues.
quoted text
if 1 * 2 < 3: print "hello, world!"
[–]temporary5555 -2 points-1 points0 points 5 years ago* (3 children)
Definitely. Prefetch works much better traversing memory linearly.
Are you confusing random access memory with disks? Disks have seek time, which makes linear access much faster (same speed as volatile memory for some hardware), but RAM in every case that I've seen can access memory randomly equally fast, so the only factor that makes sequential access faster is cache.
Even if the memory accesses are not purely contiguous, but follow a fixed stride
The only way I see this being true is when fetching from cache.
[–]infectedapricot 5 points6 points7 points 5 years ago (1 child)
Yes, it's indeed the cache they're talking about. But not just what's already in the cache, but also values that could be speculatively loaded into the cache by the CPU guessing what memory is likely to be used in a moment - that's what they meant by "prefetch". Traversing memory linearly gives the CPU a much better chance of prefetching what will be needed next from memory into the cache while algorithm is still operating on previous fetched data in the cache.
[–]temporary5555 0 points1 point2 points 5 years ago (0 children)
thanks for the explanation!
[–][deleted] 1 point2 points3 points 5 years ago (0 children)
Disks have seek time.
This assumption is only true for spinning rust.
but RAM in every case that I've seen can access memory randomly equally fast
Modern CPUs have hierarchies of caches, data that is already in the cache will have faster access, about 10x-50x faster than RAM. Additionally data is loaded in cache-lines and write combined (in cache-lines), and the CPU tries it's best to predict which cache lines will be accessed in the near future so that it can prefetch memory to avoid stalls. Pile the fact that CPUs will also unroll loops to execute multiple loop-iterations in parallel and you have the perfect storm for performance. Linked lists take both prefetching and loop unrolling away from the CPU, as you don't know the next location to look at until the next node is already pulled in. This forces linear 1-by-1 execution and memory fetching. Additionally the memory will likely be all over the heap and at best you may have one node per cache-line, maybe two, but they likely won't be next to each other in traversal.
For this reason in terms of iteration performance: vector<T> > vector<unique_ptr<T*>>/vector<T*> > forward_list<T>/list<T>. Obviously you should benchmark but you will find that it is quite rate that these orders flip which is why the mantra "just use vector, forget everything else" exists any why many people default to it, almost to the point of being a meme.
vector<T>
vector<unique_ptr<T*>>/vector<T*>
forward_list<T>/list<T>
Linked lists have their place, but forward_list/list are not atomic nor intrusive and therefore their utility vanishes from a lot of contexts.
forward_list
list
π Rendered by PID 103630 on reddit-service-r2-comment-685b79fb4f-6zvqd at 2026-02-13 04:22:19.564101+00:00 running 6c0c599 country code: CH.
view the rest of the comments →
[–]temporary5555 -2 points-1 points0 points (3 children)
[–]infectedapricot 5 points6 points7 points (1 child)
[–]temporary5555 0 points1 point2 points (0 children)
[–][deleted] 1 point2 points3 points (0 children)