Re: [Gc] libatomic-ops nios2
Marek Vasut <[email protected]> Thu, 28 Jan 2016 11:54:14 +0100
| Newsgroups | gmane.comp.programming.garbage-collection.boehmgc |
|---|---|
| Message-ID | <[email protected]> |
On Thursday, January 28, 2016 at 08:36:25 AM, Chung-Lin Tang wrote: > On 2016/1/28 12:28 PM, Marek Vasut wrote: > >> You may want to go the direct kuser route. A little bit of inline asm > >> > >> > should get you more performance compared to calling into libgcc, and > >> > nios2 softcores can really use that bit of optimization. That's also > >> > what I did in glibc. > > > > Aren't those gcc builtins expanded in place anyway ? Or do you see some > > real performance drop if you don't use the kuser helper directly ? > > No, the GCC builtins are not expanded inline, the __sync_* routines are > implemented in libgcc. Hm, I didn't know. Thanks! > I have no evidence of significant performance gaps, though at least under > PIC, the nios2 function call overhead is a bit costly. However, my > concerns may be unfounded. I'd suspect the switch from userland to kernel and back might be the most constly bit here. But that'd have to be profiled to really see if that is the case. > > btw. I tried making two patches, one for libatomic-ops and one for bdwgc, > > > find them below, but I have no clue if they are correct: > I'm not familiar with this code to review, but if there is a generic > implementation ready to use, then it should work for nios2. You can just > start there. Yeah, that's what I think as well. The generic implementation might be a good start and further optimizations can come later. Thanks! Best regards, Marek Vasut