4 ms·

What a remarkably misguided rant. To each his own. What works for a general-purpose app on a desktop hardware doesn't work for a resource-constrained firmware

by abcd_f 12y ago

What a remarkably misguided rant. To each his own. What works for a general-purpose app on a desktop hardware doesn't work for a resource-constrained firmware (that still has to deal with potentially unbounded inputs). Yes, there's exponential reallocation, but there's also a multitude of other strategies, each best fit for its particular application domain. "Rookie mistake".

barrkel 12y ago
I've been burned far more often by O(n^2) algorithms being used inappropriately than by slightly too high memory usage. It usually comes up when you give a piece of software an order of magnitude more data than it's used to, and discover it becomes unusable. Resource constrained firmware is a special case, because the package is tested as a unit, rather than individual software modules which may themselves be used in very different use cases. The default algorithm should still usually be exponential growth, with tuning back where necessary to meet memory usage goals.
deleted 12y ago
[deleted]
pja 12y ago
You're making a pedantic special case correction to a generally correct truth. This is not an endearing trait. Everybody knows that a statement such as the one the parent post made will have special case exceptions: The point is that exponential growth should be the default & any other choice requires justification. Asserting this is not a "misguided rant".
- nnethercote 12y ago
  > Everybody knows that a statement such as the one the parent post made will have special case exceptions Thank you for reading with a spirit of intellectual generosity. When I write posts like this I always wonder about how many qualifications and weasel words I should add just in case it makes Hacker News and the nitpickers come out in force. In this case I wrote things like "A strategy that is usually better is exponential growth" but still many of the comments are polite variations on "exponential isn't best in all circumstances, you idiot".
  - Someone 12y ago
    Instead of weasel words, [RFC 2119] should be sufficient (https://www.ietf.org/rfc/rfc2119.txt https://www.ietf.org/rfc/rfc2119.txt) (Google also gave me http://tools.ietf.org/html/rfc6919 http://tools.ietf.org/html/rfc6919, which I did not know about yet. The third month of the year often sees remarkable productivity, culminating in superb output in the beginning of the fourth month)
vidarh 12y ago
If you know you have special case constraints, you presumably will know enough to deal with them properly. In my experience the far more frequent mistake is developers on "normal" systems that seems to think that system calls in general are "free" and are far too cavalier about doing things like small reads, or allocating small buffers. As a more general advice, rather than growing buffers exponentially: Developers should in general treat kernel space as a remote system in terms of performance, and remember that every system call is slow. You can typically afford to do quite a lot of extra bookkeeping in user space to cut the number of system calls and still come out on top (e.g. user space buffering of reads). And learn to love strace/dtrace/systemtap/whaever mechanism to trace and profile system calls. Paying attention to this can have a dramatic impact on performance for very little effort.

by abcd_f 12y ago

barrkel 12y ago

I've been burned far more often by O(n^2) algorithms being used inappropriately than by slightly too high memory usage. It usually comes up when you give a piece of software an order of magnitude more data than it's used to, and discover it becomes unusable. Resource constrained firmware is a special case, because the package is tested as a unit, rather than individual software modules which may themselves be used in very different use cases. The default algorithm should still usually be exponential growth, with tuning back where necessary to meet memory usage goals.

deleted 12y ago

[deleted]

pja 12y ago

You're making a pedantic special case correction to a generally correct truth. This is not an endearing trait. Everybody knows that a statement such as the one the parent post made will have special case exceptions: The point is that exponential growth should be the default & any other choice requires justification. Asserting this is not a "misguided rant".

nnethercote 12y ago
> Everybody knows that a statement such as the one the parent post made will have special case exceptions Thank you for reading with a spirit of intellectual generosity. When I write posts like this I always wonder about how many qualifications and weasel words I should add just in case it makes Hacker News and the nitpickers come out in force. In this case I wrote things like "A strategy that is usually better is exponential growth" but still many of the comments are polite variations on "exponential isn't best in all circumstances, you idiot".
- Someone 12y ago
  Instead of weasel words, [RFC 2119] should be sufficient (https://www.ietf.org/rfc/rfc2119.txt https://www.ietf.org/rfc/rfc2119.txt) (Google also gave me http://tools.ietf.org/html/rfc6919 http://tools.ietf.org/html/rfc6919, which I did not know about yet. The third month of the year often sees remarkable productivity, culminating in superb output in the beginning of the fourth month)

vidarh 12y ago

If you know you have special case constraints, you presumably will know enough to deal with them properly. In my experience the far more frequent mistake is developers on "normal" systems that seems to think that system calls in general are "free" and are far too cavalier about doing things like small reads, or allocating small buffers. As a more general advice, rather than growing buffers exponentially: Developers should in general treat kernel space as a remote system in terms of performance, and remember that every system call is slow. You can typically afford to do quite a lot of extra bookkeeping in user space to cut the number of system calls and still come out on top (e.g. user space buffering of reads). And learn to love strace/dtrace/systemtap/whaever mechanism to trace and profile system calls. Paying attention to this can have a dramatic impact on performance for very little effort.