- boost's thread or std's thread? - 3 Updates
- compiler generate jmp to another jmp - 2 Updates
| JiiPee <no@notvalid.com>: May 17 09:05PM +0100 On 17/05/2017 20:46, Paavo Helde wrote: > different approaches if possible, for comparison. The time to focus on > top performance will come maybe after some 5 years when you have > gathered enough experience. Thanks. Yes I would agree. The performance is not necessary hugely better unless statistics/tests proves about it. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: May 17 10:59PM +0200 On 17.05.17 20.40, JiiPee wrote: > I am thinking with one or my friends whether we should use boost's > thread or std's thread? Are they very similar? I have never used boost's > thread-system. Which one you would use? thanks If in doubt prefer the std version unless you have good reasons not to do so. Marcel |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 17 03:43PM -0700 On 5/17/2017 11:40 AM, JiiPee wrote: > I am thinking with one or my friends whether we should use boost's > thread or std's thread? Are they very similar? I have never used boost's > thread-system. Which one you would use? thanks Use the standard. |
| David Brown <david.brown@hesbynett.no>: May 17 11:39PM +0200 On 16/05/17 15:26, Rick C. Hodgin wrote: > instruction cache, but I am not aware that they will automatically > flush the pipeline if they detect a write to an address that's > already been decoded and is in the pipe. Minor point - perhaps all /x86/ processors snoop data writes and update the L1 instruction cache and/or flush instruction caches. But that certainly does not apply to /all/ processors. Most processors, I think, assume that self-modifying code is a bygone technique that dropped out of fashion many decades ago, and do not waste the rather significant design effort and silicon space needed for such detection. On the ARM and PPC, IIUIC, if you want to change code you write it to memory (as data writes), then flush the relevant addresses in the data cache to push the change into memory or combined cache levels, then discard the relevant lines in instruction cache, then issue an instruction pipeline flush instruction. /Then/ you can start executing from the new code. |
| David Brown <david.brown@hesbynett.no>: May 17 11:43PM +0200 On 16/05/17 17:01, Rick C. Hodgin wrote: > you can minimize instruction cache pollution by dynamically altering > your code at runtime so that algorithms which won't be required in > this runtime instance are no longer present, etc. What is "true optimisation" ? Do you think that being able to modify code at run-time somehow brings orders of magnitude greater performance? The whole point of instruction caches is that code that is often used gets into the cache, while code that is not used, stays out. This happens automatically in the cache - you don't need to /modify/ the code to achieve the effect. In some operating systems (such as Linux), code that is not executed on a particular platform might not even be loaded off the disk when you run a program. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment