0

How fast std::time(NULL) comparing to just reading variable? I plan to use std::time(NULL) in low-latency application for trading. I'm thinking what is better:

  • just call std::time(NULL) every time I need it
  • in special thread (which I already have) periodically update global variable and assign std::time(NULL) to it, read this variable from all other places from other threads

Second appraoch is less accurate, but will it be faster? I don't need accuracy, I need speed. If second approach makes sense then how should I declare my variable? volatile std::time_t or std::atomic<std::time_t> or something else? I write this variable from one thread and read it from many threads.

Oleg Vazhnev
  • 23,239
  • 54
  • 171
  • 305
  • 4
    *I don't need accuracy, I need speed.* Are you sure speed without accuracy is a good idea? – Frédéric Hamidi Apr 28 '14 at 14:06
  • 1
    Entierly platform (and version thereof) dependent. (e.g. on some it's the overhead of a system call too, on others a system call is not needed). Thus, you need to measure it on your platform. – nos Apr 28 '14 at 14:07
  • Possible duplicate: http://stackoverflow.com/questions/6498972/faster-equivalent-of-gettimeofday – Bill Lynch Apr 28 '14 at 14:17
  • Did you write a test application that profiles each method? – D Drmmr Apr 28 '14 at 14:25
  • volatile is certainly incorrect. You need atomic to avoid data races if it's updated in one thread and read in another. – jcoder Apr 28 '14 at 14:26

2 Answers2

1

Implement a utility thread (or process) that gets the clock a few times a second (whatever meets your accuracy demands) and saves it in memory.

Implement an interface that returns the time by reading it from this location rather than making an expensive OS call and having a possible context switch into the kernel (depending on the OS platform you're developing for). For you, this interface will probably be class template with policy in order to avoid virtual calls and make the calls eligible for inlining.

You do it this way so that you can easily create mocks and such in unit tests, or change the implementation later.

oz10
  • 153,307
  • 27
  • 93
  • 128
  • 1
    so you assume that `std::time(NULL)` is more expensive than reading variable? probaly `std::time(NULL)` just do the same thing - returns me value of some variable? – Oleg Vazhnev Apr 28 '14 at 14:19
  • @paxos Interesting solution:(genuine) doubt, can this solution suffer from contention as he will need to make the access to such variable atomic via some lock mechanics? – sergico Apr 28 '14 at 14:27
  • 1
    I've implemented this solution in a collections head end (not a trading app but an app that reads/parses exchange data). In our case, we had utility process updating shared memory and other processes reading from shared memory. We stored the time as uint64_t, no need for synchronization because of that. – oz10 Apr 28 '14 at 14:50
  • @javapowered what std::time(NULL) does is platform dependent. Reading time on windows usually required context switch into the kernel (very expensive) but was much faster on linux. This solution works on any platform and has the added advantage of making unit testing easy. – oz10 Apr 28 '14 at 14:52
0

As far as I understand you do not need the correct time, but just time deltas, and quickly (as you state you do not need time accuracy) As mentioned by @nos the best way is platform dependent.

If your hw platform is an x86 architecture probably the faster way to get delta times is to use the CPU timer via some inline assembly (using the instruction is RDTSC) but be aware that x86 CPUs can reorder instructions in the pipeline.

sergico
  • 2,595
  • 2
  • 29
  • 40