4 ms·

That is a concern, but Pernosco is challenging to implement. We built on rr, which was already state of the art, and we've added a lot of secret sauce. Of cours

by roca 7y ago

That is a concern, but Pernosco is challenging to implement. We built on rr, which was already state of the art, and we've added a lot of secret sauce. Of course the smart big tech companies could duplicate it, but it is not simply a matter of putting a team together and grinding out the code.

lmeyerov 7y ago
Makes sense -- in-house NIH is generally better for a few key things (ex: integration) and ultimately worse for most. Good luck!
souprock 7y ago
Nah, rr is not state of the art. :-) About a dozen years ago my workplace built something like that in-house. I see you've made progress. You have the reverse dataflow. You can't debug an arbitrary firmware or bootloader or OS however, and you can't properly debug a bunch of interacting systems. Simics also seems to have most of that. I last checked about half a dozen years ago, so the other features might now also be supported. It's not cheap, but you could model all the computers of a factory or aircraft all at once. You could then step forwards and backwards as desired, coherently examining the RAM and other hardware of all the computers as you please. I wouldn't be surprised if dozens of similar tools have been built.
- roca 7y ago
  Fair, but that's not rr's target market. AFAIK Simics is not competitive with rr or Pernosco in recording overhead or scalability when you're debugging a Linux user-space application that executes, say, a trillion instructions.
- roca 7y ago
  Out of those things, the one we do want is the ability to debug a collection of interacting distributed processes. Our goal would be a bit different though: splice together recordings from different nodes of a real system, rather than simulating all the nodes from the ground up. So our implementation approach will have to be different.

4 ms·

That is a concern, but Pernosco is challenging to implement. We built on rr, which was already state of the art, and we've added a lot of secret sauce. Of cours

by roca 7y ago

lmeyerov 7y ago
Makes sense -- in-house NIH is generally better for a few key things (ex: integration) and ultimately worse for most. Good luck!
souprock 7y ago
Nah, rr is not state of the art. :-) About a dozen years ago my workplace built something like that in-house. I see you've made progress. You have the reverse dataflow. You can't debug an arbitrary firmware or bootloader or OS however, and you can't properly debug a bunch of interacting systems. Simics also seems to have most of that. I last checked about half a dozen years ago, so the other features might now also be supported. It's not cheap, but you could model all the computers of a factory or aircraft all at once. You could then step forwards and backwards as desired, coherently examining the RAM and other hardware of all the computers as you please. I wouldn't be surprised if dozens of similar tools have been built.
- roca 7y ago
  Fair, but that's not rr's target market. AFAIK Simics is not competitive with rr or Pernosco in recording overhead or scalability when you're debugging a Linux user-space application that executes, say, a trillion instructions.
- roca 7y ago
  Out of those things, the one we do want is the ability to debug a collection of interacting distributed processes. Our goal would be a bit different though: splice together recordings from different nodes of a real system, rather than simulating all the nodes from the ground up. So our implementation approach will have to be different.