Seeing C++

    int allocation[n];
    memset(allocation, -1, sizeof(allocation));
    for(int i = 0; i < n; i ++)

    allocation = [-1] * n
    for i in range(n):

It's also claimed that this system is good at guessing types from untyped languages.

So a good way to use this technology might be to have something that looks at source code and tries to translate all the function signatures and type definitions. This includes looking at function calls and bodies to help guess ("infer" is a stretch for this approach) the types of ambiguous variables.

Example is

    int foo(char* s);

    int getdata(int *buf, size_t bufl);

Then try to translate the executable code with that information available. Bad guesses about types will usually result in translation failures or code that compiles with type errors, so someone will notice.

So this is promising for modernizing code.

I want to see one able to turn C pointer arithmetic into slice syntax. Now that would be a big step forward.

It also either knew about the machine integer representation, or else made a combination of two mistakes that turned out to cancel each other out.

This

    int allocation[n];
    memset(allocation, 42, sizeof(allocation));
    for(int i = 0; i < n; i ++)

    allocation = [42] * n
    for i in range(n):

    Python 3.6.9 (default, Apr 18 2020, 01:56:04) 
    [GCC 8.4.0] on linux
    >>> n = 10
    >>> allocation = [42] * n
    >>> allocation
    [42, 42, 42, 42, 42, 42, 42, 42, 42, 42]

  $ cat test.c
  #include <stdio.h>
  #include <string.h>
  int main() {
      int n = 10;
      int allocation[n];
      memset(allocation, 42, sizeof(allocation));
      for(int i = 0; i < n; i ++)
          printf("%d\n", allocation[i]);
  }
  $ gcc test.c
  $ ./a.out
  707406378
  707406378
  707406378
  707406378
  707406378
  707406378
  707406378
  707406378
  707406378
  707406378

https://federalnewsnetwork.com/tom-temin-commentary/2020/01/...

It should not be surprising that it is written in Assembler, given those factors and the performance advantages over the alternatives.

I was writing new 370 Assembler in the 90s for high throughput electronic pre-press systems.

Publications by universities will almost always include details like dataset sizes, hardware used, and durations for pre-processing, training, and inference.

As-is, this paper leaves me puzzled as to whether this novel solution is even practical in any way shape or form.

If I essentially need the computational resources of a medium-sized data centre to prepare the data, and train the system for adding a new language-pair or fine-tuning an existing one, it'd not be a practical method outside of the Four Horsemen (GAFA) and their closest competitors...

I applaud the use of computational accuracy as the primary metric for evaluating the results, though.

The details section:

> 4.1 Training details We use a transformer with 6 layers, 8 attention heads, and set the dimensionality of the model to 1024. We use a single encoder and a single decoder for all programming languages. During XLM pretraining, we alternate between batches of C++, Java, and Python, composed of 32 sequences of source code of 512 tokens. At training time, we alternate between the denoising auto-encoding and back-translation objectives, and use batches of around 6000 tokens. We optimize TransCoder with the Adam optimizer [25], a learning rate of 10−4, and use the same learning rate scheduler as Vaswani et al. [45]. We implement our models in PyTorch [39] and train them on 32 V100 GPUs. We use float16 operations to speed up training and to reduce the memory usage of our models.

> 4.2 Training data

We download the GitHub public dataset available on Google BigQuery . It contains more than 2.8 million open source GitHub repositories. We filter projects whose license explicitly permits the re-distribution of parts of the project, and select the C++, Java, and Python files within those projects. Ideally, a transcompiler should be able to translate whole projects. In this work, we decide to translate at function level.

What we usually see is that someone else goes through the time to reproduce the results when reproducing it. Or internally from companies you can see projects moving from one company to another like MapReduce (Google) to Yahoo (Hadoop).

And then if enough companies don't want to manage the whole project the software gets donated to the Apache Software foundation.

That's quite literally the opposite of what science is all about! If they don't want others to reproduce their results, they might just as well end each paper with "You can take our word for it!" and skip the details altogether...

What I'm rather interested in are points of comparison. Performance in terms of a chosen metric is one thing, but research gets more useful if it can easily be reproduced. This is the norm in all other sciences - why not in AI research?

If I can see that their approach is 20% better than SOTA, but they require 1M LoC plus 3 weeks of total computation time on a 100 machine cluster with 8 V100 per node, I can safely say - sod it! - use the inferior commercial product instead and add 20% manual effort (since I need to add manual work anyways as the accuracy isn't 100%).

I worked in a lab where I had to reproduce others peoples code in Java. I never finished any of those projects.

For Example GPT-2 would need around ~$50k to reproduce from scratch. GPT-3 is probably a few orders of magnitude than that. How would anyone reproduce it unless they are a company? I've seen NVIDIA reproduce some results.

Also, most of the issues are you don't have the datasets and after the PhD students graduate and the professor gets a job your access of the datasets go away like bitrot.

8 V100's cost about $20/h, 100 machines for 2 weeks (allowing for a long training time) will cost $638K. This is the salary of three to five engineers for a year. If your model reduces more than that amount of time it is worth it. It's just a matter of how much use you can get out of it. Of course a model can be reused by different teams and companies, so it could easily be worth the price.

I expect the number I calculated to be exaggerated for this task, though, you don't need that much compute for this model. GPT-3 cost $1.2M per run and it is the largest model in existence.

In NLP land, En-Fr unsupervised translation yield significantly better result than say for En-Zh translation.

E.g. in its current state it would not be able to translate large codebases, even more so using different libraries.

For example, the translator consistently fails to convert Python

  max(arr)

  Math.max(arr)

Another problem is that unless you can port tests too, the code is not very reliable.

(via https://news.ycombinator.com/item?id=23470668, but no comments there)

I like the idea of shared VMs like Truffle and LLVM, but they really don't fix the problem of allowing developers with disparate backgrounds and preferences collaborate.

For dynamic it would require introspection...

Hmm... The authors literally ran a series of experiments and published them without giving a clear way to reproduce the results. How is that useful to anyone except to self advertise?

My comment about prediction vs understanding was simply meant to underscore this, albeit it might rub some people the wrong way. If you publish a paper purely about prediction (ie a set of experiments) be prepared to release all pertinent information to reproduce said experiments. If you choose to publish a paper that aims to improve mankind's understanding of the problem at hand, you are intrinsically required to provide all proof in your exposition.

Otherwise we might as well just believe everything anyone ever says with no proof.

It beats existing commercial products that try to do the same, so to me it seems it has some value right now.

While I agree with your conclusion, a minor correction is in order here: it beats a (as in a single selected) commercial product and a single free OSS transpiler.

The improvement for the commercial product is 61% vs. 75% accuracy (i.e. 23% better) which - while impressive given the unsupervised learning aspect - isn't a game changer (yet!).