avitzur

Good times, good times.

Well howdy, old-timer! That brings back some memories. (The '80s: after the dinosaurs, but before the giant armored sloths - back when neutrinos were massless and Λ was zero.)

Did you work on Axiom? That was the finest crafted computer algebra system.

You're welcome

Erin Ottmar's https://graspablemath.com is probably the best modern exploration of the idea.

At Apple? None whatsoever. It was a surprising fluke that even in the Apple of 1993. It only succeeded because so many people helped. That Apple was beleaguered at the time may have given employees a certain devil-may-care attitude towards their own job security and a willing to cross certain lines to assist us or look the other way.

Btw, I wrote that, Ask Me Anything.

Amy O'Leary tells my favorite version of this story on This American Life:

https://www.thisamericanlife.org/284/should-i-stay-or-should...

Yes, the numeric evaluation is vectorized via the Accelerate Framework's vForce and vDSP APIs. That is a significant performance improvement. The numeric evaluation remains a hotspot with vectorization, as that is where the app does most of its work.

Applications / Utilities / Grapher is a different application (formerly Curvus Pro X from Arizona Software) which replaced the original Mac OS 7 Apple menu Graphing Calculator because I was very slow porting to Mac OS X.

That thread describes me working through performance issues in the initial port eight months ago. Those cases perform adequately now. Parsing is not a bottleneck. Walking the bytecode remains a performance hotspot, as that is where all the numeric calculations occur, but no more or less so comparing the C++ and Swift implementations.

I did investigate maintaining the flex/bison parser, since its generated state machine C code is more robust than my handwritten recursive descent parser when presented with pathological input. However, as you say, since I need a Swift data structure in the end, there is little to be gained and a lot of complication bridging via a C-FFI.

Thank you! I can't believe that was thirty years ago. It feels unreal.

The math is internally represented as a tree for display and editing. Most of the performance critical code is the numeric evaluation when graphing. For that, the math is compiled to a linear byte code which vastly improves locality of reference and is an opportunity to apply optimizations such as common subexpression elimination and loop invariant code motion.

Most of the performance critical sections are numeric computation loops. I use the Unsafe APIs where profiling shows that the bounds-checking overhead is significant.

In principle, I could get rid of reference counting overhead by using value types or immutable data. I couldn't see a simple path to doing that without re-architecting everything (with no guarantee that the end result would not just have different performance issues.) For the moment, I'm awaiting compiler improvements before re-evaluating the tradeoffs. There is certainly room for the compiler to reason better on eliding retain/release. https://github.com/apple/swift/issues/58549

Yes, the code does use Accelerate where applicable. That is one component of the numeric evaluation. It addresses the lowest level of things like evaluate the sin function on every array element, or multiply there arrays element wise. Performance tuning is a game of whack-a-mole. There's always another bottleneck somewhere.

I wrote the blog post. AMA.

It has been in continuous development since 1985. Before the port, parts were in C, C++, Objective-C, and Objective-C++, as well as Lex, Yacc, GLSL, and Python. Will do the top-level comment.

Yes, precisely. I looked into bridging to C++ initially, but it was impractical.

Still working on it.

https://www.youtube.com/watch?v=m5h9KPkJ7eE

THANK YOU!!!

We were trying to build an iPad with 1992 technology. http://arno.org/arnotify/2010/01/penmac/

Thank you!

50, and still programming on the same codebase I started when I was 18.

Yes, as well as FullWrite and many other products.

When the hardware failure is more frequent than failures in your software, we can consider that "good enough" (for consumer-level applications.)

I started programming on an HP-65 in the 70's. That was before graphing calculators, though.