The "problem" at this part in the text is that the headers still have to get parsed multiple times by the preprocessor. With his approach this would not be necessary.
That said, I don't think that is that big of a problem compared to final compile time reduction.
EDIT: Disregard that, the preprocessor remembers the states of include guards. So there is literally no point.[1]
> I don't think I've ever seen any C++ code bases that follows this rule.
It's not particularly useful to do this given that the moment you include anything from /usr/include and STL that rule will get broken from under you a 100 times.
Tensorflow is just such a classic clusterfuck google project. V2 had huge breaking changes (reminiscent of angular) and tons of the apis are clunky and don’t work well together. There are like 3 different ways to save a model. It’s almost like a bunch of teams built features with no oversight.
I’m pretty sure tf is considered in maintenance mode within google as Brain and the tf creators themselves have moved to Jax. I do think Google learned a lot from tensorflow and am excited to see Jax pan out.
Pytorch is a pleasure to debug. I think pytorch jit could close the deployment gap.
The article gives credit to TF server and TFLite and so forth as being better for deployment, but leaves out the fact that those systems don't fucking work most of the time, and support is pretty much over at this point. The same goes for model support; even the models in TF's own repository are sometimes broken or don't follow the API conventions set forth in the documentation. I honestly don't know how anyone uses TF in production at this point, unless they are frozen on a specific old version and have figured out an environment that works with their specific models already.
Yeah, TensorFlow's API has definitely gotten convoluted and confusing. I think the shift from TF1 to TF2 and then later wrapping Keras in TF just caused a lot of problems.
TensorFlow seems to be spreading itself pretty thin. Maintaining so many language bindings, TensorFlow.js, TFlite, Server, etc. seem like they could all use some focus, BUT, and this is a big but, do you think if they can get each part of their ecosystem to an easily usable point that they'll have cornered the industry sector?
PyTorch is taking a much more targeted approach as seen with PyTorch Live, but I truly think that TFLite + Coral will be a game-changer for a lot of industries (and Google will make a fortune in the process). To me it seems like this is where Google's focus has lain in the AI space for the past couple of years.
> I truly think that TFLite + Coral will be a game-changer for a lot of industries
I'd like to agree. Google was very far ahead of the curve when they released Coral. I was completely stoked when they finally added hardware video encoding to the platform with the release of the Dev Board Mini.
I want them to succeed but I fear if they don't drastically improve their Developer Experience, others will catch up and eat their lunch. TensorFlow has been hard to pick up. A few years ago when I was trying to pick this up to create some edge applications, PyTorch wasn't so much easier that it seemed worth sacrificing EdgeTPU support. But now PyTorch seems much, much easier than it did then, while TensorFlow hasn't seemed to improve in ease-of-use.
Now I'm genuinely considering sacrificing TFLite / EdgeTPU in favor of, say Jetson-esque solutions just so that I can start doing something.
Note: I am an amateur/hobbyist in this context, I am not doing Edge machine learning professionally.
Yeah, I hear you loud and clear on a lot of those points. I think the most important think honestly is the fact that most PhDs use PyTorch in academia, so industry will inevitably shift to tailor to this growing supply if possible. Of course, Coral/TFLite are really useful, so a balance will be found, but it'll be interesting to see how it plays out.
Totally agree on the debugging. The fact that PyTorch is more pythonic and easier to debug makes it the better choice for a lot of applications.
Are you in research? I think TensorFlow's position in industry puts it in a kind of too-big-to-fail situation at this point. It'll be interesting to see what happens with JAX, but for now TensorFlow really is the option for industry.
Do you think TFLite + Coral devices will help breathe new life into TF?
Meanwhile PyTorch doesn't follow SemVer and always has breaking changes for every minor version increment. There's always "Backwards Incompatible Changes" section for every minor version release: https://github.com/pytorch/pytorch/releases
Even TF 1 was just an extension of Google Brain: the project that took a datacenter of CPUs in Google to distinguish cats and dogs in Youtube videos with very high accuracy. I remember when Jeff Dean was talking about it the first time, it felt like magic (though it still feels like it, it’s just more optimized magic :) ).
I think PyTorch c++ api is less mature and harder to compile into other projects. Tensorflow started with the c++ api exposed which is why the graph format is so stable and favorable to deployment in heterogeneous environments.
Yes it relies on the target being static when capturing the training data, but it’s ok for the background to move. We were actually surprised by how well it works on moving objects without being trained on them. In the post you can see Julius riding on a scooter and that is an unseen example with a detector that was only trained on static scooters.
Ive noticed that the rentals on the market, while cheaper are generally lower quality. It seems to me that many landlords are opting for airbnb, where you can find 1 fully furnished 1 bedrooms for 2k$ a month rather than lock in a rent controlled tenant at the current prices.
I've noticed this as well - for house rentals in my area, the size seems to scale with price, and there doesn't seem to be anyway to scale up quality (there are some exceptions to this, but it's mostly true).
No, they don't. Their safety record is incredibly good, especially considering you're zipping along at 500 mph in an aluminum balloon at 30,000 feet with flaming engines and surrounded by jet fuel. They really are a triumph of engineering.
yes, but also with 100+ years of engineering, for far fewer companies/nations, and with trillions (more?) thrown at the discipline. Software engineering is, what, 50 years old, tops?
> Software engineering is, what, 50 years old, tops?
I've been working in this industry for nearly 45 years now. I still see endemic vulnerability to single points of failure, and little recognition of that.
Heck, the SolarWinds hack was first discovered by a security company because it had compromised their own internal systems and gone undetected for some time.
Given that software engineering is part of aerospace engineering, some of it is part of that engineering success.
But a key aspect of this is that one does not develop software for airplanes the same way and with the same constraints/goals as other areas of software engineering.
If anything, aerospace engineering is a prime example of how software can be made more reliable by tolerating failures instead of relying on it not to fail, to come back to GP's point about failure-tolerant designs.
In my day at Boeing, nobody considered that the pilot might be a bad actor. Unfortunately, that was a mistake. It turns out pilots can be bad, and now there are procedures for that.
Funny that Boeing are capable of considering that, but not a single sensor failing and how that might impact a system designed to hide the actual aerodynamics of the plane.
Boeing really aren't a good example for anything besides negligence and how to game regulators.
Testing model code tends to be very difficult unless you design your training loop with lots of abstractions and dependency injection which makes the code less explicit and difficult to understand. For example, try to look at the Tensorflow Estimator framework. Absolutely awful to use but is well tested.
Exactly. The tests are concerned with integrating the ML component into the broader picture of requirements and engineering. Engineers are not really interested in why the statistics of a model is failing. And should never be (that's why testing model internals in TFML is an anti-pattern)
The other day I said “Hay Siri, take me to Buena Vista park.” She responded “the entrance buena vista Avenue?” and I responded: “oops I actually meant corona height park” and she instantly started navigation there. I actually held a productive conversation with a computer. Magical.
The issue with voice assistants is frequently after they get the thing wrong the first time I might not bother interacting with them again. Especially if there are other people around.
That’s what you get for creating a closed system for connected speakers. You get trounced by bigger fish who can do it just as well and have wider integration.
Errr, why?