Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's wrong with 2006 programming?

antirez.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: What's wrong with 2006 programming?

#31

Post by kenjackson »

bediger wrote: post #10

I blame Benjamin Zorn in this paper: http://www.cs.colorado.edu/department/publications/reports/d... for the whole "programmers shouldn't manage memory" myth. Clearly, if you know what you're doing, you can do better than the OS and/or malloc() does. If you don't know what you're doing, you have bigger problems than writing your own allocator will quickly solve.

But the real point isn't "can you do a better job", but is it worth it to a better job?

If I can use an OTS memory allocator and get within 2% of my hand-crafted hand-tuned allocator, I think I'd need to be extremely perf sensitive to care.

Re: What's wrong with 2006 programming?

#32

Post by jules »

dasil003 wrote: post #29
scott_s wrote: post #25

Earlier quoted context omitted.

Well, yes. I take him "seriously," but I'm not yet convinced his techniques outperform the kernel. That's how systems work is done. If you want to convince people that your way is better, then you need data to back it up.

You can't take any of his arguments at face value? Like the blocking argument?

No, performance of complex systems is really really hard to predict.

Re: What's wrong with 2006 programming?

#33

Post by scott_s »

dasil003 wrote: post #29
scott_s wrote: post #25

Earlier quoted context omitted.

Well, yes. I take him "seriously," but I'm not yet convinced his techniques outperform the kernel. That's how systems work is done. If you want to convince people that your way is better, then you need data to back it up.

You can't take any of his arguments at face value? Like the blocking argument?

Remember that I started this discussion off by saying "This author makes compelling arguments for implementing application level paging." I'm down with his arguments - people have actually made them before, and I thought they were good arguments then, too. But I can't say "Yes, I agree, what you have done improves performance" until I actually see performance comparisons.

But that's only the first level point. The second level point is: are the optimizations worth it? That is, if you only improve performance by less than 1%, then it's probably not worth the hassle. These are the sorts of things that experiments can tell you.

If it sounds like I'm being pedantic: well, yes, I am. I do systems research. This is the same standard I hold myself and my peers to. If someone asked me to review a systems paper that claimed to improve something, but had no results, I'd reject it. I recognize this is a blog post and not an academic paper, but my standard for "do I accept that this is a better approach" has not changed. And I have seen plenty of blog posts with experiments.

Re: What's wrong with 2006 programming?

#34

Post by acqq »

bediger wrote: post #10

I blame Benjamin Zorn in this paper: http://www.cs.colorado.edu/department/publications/reports/d... for the whole "programmers shouldn't manage memory" myth. Clearly, if you know what you're doing, you can do better than the OS and/or malloc() does. If you don't know what you're doing, you have bigger problems than writing your own allocator will quickly solve.

As far as I see the Zorn's paper is about mallocs vs garbage collector (moreover, specific mallocs and a specific GC), whereas the main article here is about just allocating from VM versus managing your own cache with your own file read / write.

