chrislattner   18

Apple’s culture of secrecy wore down Swift creator & Xcode lead Chris Lattner, say friends [Update] | 9to5Mac
Academics said back in October that Apple’s ‘off the scale’ approach to secrecy was one of the reasons behind the high-profile problems with Apple Maps, as the company’s researchers were cut off from other work being done in the field.

Fear of being isolated from the wider scientific community was also said to be hampering Apple’s hiring efforts within the AI field, a claim the company seemingly acknowledged a couple of months later when it announced that it’s AI researchers would, after all, be allowed to publish papers on their work. The first such published paper appeared shortly after the announcement.

BI also pointed to an incident in 2015 when Apple’s entire networking team quit over Apple’s refusal to allow them to participate in an industry-wide network security forum known as the Open Compute Product. The resignations led to Apple changing its mind and joining the OCP.
(Chris Lattner has tweeted his reaction to the BI piece, calling it “fabricated or speculating”.)
apple  chrislattner  llvm  swift  spunti  sda  soa  xcode  personaggi  open  problemi 
january 2017 by nicoladagostino
LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #1/3
Undefined behavior exists in C-based languages because the designers of C wanted it to be an extremely efficient low-level programming language. In contrast, languages like Java (and many other 'safe' languages) have eschewed undefined behavior because they want safe and reproducible behavior across implementations, and willing to sacrifice performance to get it. While neither is "the right goal to aim for," if you're a C programmer you really should understand what undefined behavior is.
c  clang  undefined  llvm  chrislattner 
may 2016 by dlkinney
[swift-evolution] Proposal: Universal dynamic dispatch for method calls
Swift is another case of a hybrid model: its semantics provide predictability between obviously static (structs, enums, and global funcs) and obviously dynamic (classes, protocols, and closures) constructs. A focus of Swift (like Java and Javascript) is to provide an apparently simple programming model. However, Swift also intentionally "cheats" in its global design by mixing in a few tricks to make the dynamic parts of the language optimizable by a static compiler in many common cases, without requiring profiling or other dynamic information.. For example, the Swift compiler can tell if methods in non-public classes are never overridden (and non-public is the default, for a lot of good reasons) - thus treating them as final. This allows eliminating much of the overhead of dynamic dispatch without requiring a JIT. Consider an “app”: because it never needs to have non-public classes, this is incredibly powerful - the design of the swift package manager extends this even further (in principle, not done yet) to external libraries. Further, Swift’s generics provide an a static performance model similar to C++ templates in release builds (though I agree we need to do more to really follow through on this) -- while Swift existentials (values of protocol type) provide a balance by giving a highly dynamic model. The upshot of this is that Swift isn’t squarely in either of the static or dynamic camps: it aims to provide a very predictable performance model (someone writing a bootloader or firmware can stick to using Swift structs and have a simple guarantee of no dynamic overhead or runtime dependence) while also providing an expressive and clean high level programming model - simplifying learning and the common case where programmers don’t care to count cycles. If anything, I’d say that Swift is an “opportunistic” language, in that it provides a very dynamic “default" programming model, where you don’t have to think about the fact that a static compiler is able to transparently provide great performance - without needing the overhead of a JIT. Finally, while it is possible that a JIT compiler might be interesting someday in the Swift space, if we do things right, it will never be “worth it” because programmers will have enough ability to reason about performance at their fingertips. This means that there should be no Java or Javascript-magnitude "performance delta" sitting on the table waiting for a JIT to scoop up. We’ll see how it works out long term, but I think we’re doing pretty well so far. TL;DR: What I’m really getting at is that the old static vs dynamic trope is at the very least only half of the story. You really need to include the compilation model and thus the resultant programmer model into the story, and the programmer model is what really matters, IMHO.
programming  swift  chrislattner  static  dynamic  compilers  optimization  jit 
december 2015 by dlkinney
AnandTech: Upgrading and Analyzing Apple's Nehalem Mac Pro
Fantastic deep-dive into the Nehalem Mac Pro from AnandTech. The best parts are the deep dive <a href="http://www.anandtech.com/mac/showdoc.aspx?i=3597&p=10">into the heatsinks on the dual-CPU model</a> (fun fact: it uses custom packaging on the CPUs!) and a look into the <a href="http://www.anandtech.com/mac/showdoc.aspx?i=3597&p=9">potential performance boost that can be gained by switching to SSD</a>. I haven't worked myself up to paying the price for one of these yet, but the want is certainly there, and reviews like this are certainly a huge help to my purchasing process. (via <a href="http://nondot.org/sabre/">chris</a>)
myblog-posted  Nehalem  MacPro  ChrisLattner  Apple  AnandTech  SSD  IntegratedHeatSpreader 
july 2009 by areitz

related tags

2014  acm  anandtech  apple  award  behavior  c  clang  comparison  compiler  compilers  design  dynamic  history  integratedheatspreader  jit  llvm  llvmprogramming  macpro  myblog-posted  nehalem  news  open  optimization  osx  personaggi  problemi  programming  programminglanguage  read  sda  soa  spunti  ssd  static  swift  swiftlang  tesla  teslamotors  undefined  xcode 

Copy this bookmark:



description:


tags: