Slashdot Mirror

← Back to Stories (view on slashdot.org)

Deep Learning May Need a New Programming Language That's More Flexible Than Python, Facebook's Chief AI Scientist Says (venturebeat.com)

Posted by msmash on from the in-pursuit-of-a-better-language dept.

Deep learning may need a new programming language that's more flexible and easier to work with than Python, Facebook AI Research director Yann LeCun said today. From an interview: It's not yet clear if such a language is necessary, but the possibility runs against very entrenched desires from researchers and engineers, he said. LeCun has worked with neural networks since the 1980s. "There are several projects at Google, Facebook, and other places to kind of design such a compiled language that can be efficient for deep learning, but it's not clear at all that the community will follow, because people just want to use Python," LeCun said in a phone call with VentureBeat. "The question now is, is that a valid approach?" Further reading: Facebook joins Amazon and Google in AI chip race.

17 of 263 comments (clear)

  1. Easy by mobby_6kl · · Score: 4, Funny

    Just use C++

    1. Re:Easy by Anonymous Coward · · Score: 4, Insightful

      True, but even C/C++ and Assembly doesn't provide an "easy" way to do threading, which is the issue.

      Scripting languages, basically do not do threading, of any kind, at all. They're too slow to synchronize across threads, which makes invoking threads inside them fruitless.

      While C is ultimately the right language to do everything in (not C++) , the real issue is that cpu's are expanding in cores, just like GPU's have, yet GPU's have standardized more or less on just three API's, OpenGL, Direct3D and Vulkan. So if you can write a program against Vulkan, you have as close to bare hardware as you are going to get. But for CPU's, there is still a 57 flavors of rubbish programming languages and no standard runtime that works for all of them, at best most of these programming languages are still developed in C or C++ and thus require a complete C AND C++ runtime to function.
      Python is not written in Python. Java is not written in Java. If a language can not compile itself, it's not flexible enough to be used for any of the three main corner stones of software development: Operating Systems, Applications, and Games. While you certainly can write an application or game with a scripting language, it will be slow, it will be limited by the operating system's own libraries (eg 32-bit libraries on a 64-bit OS as just one example) and generally require more maintenance than simply writing it in C to begin with.

      Memory overflow errors are caused by people learning programming languages like Java first instead of C, because if you learn C first, you then learn how to initialize memory, and how big memory chunks actually are.

    2. Re: Easy by Anonymous Coward · · Score: 4, Funny

      Ostensibly, yes. Honestly, most of it was hacked together with Perl.

    3. Re:Easy by thereddaikon · · Score: 5, Insightful

      True, but even C/C++ and Assembly doesn't provide an "easy" way to do threading, which is the issue.

      Nothing is easy to multithread in because multithreading anything more than the most basic of processes is inherently complex. This doesn't apply to SIMD structures which is the main reason why GPU's can be so parallel. One pixel doesn't care what color the other one is.

      While C is ultimately the right language to do everything in (not C++) , the real issue is that cpu's are expanding in cores, just like GPU's have, yet GPU's have standardized more or less on just three API's, OpenGL, Direct3D and Vulkan. So if you can write a program against Vulkan, you have as close to bare hardware as you are going to get. But for CPU's, there is still a 57 flavors of rubbish programming languages and no standard runtime that works for all of them, at best most of these programming languages are still developed in C or C++ and thus require a complete C AND C++ runtime to function.

      A lot to disect here. So for starters APIs and languages aren't the same thing and the main graphics APIs can be interfaced with multiple languages, I've seen programs written in everything from Javascript, Python, C, and Java interface with the OpenGL api. Second, there is no such thing as a C/C++ runtime. Runtimes only exist in interpreted languages like JS with its DOM or in ones that compile to byte code for a nonexistent VM like Java. C/C++ compile to binary for a given architecture. That's the fundamental difference between compiled and interpreted languages.

      Python is not written in Python.

      Actually, some runtimes are.

      If a language can not compile itself, it's not flexible enough to be used for any of the three main corner stones of software development: Operating Systems, Applications, and Games.

      I don't know about flexibility, one of the biggest strengths of these dinky languages is their flexibility. Their biggest weakness however is a lack of efficiency and performance. If you had said they are unsuitable due to performance issues or an inability to run direct on the metal then I would agree with you. It's impossible to write an OS kernel that runs on a real machine by itself in javascipt or python. It cant be done because they both require JITs to work.

      While you certainly can write an application or game with a scripting language, it will be slow,

      Not a guarantee, but likely depending on complexity. There have been many successful games written in Java, minecraft for example.

      it will be limited by the operating system's own libraries (eg 32-bit libraries on a 64-bit OS as just one example) and generally require more maintenance than simply writing it in C to begin with.

      Eh, any program referencing external libraries has this problem. See issues with old C++ programs referencing deprecated Win32 APIs trying to run in Windows 10. However it is possible with some careful coding and luck to write a complex application that can work for decades unmodified in C. The same cannot be said for JS. If you write something complex in JS and dont touch it, three years later it wont work. This is especially true if you use some idiotic technology like NPM. Because storing your dependencies in the cloud is a great idea.

      Memory overflow errors are caused by people learning programming languages like Java first instead of C, because if you learn C first, you then learn how to initialize memory, and how big memory chunks actually are.

      While I do appreciate C, I think you give it too much credit. For one any serious Java programmer has to learn memory management eventually because the built in garbage collection is trash and once you get to a certain complexity level its no longer good enough. On top of that C's memory model is not an accurate representation of how a computer's memory model works anyways. I think this is one of C and C++'s biggest weaknesses and contributes to many of the mistakes programmers make in regards to memory management when using them.

    4. Re:Easy by Pseudonym · · Score: 4, Informative

      Second, there is no such thing as a C/C++ runtime.

      Yes, that thing called crt0 that you've seen all your life is an illusion.

      On a modern CPU, the C runtime doesn't have to do much. It has to set up the stack, argc/argv/envp, atexit handlers, and a few more random things. But it very much exists.

      Also consider that C compilers are allowed to generate calls to memcpy if you assign a large struct or something, and many of them do.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    5. Re:Easy by serviscope_minor · · Score: 4, Interesting

      Just use C++

      Indeed, and the library you want in particular is called DLib.

      http://dlib.net/

      Specifically:

      http://blog.dlib.net/2016/06/a...

      the networks are represented as templates. It's pretty cool and very high performance. Particularly impressive given the relative resources invested relative to Tensorflow and PyTorch/Caffe.

      --
      SJW n. One who posts facts.
    6. Re: Easy by reanjr · · Score: 4, Insightful

      Threading in ANSI C is pretty straightforward. There are inherent complexities in multithreaded code, but those can't be ignored by any language. In the context of what C code looks like, I think the threading interface is about as simple as you can get. Do you have any examples of a simpler model?

    7. Re:Easy by Dunbal · · Score: 4, Informative

      There is no easy way to do threading, by its very nature. It's not a language thing, it's a computer thing. If more than one thread is trying to access the same resource at the same time the headaches begin: who goes first, how do you get the threads to accept its place in the queue and "know" when the other is done, etc, etc, etc. Languages that support memory locking of course make things easier but you still have to think the program through very clearly and often you end up with rather unusual and not reproducible bugs.

      However I posit that many people who use higher level languages have no actual idea of how a computer works or what they are actually doing, unlike us old timers who grew up with assembler.

      --
      Seven puppies were harmed during the making of this post.
  2. There are only two options here... by Etcetera · · Score: 4, Funny

    ... for building Skynet, and it'll be Lisp or perl.

    And we all know which one the Lord used: https://xkcd.com/224/

    --
    Hire a Linux system administrator, systems engineer,
  3. Dumping Python Is Both And Easy And Lucrative by L_R_Shaw · · Score: 5, Insightful

    Over the past few months I have spoken to a few recruiters I know who were asking me to give them all the senior C++ engineers I know or if I personally was interested.

    In what?

    Doing complete rewrites of giant mountains of garbage Python code written by twenty something year old hipsters or older researcher type people.

    It is boring as fuck work but companies and organizations are desperate and willing to pay huge amounts of money to rid themselves of the clusterfuck that is Python.

    1. Re:Dumping Python Is Both And Easy And Lucrative by ShanghaiBill · · Score: 5, Insightful

      If I have to choose, I'll deal with giant mountains of garbage Python over even a small hill of garbage C++

      That is backwards.

      Python is great. I use it all the time. For scripts. Small programs that are fast to write, easy to read, and avoid all the complexity of type checking and memory management. Python is also easy to learn. It is taught in elementary schools.

      But for a 200,000+ line project written by a team, with coders coming and going during the project, Python is a very poor choice. "Quick and easy" doesn't scale. For big projects you need rigid type checking, complex data structures, fine tuned encapsulation, compile time error checking, static and dynamic analysis, verifiable memory allocation and release, etc. C++ has all of that, Python does not.

      So you want to use C++ for the "giant mountains" of code. Python is for the "small hills".

    2. Re:Dumping Python Is Both And Easy And Lucrative by tomhath · · Score: 5, Insightful

      Those companies should be thankful they aren't rewriting giant mountains of garbage C++ code written by twenty something year old hipsters or older researcher type people.

  4. Julia anyone? by jgfenix · · Score: 5, Insightful

    I think it fits the requirements quite well.

    1. Re:Julia anyone? by TimothyHollins · · Score: 5, Interesting

      Julia has a tremendous problem. It's not designed for users, it's designed for Julia designers. If they had said "let's create an environment for deep learning that is great for threading" everything would be fine. But instead they went with "Hey, let's do all those awesome and cool things that we always wanted to see in a programming language and also it should be great with deep learning and implicit threading". The result is a (possibly great) environment that takes far too long to learn, has way to many individual quirks and ways of doing things that differ from the standard approach, and just is a bitch to intuitively understand.

      The environment may or may not be great, but the designers made sure that you couldn't just pick it up and go, you have to go "ahaaaa so that's how you do that" for every single thing. And when the option is using Python/R that you already understand or use Julia that you have to learn from scratch, the choice is easy, especially for the people that are scientists and not programmers at heart - which is the exact audience that Julia is targetting.

    2. Re:Julia anyone? by thejam · · Score: 4, Informative

      You can absolutely use Julia productively without getting into all the extra stuff. You can write code similar to Matlab or Numpy. Later, when you want more performance, you can delve into types more. Admittedly, the documentation emphasizes the multiple dispatch sophistication, and maybe Julia has a longer on-ramp than Python. In the past Julia was evolving very quickly, but now that 1.0 has been released, you can stick with that. But there is no other new language that has as strong a community dedicated to readable, powerful high-performance numerics. And the appeal of Julia is not that it does what currently Python or R can, but it's a better place for libraries to written by experts in the language itself. I can't think of a better language for doing research in numerical optimization, when you're really exploring new ideas and not just plugging into someone else's canned, but confining, "solutions". Most Python numerical libraries must, for performance, ultimately rely on C or C++ underneath, so becoming expert at Python does not help you in contributing to new high performance libraries. By contrast, high performance libraries for Julia can be written in Julia itself, so therefore Julia can be a very good long term investment. Please, tell me what high performance Python numerical libraries are written in Python, without C or C++?

    3. Re:Julia anyone? by Anonymous Coward · · Score: 5, Interesting

      You can write code similar to Matlab

      MATLAB is a terrible example of an "easy to learn" language. It's full of shitty hacks like "putting a semicolon after an expression suppresses output; deleting the semicolon causes the expression to dump its output to console." It's loaded with arcane semantics like the differences between a normal array and a cell array. For fuck's sake, it permits semicolons in the middle of a parameter list, like this.

      MATLAB has the quintessential property of an overdesigned language, which is: if I leave it alone for a few months and come back to it, I have to re-learn the whole damn thing. The syntax, the library, and the UI are all unintuitive and illogical. I rely heavily on my cheatfile that I've built up from this iterative exercise to get back up to speed faster. I don't have to do that with Python or C.

      or Numpy

      Numpy is a terrible example of an "easy to learn" API. Numpy arrays use semantics that are logically similar to Python arrays - but of course they're nothing like each other, none of the libraries work the same way, etc. And And some core features are so poorly documented that you have to dig through sample code until you find something that vaguely resembles what you wanna do, and then shoehorn it into the shape you want. And if you want to stare into the abyss of insanity, try looking into using the Numpy array-sharing options to circumvent the cross-thread limitations of the Python global interpreter lock.

      Don't get me wrong: both are powerful and fun when you're acclimated to them. My first Numpy experience was porting a super-simple image processing technique, and my amateur, first-attempt Numpy code finished 10,000 times faster, and that's not an exaggeration. But they're both crappy languages from a model-of-clarity-and-consistency perspective.

    4. Re:Julia anyone? by Pseudonym · · Score: 4, Informative

      Julia has a tremendous problem. It's not designed for users, it's designed for Julia designers.

      I have to disagree with that. Julia is designed for users, but it knows that its use case is not Python's use case.

      Julia was designed as an upgrade for Fortran programmers. Like all good upgrade languages, it learned from all of the languages which tried (and failed) to replace Fortran previously, like SISAL and Fortress.

      There is a cohort of programmers for whom "the standard approach" means Python's highly idiosyncratic approach. In my (admittedly limited) experience, anyone who predates the rise of Python tends to have no problem picking up Julia.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});