Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

10 thousand times faster Swift

medium.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: 10 thousand times faster Swift

#21

Post by mzaks »

toth wrote: post #17
mzaks wrote: post #9

Earlier quoted context omitted.

I Updated the run bench function https://gist.github.com/mzaks/e3a2dc7ccdfc2397bc26c55eb6dc8a... the output is now: Eager run ================================= 1557 ms encode 264 ms decode 34 ms use 206 ms dealloc 504 ms decode+use+dealloc 0,38 ms direct 0,32 ms using struct ================================= Total counter1 is 8644311667000000 Total counter2 is 8644311667000000 Total counter3 is 8644311667000000 Encod…

The function call is not being optimized out, it's being hoisted outside the loop. I.e., it is as if the code was written as: let result = flatuseStruct(outputData) for _ in 0.. The counter will still be correct, but you are not measuring what you think you are measuring.

This makes sense!

Changed the iteration to:

   for i in 0..
now result is around 43ms

Thanks for pointing it out. Have to check if there are so other things involved, but that might be it.

Re: 10 thousand times faster Swift

#22

Post by [deleted] »

mzaks wrote: post #9
gilgoomesh wrote: post #5

Bad news: the optimizer is moving your functions outside the loop. for _ in 0.. Looking at the assembly... the call to `flatuseStruct` is moved outside the loop in Release builds. You're only measuring 1 thousand iterations of `flatuseStruct`, not 1 million. Your red flag should have been this: > One million times decoding of a small object graph took 0.35ms That's literally impossible. That's doing 2.8 billion itera…

I Updated the run bench function https://gist.github.com/mzaks/e3a2dc7ccdfc2397bc26c55eb6dc8a... the output is now: Eager run ================================= 1557 ms encode 264 ms decode 34 ms use 206 ms dealloc 504 ms decode+use+dealloc 0,38 ms direct 0,32 ms using struct ================================= Total counter1 is 8644311667000000 Total counter2 is 8644311667000000 Total counter3 is 8644311667000000 Encod…

[deleted]

Re: 10 thousand times faster Swift

#23

Post by phpnode »

This is happening because of compiler optimisation technique called Loop Invariant Code Motion [0], which means that the author is not measuring what he thinks he's measuring (and this should be obvious from the numbers really), so the result is meaningless.

0. https://en.wikipedia.org/wiki/Loop-invariant_code_motion

Re: 10 thousand times faster Swift

#24

Post by stefs »

openasocket wrote: post #7

I might be misreading this, but that number doesn't seem possible. He says he can do 1 million decodings in 0.35ms, but that means each decoding is done in less than a third of a nanosecond , which sounds unreasonable. I'm not familiar with FlatBuffers, but surely there needs to be some sort of validation step for the data, right?

as being said above: this is probably a micro-benchmarking compiler optimization mistake. i.e.: don'tignore your result or the compiler will probably optimize it away.

Re: 10 thousand times faster Swift

#25

Post by mzaks »

to3m wrote: post #19
mzaks wrote: post #9

Earlier quoted context omitted.

I Updated the run bench function https://gist.github.com/mzaks/e3a2dc7ccdfc2397bc26c55eb6dc8a... the output is now: Eager run ================================= 1557 ms encode 264 ms decode 34 ms use 206 ms dealloc 504 ms decode+use+dealloc 0,38 ms direct 0,32 ms using struct ================================= Total counter1 is 8644311667000000 Total counter2 is 8644311667000000 Total counter3 is 8644311667000000 Encod…

You can see the problem here: First it cals CFAbsoluteTimeGetCurrent and saves the result. 0x100272dab : callq 0x1002b7b38 ; CFAbsoluteTimeGetCurrent 0x100272db0 : movapd %xmm0, -0xa0(%rbp) Here is the call to flatDecodeDirect. I guess RDI is the input. That's usual for the x64 ABI. 0x100272db8 : movq -0x100(%rbp), %rdi 0x100272dbf : callq 0x10026fb10 ; flatDecodeDirect I don't know what this next bit is for. 0x10027…

I was suspicious, I just could not put my finger on it :)

   for i in 0..
this results in around 42ms compared to C 25ms. I guess I should update my blog post :)

Thanks for your help.

Re: 10 thousand times faster Swift

#27

Post by protomyth »

"We saw that allocating memory and retain release calls where dominating when profiling. So why not just do the same bare bone thing that C does. Write a bunch of functions which read data from a byte array without allocating any objects."

Good, but this can become a problem if you are not properly clearing the buffer and suddenly start leaking data. OpenSSL is the current big example.

Re: 10 thousand times faster Swift

#28

Post by protomyth »

tempodox wrote: post #14

> ...Swift being as fast or even faster than C... Rather unlikely. To get “faster than C” you need to hand-code in assembler, and know your target CPU really well to outsmart the compiler. One advantage of C is that it's relatively easy to see what the CPU does when you look at the source. In Swift, this is no longer the case. So, unless you know Swift really well, being “as fast as C” doesn't come easily. One thing…

> To get “faster than C” you need to hand-code in assembler, and know your target CPU really well to outsmart the compiler.

Ada compilers can beat C compilers, and languages with some restrictions such as Fortran can beat C.

Re: 10 thousand times faster Swift

#29

Post by jdright »

Doing benchmarks without knowing what is doing, without understand what is happening and then talking about faster than C only shows naivité.

Hope you will use of this mistake to learn how things work and to investigate more in detail before announcing misleading and erroneus information.

I can understand the desire to beat C and that this comes from detaching software from hardware obscuring the basis of software and turning it in a kind of magic driven by faith.

Re: 10 thousand times faster Swift

#30

Post by Tloewald »

jdright wrote: post #29

Doing benchmarks without knowing what is doing, without understand what is happening and then talking about faster than C only shows naivité. Hope you will use of this mistake to learn how things work and to investigate more in detail before announcing misleading and erroneus information. I can understand the desire to beat C and that this comes from detaching software from hardware obscuring the basis of software an…

The writer disbelieved their own results, got others to double and triple check their work, and when the correct explanation emerged, published a correction. I think you're being overly harsh (and, in the end, the results were very close to C).
Post reply on HN