ฝัง
- เผยแพร่เมื่อ 5 พ.ย. 2017
- Website: pacificplusplus.com/
Resources: github.com/pacificplusplus/co...
Twitter: / pacificplusplus
Abstract:
This talk describes how low latency systems can be developed in C++, demonstrating common coding techniques used to reduce code execution times. While automated trading is used as the motivation for this talk, the topics discussed are equally valid to other domains such as game development and soft real-time processing.
About the speaker:
Carl's interest is in low latency/high frequency proprietary trading systems, which has seen him work in Australia, The UK and The Netherlands. In terms of coding and engineering, he considers himself brutally pragmatic. Carl is also an active member of the SG14 study group, making sure that requirements from the automated trading industry are represented as C++ evolves. He has a Ph.D. and a M.Sc. from the University of Canterbury, graduating in 2006. Carl likes to drink Belgium beer and ski, sometimes concurrently. - วิทยาศาสตร์และเทคโนโลยี
What a talk, the most useful speech I have listened to about C++, and I have used the language for more than a decade.
So many insights from this presentation, one of the best I have ever heard!
Interesting how most of this is done in games, especially FPS server code but also in rendering hot path.
Solid advice here. Agree with most of it.
Great talk!
In your own hashmap you don't really need that pointer to the key-value if you store them in another array at the same bucket array index. Also, on x86-64 in 64-bit mode using 64-bit integers generates 1-byte longer assembly instructions putting slightly more pressure on instruction cache.
Does he have a twitter or blog?
twitter.com/ProgrammerCarl
Do it on a fu… fpga and call it a day.
Also why a operating system?
Can you tell me how you send packets without using the socket layer? Are you doing it directly in the kernel?
Delete has hopefully a state maschine behind it else it would be a terrible way to allocate memory.
The standard memory manager has to be able to handle any request at any time. It's only as optimized as a completely generic implementation can be. And it's great, as long as you are mallocing everything at once and then freeing everything at once, preferably in reverse order.
You only have to consider rolling your own allocators if you expect new and delete / malloc and free numerous times over the program's life, which could cause heavy fragmentation with the default allocator .
because you may require a significant chunk of code to work on an already existing operating system? like a video game?
"how can you send packets without using the socket layer" a socket is just an ip address connected with a port, with some implementation behind it. You can easily avoid using that.
the code for delete is written to accommodate the operating system in a generic way. In windows api code I have strong memories of writing my own heaps for classes of fixed sizes.
kernel bypas, i.e. DPDK
Damn... I can put only one like...
Isn't C faster? If it's possible is it better to use C than C++?
No, neither is faster. It depends how you use them.
And will C++ be replaced by Rust in finance?
rust is a joke .
Thats many to avoid.. Avoid this avoid that.. its like u better avoid to use c++ :(
No, it's not. The things that should be avoided do not depend on the programming language, because basically, one should avoid certain patterns which are language agnostic. The same problems may appear in a program written in any language. The only thing that will be different is the actual code in this programming language that will have caused them.
Avoid C++? These were tips for low latency/high frequency workloads, not regular workloads and I doubt you'd find another language that would allow aggressive finetuning of your code.
Was it too much for you to handle? Performance tuning is essential for that specific domain as a lot depends on the time being taken to execute - which part did you not understand about that?
@@Adolf1Extra ? C
Why C++ over C if such optimizations required? Just curious
it's not a small buck different, some of the instrument has a quite large dollar per tick value, so this type of tick-by-tick trading is extremely profitable.