4 ms·

I recently built SPECint2k6 for RISC-V (on JH7110) with and without -fomit-frame-pointer and to my surprise the default (with frame pointers) was a tiny bit fas

I recently built SPECint2k6 for RISC-V (on JH7110) with and without -fomit-frame-pointer and to my surprise the default (with frame pointers) was a tiny bit faster (though so close to the noise floor that I'll settle for "the same"). I haven't dug into why frame pointers seem to cost nothing on RISC-V but it's likely that it's just that there's plenty of registers.

deleted 4y ago
[deleted]
xobs 4y ago
Unfortunately, it increases the code size by 10%. I was looking into this just last week, and can confirm that it's still a problem on the latest version of Rust nightly: https://github.com/tock/tock/pull/1660 https://github.com/tock/tock/pull/1660 I wish we could have frame pointers, because they would make working in embedded land so much easier and more reliable, but a 10% increase in code size just isn't worth it.
- andrekandre 4y ago
  perhaps slightly naive question, but whats the actual performance implication 10% increase in code size? (10% slower at runtime?)
  - MobiusHorizons 4y ago
    In the embedded world, you are limited by the amount of storage space available for your code. In a lot of cases the code is in flash or one time programmable rom memory on the microcontroller. Even if you have off-chip storage, you usually have to load the code into ram in order to run, and ram size is also quite limited. For low end microcontrollers it's common for rom / ram sizes to be on the order of 32kb (although they go much lower than that). In this world, the most common optimization level is -Os (or -Oz if available) because running out of storage space means you need a more expensive microcontroller, which increases the cost of each device you are selling, and might require a redesign of the PCB.
  - FullyFunctional 4y ago
    There isn’t a simple relationship. Ignoring the code space issue (and I$ pressure), the added instructions in this case are for function entry/exit so if that not on your hot path, it might not matter at all.
  - xobs 4y ago
    As others have noted, the issue isn't execution speed. Rather it's the fact that the memory and disk requirements increase by 10% which has a measurable effect on cost. We currently load the entire program into RAM to make things easier, so anything to lower storage requirements is a win. Someday we'll be able to mmap the disk to do XIP, but we don't have that implemented yet.
    - andrekandre 4y ago
      i see, so mostly cost/resource issue, appreciate the answer!

deleted 4y ago

[deleted]

xobs 4y ago

Unfortunately, it increases the code size by 10%. I was looking into this just last week, and can confirm that it's still a problem on the latest version of Rust nightly: https://github.com/tock/tock/pull/1660 https://github.com/tock/tock/pull/1660 I wish we could have frame pointers, because they would make working in embedded land so much easier and more reliable, but a 10% increase in code size just isn't worth it.

andrekandre 4y ago
perhaps slightly naive question, but whats the actual performance implication 10% increase in code size? (10% slower at runtime?)
- MobiusHorizons 4y ago
  In the embedded world, you are limited by the amount of storage space available for your code. In a lot of cases the code is in flash or one time programmable rom memory on the microcontroller. Even if you have off-chip storage, you usually have to load the code into ram in order to run, and ram size is also quite limited. For low end microcontrollers it's common for rom / ram sizes to be on the order of 32kb (although they go much lower than that). In this world, the most common optimization level is -Os (or -Oz if available) because running out of storage space means you need a more expensive microcontroller, which increases the cost of each device you are selling, and might require a redesign of the PCB.
- FullyFunctional 4y ago
  There isn’t a simple relationship. Ignoring the code space issue (and I$ pressure), the added instructions in this case are for function entry/exit so if that not on your hot path, it might not matter at all.
- xobs 4y ago
  As others have noted, the issue isn't execution speed. Rather it's the fact that the memory and disk requirements increase by 10% which has a measurable effect on cost. We currently load the entire program into RAM to make things easier, so anything to lower storage requirements is a win. Someday we'll be able to mmap the disk to do XIP, but we don't have that implemented yet.
  - andrekandre 4y ago
    i see, so mostly cost/resource issue, appreciate the answer!