3 ms·

Come on, boy, stop joining headline Party!:) You should make sure you truly understand what's the meaning of the word "latency". Your story is not unique[1].

Come on, boy, stop joining headline Party!:) You should make sure you truly understand what's the meaning of the word "latency". Your story is not unique[1]. The basic concept is: latency != 1/throughput. I have no interest in your codes. Just from your README, I am sure you make mistakes. Here, do you ask several questions for you before publishing eye-catching headline? Such as, 1. what's the cost of one CAS op (and maybe volatile)? 2. what's the timing accuracy in Java? 3. what's the latency of one main memory accessing? 4. ok, more pitfalls in Java, OS and micro-benchmark coming... if you have basic understanding to question#1-3, you may not claim "20 ns is possible. The best I've gotten with a bare bones optimized test was about 16 ns" yourself. [1] http://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications/ http://www.infoq.com/articles/High-Performance-Java-Inter-Th...

vardump 11y ago
> Come on, boy, stop joining headline Party!:) Seriously. Saying things like that make you look really bad - no one will take you seriously. I got that 16 ns with cache-line aligned carefully tuned assembler. No false sharing. And it most definitely didn't use CAS, but FAA. I used CPU TSC timers. That said, I'm pretty sure you can achieve close to that in Java as well. 20-40 ns latency between two CPU cores on same socket wouldn't surprise me at all. Throughput can be even higher, if you start to batch messages. Anyways: 1) Cost of CAS depends on contention. About 15 ns in any case without contention. 2) Timing accuracy on Java... Well not that I really use Java much, but I'd imagine it's exactly same as on C++, if you can access TSC somehow. Nothing prevents from ping-ponging messages between two threads either a few million times -- that way even low resolution timer is more than enough. Yes, 20ish ns latency is doable. 3) Who cares about memory latency, the point is to communicate by cache line sharing. Main memory would defeat that. 4) ?
- hyperpape 11y ago
  http://shipilev.net/blog/2014/nanotrusting-nanotime/ http://shipilev.net/blog/2014/nanotrusting-nanotime/ By coincidence, this was reposted today. Findings: nanotime probably has >= 15ns latency, and >= 30 ns granularity.
  - vardump 11y ago
    So does 1M ping pongs give me sufficient resolution? It's not like it makes sense to measure a single transaction, but say, 1M in a chain.
    - jinmingjian 11y ago
      Yes, as you are ware that, it is hard to measure the latency correctly especially in your nano-second level.
- jinmingjian 11y ago
  Hi, vardump, my true point here is clear: latency != 1/throughput. Can you accept this viewpoint? 1. our talking context is Java. There is nothing about assembler here. I assume you are the author of this library. If not, let me know. 2. I spend a little time to see your perf source[1]. Tell us what's ping-pongs you did? 3. Even your micro testing Thread busy waiting on cores. The OS still has the right to do thread scheduling. Who gurantees you have not a cache line missing for next time running? This is possible by a relative complex steps in Java. But it is obvoiusly not shown in all of your codes and notes. 4. The cache line is not sharing directly. They become coherent by MESI or its variants[2]. You busy waiting causes the coherence storm for RFO, which is expensive in theory. Although some relieve these pain, this is another topic. You need to show these latencies or at least why you do not consider them in the nanosec level? 5. if assumed "15 ns in any case without contention" is right, then 1ns for the latency of rest instructions? The cost of above cache coherence? The cost of a function call pro/epi in hotspot-JITed codes? The overhead by volatile of forbidding some JIT? OK, how about counting on GC? 6. Ping-pong is still not good enough for nanosec level latency measurement. Because, you have the "endpoint effect". At least, you need to copy? what's the memory copy throughput latency?(note again: latency != 1/throughput) 7. Finally, your codes just show the throughput of batch writing/reading into/from memory by Java's mmap kinds. It is not the "p2p" latency in common sense. I just leave HN readers to make their own judgement: I plan to announce a pico-second message-passing library because I have done the TB level L1 cache throughput in my Haswell core. [1] https://github.com/caplogic/MappedBus/blob/master/src/perf/io/mappedbus/perf/MessageReader.java https://github.com/caplogic/MappedBus/blob/master/src/perf/i... [2] http://en.wikipedia.org/wiki/MESI_protocol http://en.wikipedia.org/wiki/MESI_protocol

vardump 11y ago

> Come on, boy, stop joining headline Party!:) Seriously. Saying things like that make you look really bad - no one will take you seriously. I got that 16 ns with cache-line aligned carefully tuned assembler. No false sharing. And it most definitely didn't use CAS, but FAA. I used CPU TSC timers. That said, I'm pretty sure you can achieve close to that in Java as well. 20-40 ns latency between two CPU cores on same socket wouldn't surprise me at all. Throughput can be even higher, if you start to batch messages. Anyways: 1) Cost of CAS depends on contention. About 15 ns in any case without contention. 2) Timing accuracy on Java... Well not that I really use Java much, but I'd imagine it's exactly same as on C++, if you can access TSC somehow. Nothing prevents from ping-ponging messages between two threads either a few million times -- that way even low resolution timer is more than enough. Yes, 20ish ns latency is doable. 3) Who cares about memory latency, the point is to communicate by cache line sharing. Main memory would defeat that. 4) ?

hyperpape 11y ago
http://shipilev.net/blog/2014/nanotrusting-nanotime/ http://shipilev.net/blog/2014/nanotrusting-nanotime/ By coincidence, this was reposted today. Findings: nanotime probably has >= 15ns latency, and >= 30 ns granularity.
- vardump 11y ago
  So does 1M ping pongs give me sufficient resolution? It's not like it makes sense to measure a single transaction, but say, 1M in a chain.
  - jinmingjian 11y ago
    Yes, as you are ware that, it is hard to measure the latency correctly especially in your nano-second level.
jinmingjian 11y ago
Hi, vardump, my true point here is clear: latency != 1/throughput. Can you accept this viewpoint? 1. our talking context is Java. There is nothing about assembler here. I assume you are the author of this library. If not, let me know. 2. I spend a little time to see your perf source[1]. Tell us what's ping-pongs you did? 3. Even your micro testing Thread busy waiting on cores. The OS still has the right to do thread scheduling. Who gurantees you have not a cache line missing for next time running? This is possible by a relative complex steps in Java. But it is obvoiusly not shown in all of your codes and notes. 4. The cache line is not sharing directly. They become coherent by MESI or its variants[2]. You busy waiting causes the coherence storm for RFO, which is expensive in theory. Although some relieve these pain, this is another topic. You need to show these latencies or at least why you do not consider them in the nanosec level? 5. if assumed "15 ns in any case without contention" is right, then 1ns for the latency of rest instructions? The cost of above cache coherence? The cost of a function call pro/epi in hotspot-JITed codes? The overhead by volatile of forbidding some JIT? OK, how about counting on GC? 6. Ping-pong is still not good enough for nanosec level latency measurement. Because, you have the "endpoint effect". At least, you need to copy? what's the memory copy throughput latency?(note again: latency != 1/throughput) 7. Finally, your codes just show the throughput of batch writing/reading into/from memory by Java's mmap kinds. It is not the "p2p" latency in common sense. I just leave HN readers to make their own judgement: I plan to announce a pico-second message-passing library because I have done the TB level L1 cache throughput in my Haswell core. [1] https://github.com/caplogic/MappedBus/blob/master/src/perf/io/mappedbus/perf/MessageReader.java https://github.com/caplogic/MappedBus/blob/master/src/perf/i... [2] http://en.wikipedia.org/wiki/MESI_protocol http://en.wikipedia.org/wiki/MESI_protocol