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

Swift Numerics

swift.org

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Swift Numerics

#41

Post by Cybiote »

igouy wrote: post #36
Cybiote wrote: post #5

Earlier quoted context omitted.

Thanks, it is a well written article. The only part which tarnishes an otherwise excellent article is the language comparisons portion. Such things are best avoided as they almost always reflect the biases of or where the author has the most experience. As you acknowledge, you were unfair to Julia. Julia has excellent support for general purpose programming. It has support for multiple dispatch, a quite powerful orga…

> Setting aside the problems of microbenchmarks and unidiomatic code … We don't get to set aside problems when they would undermine a premise of your conclusion. Use of the benchmarks game as evidence must imply that you have confidence in that evidence.

It does not. Because, since both systems in comparison are in violation, when normalized to just this setting, the comparisons are meaningful. That is, while microbenchmarks are not something that should replace task relevant testing, they do have utility as a coarse indicator. The information should be taken with a large helping of uncertainty but it also points in the general correct direction in terms of relative ordering of the compared.

The reality is often that other things will dominate. Things such as computational complexity, appropriateness and optimizations of data structures in use, I/O bounds, cache locality and specific details of the problem that will tend to reduce and not magnify the differences between languages near each other in a relative ordering, when things are done properly. Or slow things majorly when things are not done properly. This holds especially if idiomatic code is not anymore expensive to write in any of the compared languages, as is the case here.

Re: Swift Numerics

#42

Post by Cybiote »

Stubb wrote: post #35
Cybiote wrote: post #18

Earlier quoted context omitted.

> stop the world GC (my car ran you over because of a random unpredictable pause!) Given a certain baseline of available resources and for the places where GC issues can be problematic (regimes I do not believe common) unpredictability of GC is the main issue, which can be readily addressed. You can for example, allocate and then manually manage or opt for a specialized JVM. If startup-time is an issue there are nati…

Can you expand on F# not being functional enough for the other 1%?

I do not believe this generalization is accurate. It wasn't me who said that but the person I quoted. F# is plenty functional but what it does lack are organizational constructs which reduce code duplication. In practice, these are not deal breakers for what you get in return (especially that you can work around them by leveraging more OOP features, which isn't necessarily a bad thing) but that as always, depends on preferences and priorities. Among functional languages, F# is pretty streamlined, believe it or not. F#'s pragmatism means the subset of Haskell that gets used in practice to keep things simple shares a fair amount of overlap with F#. Even more-so for Ocaml.

But, the person might have meant something like, if you already know Ocaml, you might complain about the lack of functors or polymorphic variants. Similarly, if you already know Haskell you might complain about the lack of higher-kinded types or GADTs. On the other hand, F# offers its own features (clean implementations of active patterns, computation expressions, type providers, async, multicore) and advantages, mostly from being able to leverage the .NET ecosystem (which also explains why those specific features are missing).

Re: Swift Numerics

#43

Post by igouy »

Cybiote wrote: post #41
igouy wrote: post #36

Earlier quoted context omitted.

> Setting aside the problems of microbenchmarks and unidiomatic code … We don't get to set aside problems when they would undermine a premise of your conclusion. Use of the benchmarks game as evidence must imply that you have confidence in that evidence.

It does not. Because, since both systems in comparison are in violation, when normalized to just this setting, the comparisons are meaningful. That is, while microbenchmarks are not something that should replace task relevant testing, they do have utility as a coarse indicator. The information should be taken with a large helping of uncertainty but it also points in the general correct direction in terms of relative…

> both systems in comparison are in violation

Invalid + Invalild != Valid

> they do have utility as a coarse indicator

Which, once again, must imply that you have confidence in that evidence.

Re: Swift Numerics

#44

Post by Cybiote »

igouy wrote: post #43
Cybiote wrote: post #41

Earlier quoted context omitted.

It does not. Because, since both systems in comparison are in violation, when normalized to just this setting, the comparisons are meaningful. That is, while microbenchmarks are not something that should replace task relevant testing, they do have utility as a coarse indicator. The information should be taken with a large helping of uncertainty but it also points in the general correct direction in terms of relative…

> both systems in comparison are in violation Invalid + Invalild != Valid > they do have utility as a coarse indicator Which, once again, must imply that you have confidence in that evidence.

Your arithmetic is not relevant to my point because as I said, when normalized to the same domain, it is valid.

> Which, once again, must imply that you have confidence in that evidence.

Nope, think of it as a bayesian update which induces a non-zero but low relative entropy, with respect to the new posterior distribution.

Re: Swift Numerics

#45

Post by igouy »

Cybiote wrote: post #44
igouy wrote: post #43

Earlier quoted context omitted.

> both systems in comparison are in violation Invalid + Invalild != Valid > they do have utility as a coarse indicator Which, once again, must imply that you have confidence in that evidence.

Your arithmetic is not relevant to my point because as I said, when normalized to the same domain, it is valid. > Which, once again, must imply that you have confidence in that evidence. Nope, think of it as a bayesian update which induces a non-zero but low relative entropy, with respect to the new posterior distribution.

> normalized to just this setting > normalized to the same domain

What do you mean by "normalized" ? What "setting" ? What "domain" ?

> Nope, think of it as …

Think of it as being honest or not being honest.

Re: Swift Numerics

#46

Post by fulafel »

zelly wrote: post #34
fulafel wrote: post #20

Earlier quoted context omitted.

Is Swift's GC real-time, then? I thought it's just normal refcounting with unbounded stop times.

No, but ARC does not have to pause all threads. Also this exists: https://developer.apple.com/documentation/swift/unsafemutabl...

So your scenario there is a separate thread that doesn't generate or free garbage? Because if it does, there will be synchronization inside malloc/free and your thread will pause. Also the Swift compiler is unpredictable about when it will use the heap instead of stack, allocations are not explicit. So it might be hard to accomplish in practice.

I agree that this special case could be more realtime with ARC, but on other GCs such an isolated worker can be implemented as a separate program instance (separate process or separate VM instance in same process) that has memory allocation and GC disabled after init.

In the other cases where you keep whe GC on, I think the low-pause GCs of today should be suitable for tasks like computer vision in cars because the pause times are so short (sub-millisecond) vs the processing time for a frame. And the generally higher performance of non-rc GC should more than make up for it.

Post reply on HN