[GPGPU-Sim] Possible stalls when `allocate_cu` always choose the oldest subcore.

[Ivecia]

Hi, community. I'm wondering whether it's a mistake for allocate_cu to choose the oldest subcore instead of a subcore containing a valid (has valid instruction, and has a free cu) instruction.

Assuming that there are IADD for subcore 0, ready for operand collect at cycle 5100, and another IADD for subcore 1, ready for operand collect at cycle 5101. No other instructions for subcore 2 and 3. At this time, current implementation will choose subcore 0, since it is the oldest. But if cus in subcore 0 are all busy, it will NOT check if we can collect operands for IADD in subcore 1.

Is it a mistake or a kind of feature here? Thanks!

• get_ready_reg_id(): Always choose the oldest subcore with a ready instruction, but did not consider whether it's free to allocate a cu.

unsigned get_ready_reg_id() {
  // for sub core model we need to figure which reg_id has the ready warp
  // this function should only be called if has_ready() was true
  assert(has_ready());
  warp_inst_t **ready;
  ready = NULL;
  unsigned reg_id = 0;
  for (unsigned i = 0; i < regs.size(); i++) {
    if (not regs[i]->empty()) {
      if (ready and (*ready)->get_uid() < regs[i]->get_uid()) {
        // ready is oldest
      } else {
        ready = &regs[i];
        reg_id = i;
      }
    }
  }
  return reg_id;
}

[JRPan]

@FJShen Is this similar to what you found?

[Ivecia]

@JRPan Yes, it's similar, and I did not look in detail for #498 before I wrote this issue :(.

#498 said: "When certain conditions coincide (e.g. one warp issued a lot of SFU op, the other issued a lot of INT op), one warp may be starved of time slots for a long time".

Here I provide another issue that one subcore may be starved (although it has valid instructions) due to other subcore (because of insufficient cus).

We may merge these issues together.

[JRPan]

No worries.

This may be a problem for workloads using specialized warps, etc. Is there anything specific you are looking for here? I can ask him to PR his fixes. Or I have a simple, perfect OC implementation that bypasses all these and results in 1.5x to 2x faster simulation time.

Let me know what you need. Thanks

[Ivecia]

Oh, take it easy. I'm just recording this for the community, who may find some strange behaviors in the future. I think this issue had hidden from users since the subcore model introduced, and if you don't look inside the simulator, you may never find it.

If someone want to improve the modeling of Operand Collector, I'm happy to join the discussion. Personally, I have other methods to walk around these issues in my research.

So feel free to let it remains or make a PR for it. Thanks for your feedback.