4 ms·

"...the speed is just incredible." Others have suggested: Perhaps it seems "fast" only because the systems that are considered acceptable today are (by compari

by 101914 12y ago

"...the speed is just incredible." Others have suggested: Perhaps it seems "fast" only because the systems that are considered acceptable today are (by comparison) incredibly slow. "... purpose built..." I believe it is only a minority of all my kernel's (and my OS's) capabilities that I actually use. The majority are there only because it is too much work to remove them. This is only my opinion.

jacquesm 12y ago
No, it is fast, it runs entirely in the L1 cache. That's a huge boost compared to anything that's larger than that. He's only going off-die to do IO.
- 101914 12y ago
  I am aware of that. Of course I am not using a kernel that fits in 512k, but personally I prefer software that fits in 512k and I write and use such software regularly. But it still does not change the point of my comment. One can either say a smaller, lighter system is "fast" or one can say a larger, heavier system is "slow". It depends on the "benchmark" one chooses. You characterize the performance of "small" software as a "huge boost". While I might characterize the performance of a "large" software as a "huge slowdown". The difference is my benchmark is small software, not large software.
  - jacquesm 12y ago
    > I am aware of that. That's nice, but that did not follow from your previous comment. > Of course I am not using a kernel that fits in 512k, but personally I prefer software that fits in 512k and I write and use such software regularly. > But it still does not change the point of my comment. > One can either say a smaller, lighter system is "fast" or one can say a larger, heavier system is "slow". It depends on the "benchmark" one chooses. > You characterize the performance of "small" software as a "huge boost". > While I might characterize the performance of a "large" software as a "huge slowdown". > The difference is my benchmark is small software, not large software. So, actually you seemed to agree with the OP then. Either that or you're not making your point very effectively.
    - 101914 12y ago
      Or you completely misunderstood my point. I was not agreeing or disagreeing with the OP, nor with you. I was pointing out that there is another way to look at the speed situation, besides the obvious one. Perhaps we could say that the way one sees the speed difference depends on what speed one expects from the software one uses. If one does not regularly use software that fits in 512k, then maybe one sees the speed of such programs as a "huge boost". But, if one is accustomed to using small executables that fit in 512k and one does not regularly use software that is, e.g., 5, 10, 20m or more, then maybe one sees having to use such larger software as a "huge slowdown".
  - wolfgke 12y ago
    > I am aware of that. Of course I am not using a kernel that fits in 512k, but personally I prefer software that fits in 512k and I write and use such software regularly. The OP was talking about 512 bytes. That's a factor of 1024 in difference.
    - 101914 12y ago
      s/2k/2b/g

by 101914 12y ago

jacquesm 12y ago

No, it is fast, it runs entirely in the L1 cache. That's a huge boost compared to anything that's larger than that. He's only going off-die to do IO.

101914 12y ago
I am aware of that. Of course I am not using a kernel that fits in 512k, but personally I prefer software that fits in 512k and I write and use such software regularly. But it still does not change the point of my comment. One can either say a smaller, lighter system is "fast" or one can say a larger, heavier system is "slow". It depends on the "benchmark" one chooses. You characterize the performance of "small" software as a "huge boost". While I might characterize the performance of a "large" software as a "huge slowdown". The difference is my benchmark is small software, not large software.
- jacquesm 12y ago
  > I am aware of that. That's nice, but that did not follow from your previous comment. > Of course I am not using a kernel that fits in 512k, but personally I prefer software that fits in 512k and I write and use such software regularly. > But it still does not change the point of my comment. > One can either say a smaller, lighter system is "fast" or one can say a larger, heavier system is "slow". It depends on the "benchmark" one chooses. > You characterize the performance of "small" software as a "huge boost". > While I might characterize the performance of a "large" software as a "huge slowdown". > The difference is my benchmark is small software, not large software. So, actually you seemed to agree with the OP then. Either that or you're not making your point very effectively.
  - 101914 12y ago
    Or you completely misunderstood my point. I was not agreeing or disagreeing with the OP, nor with you. I was pointing out that there is another way to look at the speed situation, besides the obvious one. Perhaps we could say that the way one sees the speed difference depends on what speed one expects from the software one uses. If one does not regularly use software that fits in 512k, then maybe one sees the speed of such programs as a "huge boost". But, if one is accustomed to using small executables that fit in 512k and one does not regularly use software that is, e.g., 5, 10, 20m or more, then maybe one sees having to use such larger software as a "huge slowdown".
- wolfgke 12y ago
  > I am aware of that. Of course I am not using a kernel that fits in 512k, but personally I prefer software that fits in 512k and I write and use such software regularly. The OP was talking about 512 bytes. That's a factor of 1024 in difference.
  - 101914 12y ago
    s/2k/2b/g