4 ms·

I've run into a similar issue writing a ray tracer in Swift! We are even both using Peter Shirley's "Ray Tracing in One Weekend" as a reference! I'm to this day

by drew-y 9y ago

I've run into a similar issue writing a ray tracer in Swift! We are even both using Peter Shirley's "Ray Tracing in One Weekend" as a reference! I'm to this day struggling to get the performance near the level of the C++ reference implementation. I've made some improvements but overall the swift version is around 5x slower. If any one is interested the source code is available here: https://gitlab.com/youngwerth/ray-tracer/settings/repository https://gitlab.com/youngwerth/ray-tracer/settings/repository Compiled using "swift build -c release".

CyberDildonics 9y ago
You should look at the assembly to know for sure (after you have profiled and narrowed it down). With this sort of speed difference my guess is that there is either excess memory allocation going on, pointer hopping when you think you are using something by value on the stack, or both.
- maxxxxx 9y ago
  I'll second looking at the assembly code. I had a similar problem a few years ago and an assembly expert told us that we were moving data in and out of the cache all the time instead of leaving it there. We had to change the way we looped through arrays and got a huge improvement. this could be wrong but I would also guess that the Swift optimizer is not as good as the ones C++ has mainly for the reason that it's newer.
  - CyberDildonics 9y ago
    You don't need to look at assembly to avoid cache misses, you just need to understand what the language is doing under the hood in a general sense, then make sure you access memory in a way that it can be prefetched. My guess is that it is either the program being written slightly differently or that swift is doing some sort of indirection under the hood.
    - maxxxxx 9y ago
      "you just need to understand what the language is doing under the hood in a general sense" Isn't the best to find out to look at the assembly? How else can you know what the compiler and optimizer are doing?
      - CyberDildonics 9y ago
        No, understanding what the language is doing is not the same as looking at assembly or even understanding what the optimizer is doing. If swift is creating some variables on the heap and/or creating virtual tables for inheritance (I don't know much about it) then you don't need to look at the assembly to know that you are creating indirection or doing too many heap allocations.
- drew-y 9y ago
  Thanks for the advice! I'll look into that. I have not spent much time in assembly land so it should be an interesting lesson.
Insanity 9y ago
I really enjoyed that book! I've 'followed along' with a Java implementation myself: https://github.com/DylanMeeus/Raytracer https://github.com/DylanMeeus/Raytracer However I did not really care about performance here (just a toy project), so I haven't really delved into that side of it. EDIT: I get a 404 on your git link
- drew-y 9y ago
  Oops! Pasted the wrong link. It's not letting me update either. Here's the correct one: https://gitlab.com/youngwerth/ray-tracer/tree/performance https://gitlab.com/youngwerth/ray-tracer/tree/performance

by drew-y 9y ago

CyberDildonics 9y ago

You should look at the assembly to know for sure (after you have profiled and narrowed it down). With this sort of speed difference my guess is that there is either excess memory allocation going on, pointer hopping when you think you are using something by value on the stack, or both.

maxxxxx 9y ago
I'll second looking at the assembly code. I had a similar problem a few years ago and an assembly expert told us that we were moving data in and out of the cache all the time instead of leaving it there. We had to change the way we looped through arrays and got a huge improvement. this could be wrong but I would also guess that the Swift optimizer is not as good as the ones C++ has mainly for the reason that it's newer.
- CyberDildonics 9y ago
  You don't need to look at assembly to avoid cache misses, you just need to understand what the language is doing under the hood in a general sense, then make sure you access memory in a way that it can be prefetched. My guess is that it is either the program being written slightly differently or that swift is doing some sort of indirection under the hood.
  - maxxxxx 9y ago
    "you just need to understand what the language is doing under the hood in a general sense" Isn't the best to find out to look at the assembly? How else can you know what the compiler and optimizer are doing?
    - CyberDildonics 9y ago
      No, understanding what the language is doing is not the same as looking at assembly or even understanding what the optimizer is doing. If swift is creating some variables on the heap and/or creating virtual tables for inheritance (I don't know much about it) then you don't need to look at the assembly to know that you are creating indirection or doing too many heap allocations.
drew-y 9y ago
Thanks for the advice! I'll look into that. I have not spent much time in assembly land so it should be an interesting lesson.

Insanity 9y ago

I really enjoyed that book! I've 'followed along' with a Java implementation myself: https://github.com/DylanMeeus/Raytracer https://github.com/DylanMeeus/Raytracer However I did not really care about performance here (just a toy project), so I haven't really delved into that side of it. EDIT: I get a 404 on your git link

drew-y 9y ago
Oops! Pasted the wrong link. It's not letting me update either. Here's the correct one: https://gitlab.com/youngwerth/ray-tracer/tree/performance https://gitlab.com/youngwerth/ray-tracer/tree/performance