Apple Open Sources Swift Benchmark Suite

Discussion in 'iOS Blog Discussion' started by MacRumors, Feb 8, 2016.

  1. MacRumors macrumors bot

    MacRumors

    Joined:
    Apr 12, 2001
    #1
    [​IMG]


    [​IMG]
    Apple today announced that its Swift benchmark suite is open source, just over two months after making its Swift programming language open sourced as promised at the 2015 Worldwide Developers Conference.

    Apple's Swift benchmarking suite is designed to track Swift performance with 75 benchmarks that cover multiple important Swift workloads, libraries with commonly needed benchmarking functions, drivers for running benchmarks and displaying performance metrics, and a utility for comparing benchmark metrics across multiple versions of Swift. The Swift benchmark suite is available on GitHub.

    Introduced in 2014 and launched alongside iOS 8 and OS X, Swift is Apple's programming language built for iOS, OS X, watchOS, and tvOS, designed to work with Cocoa and Cocoa Touch frameworks along with Objective-C while also being widely accessible. In 2015, Apple debuted Swift 2 with new features like advanced error handling and syntax enhancements.

    Article Link: Apple Open Sources Swift Benchmark Suite
     
  2. CFreymarc, Feb 8, 2016
    Last edited: Feb 8, 2016

    CFreymarc macrumors 68040

    Joined:
    Sep 4, 2009
    #2
    I'd like to see an adoption graph of Swift since its release. For example, how many app submitted to the store are written in Swift vs. Objective-C on a month-to-month trend. I somehow feel an Apple employee is reading this with that exact graph in an other window on their desktop they wish they could release.

    First, they announce it out of the blue at WWDC 2014. Then real quite the first year with many complaining about a buggy compiler. Then WWDC 2015, it goes open source to a rumored very soft acceptance. Now the benchmark tools are open source.

    I'm still running into a lot of firms with a "No Swift" development policy because:

    1) many say it is an immature language
    2) mixing languages in an existing project makes it too complex
    3) a catch-22 of few with Swift experience but few willing to commission projects in the language

    This reminds me of the early Java days in the 90's where it took almost ten years for it to really take off in the industry.

    One place I'm seeing Swift adopted well is in Frameworks development where many new APIs are written in Swift. Then these Frameworks integrate into apps written in Swift or Objective-C.
     
  3. ghost187 macrumors 6502a

    ghost187

    Joined:
    Mar 18, 2010
    #3
    From what I heard the only app that's written in Swift by Apple is the calculator app. So, I think it'll be decade before it really catches on like you said.
     
  4. GenesisST macrumors 68000

    GenesisST

    Joined:
    Jan 23, 2006
    Location:
    Where I live
    #4
    Well, you don't rewrite an app because there's a new language, Maybe calc was chosen as a proof of concept.

    At my company, all apps are obj-c and will remain so for the foreseeable future.

    Maybe new UI could be written in swift, for the hell of it. Maybe it's like what they say about going black... :)

    Keep in mind that this C++ guy accepted to move a legacy app to ARC about a year or so ago. (I don't regret that at all now!)
     
  5. ghost187 macrumors 6502a

    ghost187

    Joined:
    Mar 18, 2010
    #5
    Well from what I hear, coding with Swift takes considerably less time, and developers have nothing but good things to say about it.
     
  6. cerberusss macrumors 6502a

    cerberusss

    Joined:
    Aug 25, 2013
    Location:
    The Netherlands
    #6
    Since they have the core part of Swift running on Linux, it'll be fun to compare the two platforms :)
    --- Post Merged, Feb 8, 2016 ---
    I'm a freelance iOS developer. The market is very good and I can pick my projects. Those companies you mention will not get me to sign onto their projects :)
    --- Post Merged, Feb 8, 2016 ---
    Meh... It's nice in that it leaves the old Objective-C idiosyncrasies behind, and they designed it such that it prevents a whole class of bugs from being created. So it takes a bit less time, that's true.
     
  7. CFreymarc, Feb 8, 2016
    Last edited: Feb 8, 2016

    CFreymarc macrumors 68040

    Joined:
    Sep 4, 2009
    #7
    I'm sure we are looking at difference sides of the same elephant. What class of apps are you working on for this? Are these mostly start from scratch concepts, rewrites of existing products or mixed language work?

    Would not be surprised if I am running into an "old dog, new tricks" situation here with a few long term clients. I'm working with a lot of ported code and some real stick-in-the-mud managers that go back to the 80's.

    One criticism I've heard is the compiler will occasionally not put out code as expected with classic early compiler bugs such as skipped execution lines and strange offsets in the debugger.

    Swift is a breath of fresh air in the programming language space but it has a long way to go. A waterfall event will be when it gets strong support on a non-Apple platform.

    One thing I do like is it compiles to native machine instructions. I have seen way too many languages claim to be native but the application specific code does not cross compile to native instructions. Instead it's just some form of byte-codes bound to a native VM for a specific platform. Ironically, these types of "semi-native" environments have the VM is usually written in C!
     
  8. badNameErr macrumors regular

    Joined:
    Jun 13, 2007
    Location:
    Above ground.
    #8
    What problems are you encountering with this?
    Mixing ObjC/Swift in the same project works great even with my huge decade+ old OSX code bases!
     
  9. Michael Goff macrumors G3

    Michael Goff

    Joined:
    Jul 5, 2012
    #9
    Yet at the same time, OS level things seem to be coded in Swift. So it's a grab bag.
     
  10. cerberusss macrumors 6502a

    cerberusss

    Joined:
    Aug 25, 2013
    Location:
    The Netherlands
    #10
    I guess there's some selection going on, because I prefer projects that have a (relatively) new code base. I also got lucky in the sense that I started working for my own, doing staff augmentation for a team within a big European airliner that is very innovative and keen on using new technologies.
     
  11. rdas7 macrumors regular

    rdas7

    Joined:
    Nov 17, 2002
    Location:
    London, England
    #11
    I'm leading an App team at the moment, we are 2 months away from delivering an App that has been developed 100% in Swift. We are in a unique position that we've found a FTSE 250 company that were looking to develop a greenfield app in 2015/16 though.
     
  12. Keane16 macrumors 6502a

    Keane16

    Joined:
    Dec 8, 2007
    #12
    It seems as though at Apple they are re-writing chunks of their code in Swift.

    Some nice little titbits in the interview for those interested:

    https://daringfireball.net/thetalkshow/139/federighi-gruber-transcript
     
  13. segmentPage macrumors newbie

    segmentPage

    Joined:
    Oct 12, 2015
    #13
    I see many people talking about low adoption of swift by developers. And I would like to point it out that, this is totally wrong.
    Some complex apps like Facebook, Instagram, Youtube and many of Apple's own apps are already written in Objective-C.
    It will be a sheer waste of time to immediately re-write these apps when there is no significant improvement in performance and hence the companies are not wasting resources on rewriting.
    On the contrary, many new developers are learning Swift and find it easier due to its similarity with some other languages. Also most developers are starting the development of their new apps in Swift.
    It will take some time for people to adopt Swift.
    For reference, python was launched in 1991 and Django, the popular web framework in python came in 2005.
    Swift is just 2 years old and their already are several stable web frameworks popping up without Apple taking any particular interest in such developments.
    So I guess 5-10 years down the line, we might even see full stack developers doing complete development in Swift.
     
  14. mdriftmeyer macrumors 68030

    mdriftmeyer

    Joined:
    Feb 2, 2004
    Location:
    Pacific Northwest
    #14
    As a former colleague of Craig's that Engineering management speak for we have two concurrent branches for development, multiple branches for testing and above all that three separate branches for architecture modifications as we proceed forward.

    In short, we have legacy, current and possibly future, at various levels of the operating system using this new language and our tried and true 30+ years of OOA/OOD.

    First and foremost, if you expect them to use Swift to write their kernel then don't complain about performance. Whether embedded iOS or desktop OS X, the XNU hybrid kernel has C++ I/O Kit for device drivers [not Swift], has Mach Messaging in ObjC and C for the Kernel proper.

    Then there is the FreeBSD file system layer which you sure as heck won't covert to Swift. This leaves UI Frameworks because writing FoundationKit/CoreFoundation in Swift will be a test project for a decade. How come? You have billions of lines of code from third parties to hundreds and billions of internal code to transition, if at all.

    Unless Swift makes it into LLVM/Clang proper it's DOA for the forseable future. Whether it is akin to Go Bindings or what have you, not having that mature stack to then coordinate within the entire LLVM/Clang community of tools Apple has invested billions into developing it seems like Lattner needs to be reigned in.

    Tons of work has gone into the following:

    http://clang.llvm.org/cxx_status.html

    Bringing C03-C11 has been a lot of lifting.

    A huge truck load of work on OpenCL SPIR-V, Vulkan and other low level APIs using OpenCL 2.x has been building.

    Even OpenMP support up to 4.5 is merging in.

    Apple throwing a bone to Linux with Swift OpenSource isn't going to cut it until it's moved into LLVM/Clang proper.
     
  15. CFreymarc macrumors 68040

    Joined:
    Sep 4, 2009
    #15
    It is more of a "level 8 and 9" problem for those who know the Seven Layer Networking model. Yes, technically they did a good job mixing the two. Issue is that I'm finding managers who are more "source code gardeners" where they look all over checked in code making sure it is nice and readable. Two higher level languages in a single project grinds a lot of gears. One manager has it analogous to "a booth written with one chapter English with the other chapter in French" were you need someone knowing both languages to take on the project.
    --- Post Merged, Feb 9, 2016 ---
    I can see where you are coming from. It would be nice to see a demographic of what developers from different countries are using Swift over Objective-C. My current swath of projects are very hardware oriented with shared source code between the accessory and the app. That is done in C as it is the only common language between Xcode and the accessory's micro-controller IDE. From that, you get to be very "C centrist" not wanting to switch syntax conventions.

    I had one friend who is a rather achieved academic in the CS / EE realm. He did a critical review of Swift a while back. One thing that really got to him was the syntax of Swift. He swore some of the syntax was intentionally changed from normal convention to avoid any copyright claims of other compilers. There are several essays on line about the oddities of Swift syntax that you can search covering this subject.
     
  16. akac macrumors 6502

    akac

    Joined:
    Aug 17, 2003
    Location:
    Colorado
    #16
    All of our new code is Swift. Now we have a huge app - so its going to be a long time before we are anywhere close to most of it being Swift. But I've been doing all new code since about 6 months ago in Swift, and my other engineers only the last 2-3 months. Swift makes so many things better, we'd love to sit down and convert existing code to Swift…but there is little point unless we hit upon a good reason.
     
  17. cerberusss macrumors 6502a

    cerberusss

    Joined:
    Aug 25, 2013
    Location:
    The Netherlands
    #17
    Ah yes, that seems reasonable. I've done hardware related stuff in the past. We developed custom electronics to read out a sensor. The fpga would send me a byte stream and I'd unravel it with a bit of C or Python. Satisfying work and I wouldn't want to do it in Swift, you just can't easily do pointer arithmatic.
     
  18. CFreymarc macrumors 68040

    Joined:
    Sep 4, 2009
    #18
    You just brough up one of the biggest issues with both Swift. Like Java, it forces you to have everything derived from an object construct. While quite portable, it isolates you from memory addressing, pointer casting and other efficient coding techniques where very few op codes are generated.
    --- Post Merged, Feb 9, 2016 ---
    Sure there are serveral attempts at automated Objective-C to Swift translation tools out there. This reminds me of the seismic shift from Pascal to C++ at Apple in the early to mid-90's. One former engineer I met at a conference mentionsed they translated the then Finder source code from Pascal to C++ in two weeks with some automated scripts. It was so successful, it was out on a developer CD.
     
  19. badNameErr macrumors regular

    Joined:
    Jun 13, 2007
    Location:
    Above ground.
    #19
    I hate those guys! :( You have my sympathies.

    That's totally understandable in context. Although, the C interop in Swift is really good.
     
  20. cerberusss macrumors 6502a

    cerberusss

    Joined:
    Aug 25, 2013
    Location:
    The Netherlands
    #20
    It's not as bad as with Java. For example there are nice structs, which Java doesn't have IIRC. But I don't like the casting required everywhere:

    Code:
        import UIKit
        var buf = [UInt8](count: 10, repeatedValue: 0)
        // Fill buffer with A to J
        for (var i = 0; i < buf.count; i++) {
            buf[i] = 65 + UInt8(i) // 65 = A
        }
    
    So far so good. But each time you do something with the buffer, you'll have to tell Swift that -- yes -- you know what you're doing. And then to print the buffer, you'll have to tell Swift exactly how to deal with the uint8:

    Code:
        // Calculate pointer to print contents
        buf.withUnsafeBufferPointer { (pbuf: UnsafeBufferPointer<UInt8>) -> UnsafePointer<UInt8> in
            for (var j = 0; j < pbuf.count; j++) {
                let p = pbuf.baseAddress
                print(Character(UnicodeScalar((p+j).memory)))
                println(String(format:" = 0x%X", (p+j).memory))
            }
            return nil
        }
    
    Output:
    Code:
        A = 0x41
        B = 0x42
        C = 0x43
        D = 0x44
        E = 0x45
        F = 0x46
        G = 0x47
        H = 0x48
        I = 0x49
        J = 0x4A
    

    So all these good Swift things kinda get in the way and I don't like how the code looks, either.
     
  21. Janichsan macrumors 6502a

    Janichsan

    Joined:
    Oct 23, 2006
    #21
    Something like this?
     
  22. CFreymarc macrumors 68040

    Joined:
    Sep 4, 2009
    #22
    Thanks for the link. However, the TIOBE index has a lot of criticism. Many claim it is more a "fad tracker" with an excessive amount of student projects taken into consideration that may not be relevant for professional developers.
     
  23. Krevnik macrumors 68030

    Krevnik

    Joined:
    Sep 8, 2003
    #23
    These are all signs that you are trying to bend the language to a particular way of doing things rather than actually doing things in the language. A couple things to point out in the code you wrote:
    - Using C-style enumeration rather than the range enumerator, and not specifying a type for "i", which would help with the casting behavior. Swift defaults to the default int size of the platform if you don't.
    - Using a buffer rather than just letting the array size itself appropriately to fit the content (pre-sizing is a minor optimization).
    - Should be using Character or UnicodeScalar instead of UInt8. Swift doesn't assume that you are in ASCII-land, which is part of your trouble. Since you are writing code to fill a character buffer, but not actually using characters, but ASCII.
    - Instead of enumerating the array, you create an unsafe pointer and do another C-style loop. This is the worst way to iterate through an array you already have.
    - Why even use a buffer like this when a String can be sliced up and converted into the UnicodeScalars if you need the underlying value. You can also create slices of arrays if you want to only pass around a piece of an array (circular buffers for example).
    - While UnicodeScalar and Character are somewhat incomplete if you need the ability to do math on the underlying value, you can always add them as operators to make the code doing the manipulation cleaner rather than keeping values that don't represent what you are actually working with.

    For grins, I wrote up a version of the sample code you wrote using UnicodeScalar. Either way it is a bit contrived as the real solution will depend on how these things interact with the rest of the program. It also avoids extending array (which it should) for printing the hex values, which does require a few steps to get it right.

    Code:
    func +<T:UnsignedIntegerType>(lhs: UnicodeScalar, rhs: T) -> UnicodeScalar {
      return UnicodeScalar(lhs.value + UInt32(rhs.toUIntMax()))
    }
    
    func printArrayAsHexValues(buffer: [UnicodeScalar]) {
      for element in buffer {
        print(String(format: "%@ = 0x%X", String(element), element.value))
      }
    }
    
    var startChar = UnicodeScalar(65)
    var characterBuffer:[UnicodeScalar] = []
    for offset : UInt32 in 0...9 { // Range is inclusive
      characterBuffer.append(startChar + offset)
    }
    
    printArrayAsHexValues(characterBuffer)
    
    This code has the advantage of being easier to read, clearer behavior, and the customizations are actually reusable. Again, this isn't really code I'd actually write in Swift in practice, since I'd either be using an integer buffer for raw data (possibly an NSMutableData if on Apple platforms), and a string for a character buffer.

    One of the other issues with Swift is that the standard library is woefully tiny. You basically have to marshal out to a framework, and AppKit/UIKit/GCD are first class citizens, while the POSIX APIs are very much not.

    But the code you wrote suggests someone with a strong C background, possibly spending a lot of time in low level code, and not having spent much time with Obj-C, Python, C# or other modern languages used in app and tool development.

    Honestly, swift is something you need to dig into, and unfortunately, if you are doing so off an Apple platform, the frameworks just aren't there to support a rich experience. And even if you are on an Apple platform, AppKit and UIKit prevent certain features of Swift from being used to their full potential because you can get more functional programming styles done in Swift, but then things like CoreData rip you back into the world of reference types of multi threading hell that results.

    As for the comment of the GP that comments about efficient coding techniques, those are the same techniques that create crashes, security holes and other fun. All for the opportunity to maybe outsmart the compiler, when in many cases, bugs I've run into are because someone tried to outsmart the compiler, and got bit later because it forced the compiler into undefined parts of the C spec, or it actually prevented the optimizer from finding an even faster optimization because mucking with the pointers turned the whole process into something opaque.
     
  24. badNameErr, Feb 10, 2016
    Last edited: Feb 10, 2016

    badNameErr macrumors regular

    Joined:
    Jun 13, 2007
    Location:
    Above ground.
    #24
    It occurred to me that it would be possible to hack together a script which examined all the apps inside "iTunes Media/Mobile Applications/" and figured out which ones use Swift code*. This isn't indicative of the entire ios app store obviously but could still be interesting.

    *does the app include /Frameworks/libswift*
    --- Post Merged, Feb 10, 2016 ---
    Couldn't you just....

    Code:
           buf.forEach {
               print(Character(UnicodeScalar($0)))
               print(String(format:" = 0x%X", $0))
           }
    
     

Share This Page