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

Adventures in Advent of Code

davedelong.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Adventures in Advent of Code

#31

Post by jamamp »

js2 wrote: post #16

> The bug is fixed in Swift 5.7, but my computer is running macOS Monterey (12.6) and thus using an earlier version of Swift. I have since confirmed that the code works as expected on macOS Ventura. I guess the bug is apparently in the Swift runtime itself, and since Swift 5.0 and ABT stability, the runtime version is tied to the OS version. https://www.swift.org/blog/abi-stability-and-apple/ But I think that only ap…

Not only that but here is some of my output:

    $ otool -L AdventOfCode2022
    AdventOfCode2022:
        /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
        /usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 5.7.1)
        /usr/lib/swift/libswiftCoreFoundation.dylib (compatibility version 1.0.0, current version 120.100.0, weak)
        /usr/lib/swift/libswiftDarwin.dylib (compatibility version 1.0.0, current version 0.0.0, weak)
        /usr/lib/swift/libswiftDispatch.dylib (compatibility version 1.0.0, current version 17.0.0, weak)
        /usr/lib/swift/libswiftIOKit.dylib (compatibility version 1.0.0, current version 1.0.0, weak)
        /usr/lib/swift/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 6.0.0, weak)
        /usr/lib/swift/libswiftXPC.dylib (compatibility version 1.0.0, current version 6.0.0, weak)
        /usr/lib/swift/libswiftFoundation.dylib (compatibility version 1.0.0, current version 1.0.0, weak)
Not only does it say that libswiftcore is 5.7.1, but that /usr/lib/swift folder doesn't have any of those files there. Very very confusing. I don't like any of this.

I appreciate your write-up and research into all of this though! I tried googling for what runtime version of Swift is installed in Monterey and couldn't find anything. This is incredibly opaque.

Re: Adventures in Advent of Code

#33

Post by nappy-doo »

smcl wrote: post #21
stareatgoats wrote: post #2

When your code fails it's never the fault of the language. It's always ones own fault, a typo, some error in the logic, or something. Debugging always reveals that with a stone face. Always. Except > "It turns out, there was a bug in Set.intersection(_:), but it had only been discovered this past June, and the fix hasn’t made it into a public version of Swift yet. "

As someone who worked on C compilers for DSPs for a few years, I was conditioned for a while to think "compilers are broken, libraries are broken - you have no hope" for a while, when all I dealt with was our software. Obviously that's heavily influenced by what I was actually dealing with day to day and not by normal software development, but still :) One of the guys in my team handled a frantic support request from…

From your description of the bug, I think even know which compiler you worked on. I worked on a competitors compiler. The state of embedded tools in the lates 90s and early 2000s was deplorable. I'm surprised we got anything working. (I went to work for the compiler team because I was so pissed off at how poorly they worked.)

Re: Adventures in Advent of Code

#34

Post by teh_matt »

forrestthewoods wrote: post #22
sokoloff wrote: post #12

Earlier quoted context omitted.

Hat tip if you did 2021:14:2 under this constraint. I didn’t find the trick to allow that type of performance.

Is that the right day? My code for 2021:14 runs in 440 microseconds for both parts. 2021:23:2 is the only day I couldn't get under 1 second. https://github.com/forrestthewoods/aoc2021/blob/master/rust/...

I have a writeup of my 2021 solutions at https://programsareproofs.com/articles/aoc_2021.html. I got day 23 down to 31ms using Rust.

Re: Adventures in Advent of Code

#37

Post by rashkov »

mtlmtlmtlmtl wrote: post #26
disposedtrolley wrote: post #11

Earlier quoted context omitted.

Nice! I’m writing in C this year too, although I’m very much a beginner in C. What kinds of optimisations have you had to do? Are you hosting your code anywhere?

For doing it in C, by far the most useful thing you could do is implement your own generic hash table. Having a good hash table handy makes things a lot easier. Though since you're a beginner you might want to find a good library for it at first. Writing a hash table is great C exercise though, so I definitely recommend doing it at some point. I don't necessarily want to share my github as it contains my real name, b…

I think I understand how to build a hash table except for one thing: which hash function should you use? Is there a simple one that’s good enough for most things? How do you pick one?

Re: Adventures in Advent of Code

#38

Post by js2 »

jamamp wrote: post #31
js2 wrote: post #16

> The bug is fixed in Swift 5.7, but my computer is running macOS Monterey (12.6) and thus using an earlier version of Swift. I have since confirmed that the code works as expected on macOS Ventura. I guess the bug is apparently in the Swift runtime itself, and since Swift 5.0 and ABT stability, the runtime version is tied to the OS version. https://www.swift.org/blog/abi-stability-and-apple/ But I think that only ap…

Not only that but here is some of my output: $ otool -L AdventOfCode2022 AdventOfCode2022: /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0) /usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 5.7.1) /usr/lib/swift/libswiftCoreFoundation.dylib (compatibility version 1.0.0, curre…

Use DYLD_LIBRARY_PATH and DYLD_PRINT_LIBRARIES when running the compiled binary to see what's actually being loaded. It doesn't appear that DYLD_LIBRARY_PATH influences the output of otool -L.

I wasn't able to get `swift repl` to use anything but the system runtime, maybe because it's signed. Maybe it can be made to work by stripping the out the signing but to be quite honest, I'm done with this at this point.

I've been happily using Python to solve AoC. Y'all gluttons for punishment doing this in Swift:

    def part2():
        total = 0
        group = []
        for line in INPUT.splitlines():
            group.append(line.strip())
            if len(group)

Re: Adventures in Advent of Code

#39

Post by mcphage »

sokoloff wrote: post #23
forrestthewoods wrote: post #22

Earlier quoted context omitted.

Is that the right day? My code for 2021:14 runs in 440 microseconds for both parts. 2021:23:2 is the only day I couldn't get under 1 second. https://github.com/forrestthewoods/aoc2021/blob/master/rust/...

I struggled with that one; thanks for linking your code; I’ll have a look and see the trick I missed.

The key is you didn’t need to keep track of the strings, just the counts.

Re: Adventures in Advent of Code

#40

Post by tialaramex »

Volundr wrote: post #29
sokoloff wrote: post #12

Earlier quoted context omitted.

Hat tip if you did 2021:14:2 under this constraint. I didn’t find the trick to allow that type of performance.

Day 22 ( https://adventofcode.com/2021/day/22 ) is the one that nearly killed me in 2021. I did get it using a technique of breaking any overlaps into smaller and smaller rectangles, but it took like 30s to run. I looked on the AoC reddit, and honestly I still don't understand what I needed to do to make it better, but visualizing 3d spaces has always been a weakness for me.

My target is usually 1 second each, because that feels about right for my patience, rather than 1 second overall target.

My 2021 (Rust) solutions all meet that, but some only do so when optimized, and day 22 was one of those where without the optimizer I'm waiting 2-3 seconds for an answer.

IIRC the trick was to compact the indices, so e.g instead of thinking about X values of 120203 494302 and 109383 you call those 1, 2, 0. Do all the working out of which cells within the resulting tiny structure are on or off, and then expand the 1x1 cells you're talking about to their true size based on the real values instead of indices.

Post reply on HN