Comments (5)
Hi @guangqianpeng,
tcmalloc
improves the benchmark results. Withaco_amount=1000000
andcopy_stack_size=56B
, the tcmalloc version achieves 37ns peraco_resume()
operation but the default takes 66ns. Why? In this case,aco_resume()
does not allocate memory, which is really confusing...
I think the main reason of such result is because the tcmalloc
has many specialized optimizations on memory efficiency and locality especially when the allocation of small objects, which is much better than the vanilla glibc allocator.
- When copying stack, you use
%xmm
registers to optimize small memory copying. But according to my benchmark, this does not make many differences. I guessmemcpy()
already takes advantage of these registers. Do you have more benchmark results?
Here is actually a knack in the code like __uint128_t xmm0
: the gcc would try to use sse to optimize the operations about the __uint128_t
data type (whereas the clang does not, as far as I know). So if you want to use such sse optimization in libaco now, you could use gcc to compile the libaco into a static library and then use a linker to link it with any object file you like. Also, you could choose to use objdump
to inspect the actual machine code generated by the aco_resume
function.
Even when there is no such sse enhancement provided by the compiler, such "very-short memcpy inline" with these general purpose registers are still more efficient than to call the libc memcpy directly. That is because, in the case of such short copy, the cost of a function call is not small enough to neglect anymore. So, there would be some gains anyway.
Maybe in the future we should choose to use the sse directly instead of counting on such compiler's behavior ;-) But I'm afraid that such plan has to be postponed since there is a much more important thing to do now, i.e. the #22.
I will be very grateful to you for answering my questions :-)
All the discussions and questions about libaco would always be welcomed here. Just feel free to open any new issue you like :D
from libaco.
2. Do you have more benchmark results?
I did some benchmark about such conditional memcpy-inline in the past and did get the result I want. But there were no records. I would like to do another test as soon as I get another spare time.
from libaco.
-
I did use
perf
tool to check L1 dcache miss rate of the two versions, tcmalloc version achieved about the half miss rate of glibc. I guess there was false sharing or other cache problems and tried to solve it without tcmalloc. But I finally failed :-( -
I did have inspect the assembly code of
co_resume()
and saw suchmovqd %rbx %xmm1
things, I also trace into the glibc and found that memcpy finally call__memcpy_avx_unaligned()
, which use AVX instruction sets. What I didn't think of is that the overhead ofmemcpy()
call cannot be ignored, especially for small stack.
BTW, the libaco project is great, I am looking forward to your next version (especially the co schedualer).
from libaco.
BTW, the libaco project is great, I am looking forward to your next version (especially the co scheduler).
Thank you very much for your kind encouragement, @guangqianpeng, and I would try to finish the next release as soon as possible ;-)
from libaco.
BTW, the libaco project is great, I am looking forward to your next version (especially the co scheduler).
Thank you very much for your kind encouragement, @guangqianpeng, and I would try to finish the next release as soon as possible ;-)
How about the next release? :)
from libaco.
Related Issues (20)
- Document c standard library dependencies
- Status and Future Plans of libaco
- can libaco support yield/resume between threads? HOT 3
- Provide way to return error to caller instead of calling `abort()` on failed assertions HOT 1
- is it worth to create coroutine inside coroutine?
- which one better to pass argument to co function
- 关于libco bug的疑问
- Thread local storage support HOT 1
- Feature request: Ability to return a value from aco_yield() HOT 1
- Feature Request: aco_get_co() return NULL when the caller is main co HOT 4
- is 120byte the lowest we can have? possible to lower this? HOT 1
- Do libaco coroutines run on different CPUs at the same time. i.e. does the program performance benefit from having multiple CPUs HOT 2
- Question: which is faster, creating new coroutines or reusing old coroutines HOT 3
- resume multiple coroutines in parallel HOT 1
- Integrate into our io engine? HOT 1
- add arm32/aarch64 support for android and ios HOT 1
- `aco_amd64_inline_short_aligned_memcpy_test_ok` size alignment
- whether this description is incorrect
- Few questions about proper usage
- is aco_exit necessary?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libaco.