Yeah. Swift is unique in that it features both incredibly slow compile times (in the good case, in bad cases it can abort due to timeouts on one line, 40 character expressions) AND slow runtime speed, especially when not optimising.
Code without the optimiser can easily be several hundred to more than a thousand times slower than optimised code. And of course the optimiser makes compile times even slower.
That's because Character is very, very different from ASCII in Swift (a character in Swift holds an extended grapheme cluster. See https://developer.apple.com/reference/swift/character). I also doubt the way they compute its ASCII value is optimal:
extension Character {
var asciiValue: UInt32? {
return String(self)
.unicodeScalars
.filter{$0.isASCII}
.first?
.value
}
}
Certainly if it is optimal, but probably also if it isn't, I would change the program to not do that conversion in inner loops.
Isn't the "scripting" part just automatically compiling behind the scenes before running? It's not an interpreter or a VM. So the code runs just as fast as the compiled version, it's just that you pay a startup cost.
That's true between a debug build and just running it as a script I believe. But a release version will be optimized, I imagine if they compared a debug build to the scripted version they'd perform similarly.
Yep totally, going to take another pass to try and make it faster. This was just a make it work experiment. Had a few fun troubles with random, but at the moment it just crawls :(.
starting from inside the arc4random call you have double float multiplication, then cast to uint32, then the arc4rand call, then the double cast for the uint32 result and then a double float division. this adds up in instructions.
Did not expect to see "cfdrake" when I initially clicked the link - nice port! :)
Agreed with e28eta - I actually saw RubikSwift demoed at Swift Summit a few days ago as well and enjoyed it. Definitely check it out if you're interested in the topic.
I thought this was going to be a link to [1], from a talk given at Swift Summit a couple days ago. I haven't really looked at the code for either one to compare them, but for people who are interested, here's a second simple genetic algorithm in Swift (found in RubikSwift/GeneticsSolver.swift)
swift is a fantastic language, but it's absolutely not as mature as other language you're probably used to. In particular, you may experience a lot of compiler crash, typing bugs, and very bad compile time.
But i'm 100% certain it's going to be one of the most used language server side in the coming years.
I wanted an example of a simple genetic algorithm in swift, couldn't find it so I wrote it from something I found in python. 0% special, but thought i'd share. Take it or leave it, dude.
Just to add to this, if you don't like it, don't click on it/comment on it. The front page algorithm put this item here because people upvoted it, not because it queried a random selection of the user base and asked if it was "worthy".
c'mon everyone knows genetic population is 30
(I kid I kid but that number has an interesting story https://statswithcats.wordpress.com/2010/07/11/30-samples-st... )