4 ms·

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

by jdright 10y ago

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.

Tloewald 10y ago
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).
- archgoon 10y ago
  > The writer disbelieved their own results No they didn't. "To be honest it is hard for me to say, how exactly it happened that we got 70 times faster than C, but it is a measurable fact."' You also don't publish a headline "10,000 times faster Swift" if you don't believe your own results. At best, this is click-bait.
  - jdright 10y ago
    This. I may have been harsh, but I won't assume a rookie mistake only. And being 1.8x (45ms to 25ms?) is not even "near" but is surely the expected from a "modern" language.
  - mzaks 10y ago
    The good thing about any narrative, it resonates with different people on different levels. The blog post is in deed titled "10,000 times faster Swift". I though it will be a catchy title even though 6 seconds to 0.35 ms is not factor of 10,000. I thought about renaming the title to 500 times faster Swift, which would be rathe more accurate insight of current findings, but than what the hack. It's a blog post. I didn't published a scientific paper. I just reflected on my resent work. The main points of the Blog posts wehere anyways about how it is possible to make low level optimisations to make Swift programs faster. And as a matter of fact the Loop-invariant code motion was a valid technique to get the same result. Result being sum of payload content. The compiler was smarter than me. It gave me the same result doing 250times less work. I find it impressive. I must be honest I am not fluent in assembly this is why I could not figure it out by myself. Was I suspicious? Absolutely!!! But the facts were in my face. Shouldn't I publish an article, where I am not sure why I got what I got? If I wouldn't publish the article, I would not figured out the truth and wouldn't learned form this experience. And after all, this post is about performance pitfalls in Swift language. The comparison with C was almost accidental. I would compare it with C++ if I would have a Windows machine, as the benchmark for C++ project has Windows specific code. I also consulted with the author of flatcc, who is much more relaxed about my blog post than you are :) This blog post is about learning something. I learned something before I wrote this post I shared it and now I learned even more. You should try it yourself. Maybe not as satisfying as criticising, but it also has it's moments.
    - deleted 10y ago
      [deleted]
  - Tloewald 10y ago
    It would have been more honest to modify the headline and put corrections inline, for sure. (Still, 170x faster is not bad — I would still have clicked :-) )

by jdright 10y ago

Tloewald 10y ago

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).

archgoon 10y ago
> The writer disbelieved their own results No they didn't. "To be honest it is hard for me to say, how exactly it happened that we got 70 times faster than C, but it is a measurable fact."' You also don't publish a headline "10,000 times faster Swift" if you don't believe your own results. At best, this is click-bait.
- jdright 10y ago
  This. I may have been harsh, but I won't assume a rookie mistake only. And being 1.8x (45ms to 25ms?) is not even "near" but is surely the expected from a "modern" language.
- mzaks 10y ago
  The good thing about any narrative, it resonates with different people on different levels. The blog post is in deed titled "10,000 times faster Swift". I though it will be a catchy title even though 6 seconds to 0.35 ms is not factor of 10,000. I thought about renaming the title to 500 times faster Swift, which would be rathe more accurate insight of current findings, but than what the hack. It's a blog post. I didn't published a scientific paper. I just reflected on my resent work. The main points of the Blog posts wehere anyways about how it is possible to make low level optimisations to make Swift programs faster. And as a matter of fact the Loop-invariant code motion was a valid technique to get the same result. Result being sum of payload content. The compiler was smarter than me. It gave me the same result doing 250times less work. I find it impressive. I must be honest I am not fluent in assembly this is why I could not figure it out by myself. Was I suspicious? Absolutely!!! But the facts were in my face. Shouldn't I publish an article, where I am not sure why I got what I got? If I wouldn't publish the article, I would not figured out the truth and wouldn't learned form this experience. And after all, this post is about performance pitfalls in Swift language. The comparison with C was almost accidental. I would compare it with C++ if I would have a Windows machine, as the benchmark for C++ project has Windows specific code. I also consulted with the author of flatcc, who is much more relaxed about my blog post than you are :) This blog post is about learning something. I learned something before I wrote this post I shared it and now I learned even more. You should try it yourself. Maybe not as satisfying as criticising, but it also has it's moments.
  - deleted 10y ago
    [deleted]
- Tloewald 10y ago
  It would have been more honest to modify the headline and put corrections inline, for sure. (Still, 170x faster is not bad — I would still have clicked :-) )