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

11–20 of 51 posts

Re: What's wrong with 2006 programming?

#11

Post by bch »

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…

There was no mention of Linux in the article. This system also runs on the various *BSDs, Solaris, MacOS...

Re: What's wrong with 2006 programming?

#12

Post by scott_s »

bch wrote: post #11
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…

There was no mention of Linux in the article. This system also runs on the various *BSDs, Solaris, MacOS...

Then it's worth noting that CLOCK-Pro is used in NetBSD.

My point here is that a lot of people have spent a lot of time working on the page replacement problem. I am very open to the idea that an application can beat the page replacement policy in the underlying kernel, for a variety of reasons. But: numbers. Always evaluate. The implementation of these algorithms in practice is always more subtle than our high level understanding, so we need to do real performance comparisons to know if we actually improved anything.

(I'm getting my information from the algorithm's author's page: http://www.ece.eng.wayne.edu/~sjiang/ Jiang graduated from William and Mary while I was a young grad student there.)

Re: What's wrong with 2006 programming?

#13

Post by rbranson »

nostrademons wrote: post #8
rbranson wrote: post #7

Earlier quoted context omitted.

What would be the point of being able to spill to disk if you've got to keep everything in RAM? Simple serialization?

The point is zero-copy on load, not being able to spill to disk. Most high-performance, scalable servers I've seen ignore virtual memory entirely and kill (+ restart) the process if it exceeds the physical memory available on the machine. Yes, that means they use pre-1960s technology; sometimes, the price of performance is ignoring the programming conveniences we've come up with in the last 50 years.

Most applications need to perform some computations with data that is read from the backing store. Even simple sorts and searches will vastly outweigh the cost of an extra memcpy. Honestly, an HTTP cache is sort of a perfect case for the way in which Varnish was implemented. There is very little actual processing, if any, that needs to be done with the data that's read from disk. It just needs to be read from the backing store and shuttled over the socket as fast as possible, with very little friction. An extra memcpy or two matter in the Varnish scenario.

Re: What's wrong with 2006 programming?

#14

Post by bch »

scott_s wrote: post #12
bch wrote: post #11

Earlier quoted context omitted.

There was no mention of Linux in the article. This system also runs on the various *BSDs, Solaris, MacOS...

Then it's worth noting that CLOCK-Pro is used in NetBSD. My point here is that a lot of people have spent a lot of time working on the page replacement problem. I am very open to the idea that an application can beat the page replacement policy in the underlying kernel, for a variety of reasons. But: numbers. Always evaluate. The implementation of these algorithms in practice is always more subtle than our high level…

Agreed. "Problems" without measurements aren't worth much. My initial reaction was to your assumption about Linux, but we agree that assumptions in general aren't worth much.

Re: What's wrong with 2006 programming?

#15

Post by dasil003 »

scott_s wrote: post #12
bch wrote: post #11

Earlier quoted context omitted.

There was no mention of Linux in the article. This system also runs on the various *BSDs, Solaris, MacOS...

Then it's worth noting that CLOCK-Pro is used in NetBSD. My point here is that a lot of people have spent a lot of time working on the page replacement problem. I am very open to the idea that an application can beat the page replacement policy in the underlying kernel, for a variety of reasons. But: numbers. Always evaluate. The implementation of these algorithms in practice is always more subtle than our high level…

I'm a bit torn on this. I realize that you need to benchmark to really prove anything, and that optimization intuitions are often wrong, but on the other hand, you really need a wide variety of world benchmarks to approach any form of real world "proof". In the early implementation stages, I think clear thinking such as provided in this article is probably more important than spending 50 times as long setting up an array of benchmarks. Hopefully Salvatore has done some micro-benchmarks during development to guide his thinking, but even if not, it's hard to refute the thinking in this article.

If you think about the problem space of Redis vs Varnish, it's intuitively obvious that Varnish deals with a wide variety of general data without many opportunities to optimize beyond general purpose algorithms such as an OS provides. Whereas Redis has specific data types often with small footprints, and very careful attention paid to the details of optimization for memory and disk usage.

Re: What's wrong with 2006 programming?

#16

Post by moron4hire »

Something like paging virtual memory for Redis is going to be a core feature. I can completely understand why they would want to keep core features "in house". It's not "not implemented here" syndrome if the entire point of your company is to implement things like this.

Re: What's wrong with 2006 programming?

#17

Post by stephen »

I'm not an expert, but the application's memory usage being opaque to the kernel sounds vaguely like the problems Azul had scaling its Java runtime to large (>2GB) heaps.

Azul recently open sourced some of their kernel patches:

http://www.managedruntime.org/faq

But that is about all I know.

Re: What's wrong with 2006 programming?

#18

Post by scott_s »

dasil003 wrote: post #15
scott_s wrote: post #12

Earlier quoted context omitted.

Then it's worth noting that CLOCK-Pro is used in NetBSD. My point here is that a lot of people have spent a lot of time working on the page replacement problem. I am very open to the idea that an application can beat the page replacement policy in the underlying kernel, for a variety of reasons. But: numbers. Always evaluate. The implementation of these algorithms in practice is always more subtle than our high level…

I'm a bit torn on this. I realize that you need to benchmark to really prove anything, and that optimization intuitions are often wrong, but on the other hand, you really need a wide variety of world benchmarks to approach any form of real world "proof". In the early implementation stages, I think clear thinking such as provided in this article is probably more important than spending 50 times as long setting up an a…

I think you're overstating the time it takes to come up with benchmarks to evaluate performance optimizations. Even micro-benchmarks tailored to showcase your performance under ideal circumstances are a start. The longer you go without doing any performance comparisons, the longer you go without knowing if your work was worth it.

I'm not trying to deride his work - it's a neat project, and I will probably read through his earlier entries more. I'm down with all of the reasons provided, but I recognize that as humans, we tend to believe in things we understand. Hence, we need to evaluate.

Re: What's wrong with 2006 programming?

#20

Post by davidw »

moron4hire wrote: post #16

Something like paging virtual memory for Redis is going to be a core feature. I can completely understand why they would want to keep core features "in house". It's not "not implemented here" syndrome if the entire point of your company is to implement things like this.

The code is open source under a BSD style license, so it's not really about benefits for the company, which in this case is VMWare. They make their money elsewhere and pay antirez to hack on Redis, which is a pretty good deal for users of Redis.
Post reply on HN