You have to carefully define what you are optimizing for. I assume you are writing your programs to solve some problem. We can then ask:
How long does it take to solve the problem with C or CUDA? This cycle time includes both the development time and the running time. It may include the time required to acquire necessary skills and equipment.
How much does it cost to solve the problem with C or CUDA? This includes developer salary, energy costs, overhead, transaction costs, and opportunity cost.
So unfortunately, this is more about project management than about benchmarking.
There are a couple of extremes where the answer is simple.
There are use cases where the development effort dominates. This happens when your problems are very specific and each need substantial development effort, and each program is only run a couple of times. E.g. if I need 5 days to write the program, then it doesn't really matter if I get an answer in 12 hours or 45 minutes.
There are use cases where raw performance is most important, e.g. in high-performance realtime systems. Increased development, energy, and hardware costs are more tolerable than getting an answer 5 milliseconds too late.
And there are uses cases where the program is run so much that hardware and development costs are quickly amortized. Performance per watt starts to dominate the calculation.
I'm currently involved in a small research project where the run time dominates over development time, and the long cycle time results in significant opportunity cost. This means we are effectively time-limited, not cost-limited. To shorten the cycle, we're throwing more resources at development and hardware, whereas energy costs are negligible. If switching to a higher-performance technology doubles the development effort but doubles performance, that's absolutely worth it for us.