And as others already noted, "'just' allocating from VM" can be better (less copying) once you can organize everything right and know how to manage the threads. And the main argument of the main article is "if you can't access it with different threads, VM access can block you everything" (that's the two clients complaint). That much both are right, as long nobody tries to make some too general statements like "just use always X."

Re: What's wrong with 2006 programming?

#35

Post by wmf »

ntoshev wrote: post #27
wmf wrote: post #2

Just to amplify his point, if you want your program to take page faults as PHK suggests, it has to be multithreaded. If you choose event-driven concurrency you can't afford to take page faults in mmap() or read(). When you make the threads vs. events decision you're implicitly making a bunch of related decisions about I/O and scheduling as well; a hybrid approach (like using events and mmap) won't work well.

Be sure to check PHK's comment (#5) madvise + mincore syscalls could be used to get the kernel to preload the pages asynchronously.

Not really; because mincore() does not generate events you'd have to poll to find out when the page-in has finished, which seems pretty wasteful. If I was doing disk I/O from an event-driven program I would rather use the Flash approach of using a small number of worker threads to perform blocking I/O. PHK says "I consider this a deficiency in POSIX standards, not in the concept of VM.", but you have to go to production with the kernel you have, not the kernel you wish you had.

Re: What's wrong with 2006 programming?

#36

Post by jasonwatkinspdx »

fleitz wrote: post #22

Stop thinking of RAM/disk/etc as storage systems and start thinking of them as retrieval systems. Then stop thinking of your data costs as $/GB (storage systems) and start thinking of your data costs as $/(IO/sec/GB) (retrieval systems). I know everyone these days seems to think that removing a structured query language parser from a database makes every other problem go away, but realistically RDBMS vendors spend mi…

This has been well understood since antiquity (in the CS world at least). Read Jim Gray's "The 5 minute rule" and the more recent papers that cite it. Most likely the access frequency of your objects is not such to demand them residing in L2.

Ultimately there's no need to use a commercial database either, as there are compelling open source alternatives, though if your needs are very specific, a commercial database may be your best tool.

Re: What's wrong with 2006 programming?

#37

Post by jasonwatkinspdx »

nostrademons wrote: post #5
wmf wrote: post #2

Just to amplify his point, if you want your program to take page faults as PHK suggests, it has to be multithreaded. If you choose event-driven concurrency you can't afford to take page faults in mmap() or read(). When you make the threads vs. events decision you're implicitly making a bunch of related decisions about I/O and scheduling as well; a hybrid approach (like using events and mmap) won't work well.

You can use events + mmap, you just need to factor the paging latency into your design. Normally, this might mean mmapping a chunk of data at startup, touching it all so that it's resident in RAM, and then beginning to serve queries, keeping an eye on your total resident set so that it never pages out.

The entire point of redis's VM layer is to serve data sets larger than ram when the request distribution is such not everything need be memory resident (I believe this is sometimes referred to as the 1:10 problem in the redis community).

While ram is far cheaper than it once was, there still are substantial savings in reducing your resident set requirements from TBs to just hundreds of GBs.

Re: What's wrong with 2006 programming?

#38

Post by nwmcsween »

scott_s wrote: post #4

Again, the kernel will use a simple LRU algorithm, where the granularity is the page. I don't think it's accurate to describe any performance critical part of the Linux kernel as "simple." For an overview of the page replacement policy, see http://kerneltrap.org/node/7608 . I wondered if CLOCK-Pro [1, 2] had made it into the kernel yet, but it looks like it has not. This author makes compelling arguments for implemen…

How is LRU not simple? The page replacement policy in Linux is simple it's just makes use of available information - The algorithm does not make the system. Clock-pro is not in Linux and I doubt it ever will be. The goal in creating manageable code is passing the information that you know to the next person that doesn't by using comments and even Linux doesn't do this at all so hack-ability of any non trivial parts is near impossible without a few months of poking.

Re: What's wrong with 2006 programming?

#39

Post by gjm11 »

bediger wrote: post #30
gjm11 wrote: post #28

Earlier quoted context omitted.

It seems a bit strange to blame Zorn for spreading the myth that "programmers shouldn't manage memory" on the basis of that paper, when at about the same time he was writing a bunch of other papers extolling the virtues of customized memory allocators: http://portal.acm.org/citation.cfm?id=172674 , for instance.

Did you read the "CustoMalloc" paper? It's more of the same. Just to illustrate, the paper you referenced has the title "CustoMalloc: efficient synthesized memory allocator". That is, "CustoMalloc" takes a look at memory usage patterns of a particular program, then generates a semi-customized allocator for that program.

Yes, of course I read it. Yes, the allocators are synthesized; so what? The point is that "synthesize a semi-customized allocator for each program" is a very different thing from "just use what the system provides you with; you won't be able to do better".
Post reply on HN