5 ms·
The following line will give an error if you try to compile it in Swift 3: let a: Double = -(1 + 2) + -(3 + 4) + 5 Reminds me when Golang said you should
by smegel 10y ago
The following line will give an error if you try to compile it in Swift 3:
let a: Double = -(1 + 2) + -(3 + 4) + 5
Reminds me when Golang said you should avoid using numbers greater than about 20k in your program to avoid GC problems. I.e. farcical.
- golergka 10y agoWhat. Can you give a link, please? Wasn't able to google that up.
- smegel 10y agohttps://news.ycombinator.com/item?id=3805598 https://news.ycombinator.com/item?id=3805598
- hjnilsson 10y agoYes. I would have thought this to be solved by now. What is especially scary is that very simple expressions can significantly increase compile time, and there is no easy way of knowing. What would be hilarious is if the swift dev team releases a compile profiler that shows "hot lines" that take a long time to compile, while not solving the actual issue.
- Kallikrates 10y agoThis information is currently partially available. Not line by line but definition by definition. It's hidden behind a compiler flag but there are open source tools that consume it and display it for developer consumption.
- espadrine 10y ago> Golang said you should avoid using numbers greater than about 20k in your program to avoid GC problems Isn't this unavoidable with conservative garbage collectors? The GC looks at your fields and believes your integer is a pointer… It cannot know better. Swift doesn't have that issue, but reference counting has its own risks of memory leaks through mishandled weak references, and a performance overhead.
- Dylan16807 10y agoIf you really want to use a conservative GC, you should not use the top or bottom of your address space for heap.
- solidsnack9000 10y agoScanning the heap looking for values that "look like pointers" in some indefinite way is a fairly unusual strategy. There are many GC'd languages -- Haskell and O'Caml come to mind -- without this limitation. Haskell used "pointer tagging" where every value had two bits reserved at the top end and thus Ints were limited to 30 bits. The two bits were used to tell the GC what it was looking at. Later developments side-stepped this limitation but I'm not sure how. Does ARC have an overhead relative to GC? If if it does, it at least prevents latency spikes.
- Someone 10y ago"Does ARC have an overhead relative to GC? If if it does, it at least prevents latency spikes" It doesn't prevent latency spikes. As an extreme example, create a linked list or tree with a billion nodes, and let its root go out of scope. That will call free a billion times.
- deleted 10y ago[deleted]
- solidsnack9000 10y agoDo that every request, and it will be the same each time. With GC, you can see a latency spike when every request creates such a list and they aren't freed until, due to memory pressure, many are freed all at once. Some of the requests will get stuck waiting for a linked list node and have very high latency relative to the other ones. The strength of ARC for interactive applications is its consistency.
- _ph_ 10y agoThis was in a 32 bit version of a very old Go compiler (pre 1.0?) - this should not mistaken for a current Go problem.
- millstone 10y agoHow has this been addressed in modern Go?
- hnkain 10y agoGo's GC has been precise for heap-allocated data since go1.1 (released 3 years ago) and precise for heap and stack-allocated data since go1.3 (released 2 years ago), completely fixing any GC problems with values that look like pointers. I agree that the statement about avoiding large numbers was farcical, but it was not made by "Golang" but rather by someone on the go-nuts mailing list. Your sentence makes it sound like this was general advice for people programming in go from the go team, but to the best of my knowledge this is not true.