readittwice

Thanks, that explains it! Didn't know that final fields have this special rule and that the value field in the String class is final.

So to recap: this shouldn't be possible for Strings, since the value field in the String class is final and therefore has a memory barrier. But it could happen for other classes with non-final fields.

Why is the JIT not allowed to do this? (Assuming publishing isn't volatile) The reordering could also be caused by the CPU, not only by the JIT. If the JIT isn't allowed to reorder, we also need to prevent the CPU from reordering. Otherwise it doesn't make sense to restrict the JIT from reordering if the CPU could still reorder later. We would need to emit memory barriers for non-volatile loads & stores to prevent reordering on architectures like ARM. This sounds quite expensive.

This doesn't make sense to me. Am I thinking wrong? Can you point me to documentation/reference that states that the JIT isn't allowed to do this?

AFAIU the JIT-compiler (or the CPU) could reorder the code:

    String x = allocate String; // allocate memory only (no initialization)
    initialize string x // constructor
    publish x // e.g. store in some global

reordered to

    String x = allocate String;
    publish x // after publishing some other thread could read unintialized object
    initialize string x

I've worked in Switzerland as a consultant and there were Germans all around. A friend of mine makes more money waitressing in Switzerland than I make as a SW engineer in Austria. So I am kind of guilty too ;)

Actually there are quite a lot of young people from Spain & e.g. Romanians that leave their countries. Emigration in Romania is quite a big problem (from 23 million to 20 million people). I guess it depends on your definition of "moving in masses".

First: I like the name!

That said, it is a bit unfortunate to fork or at least to try to fork a project like Node.js over these reasons. Although it is quite likely that the fork was mainly created to pressure the Node-devs to remove rvagg from the project after all.

What puzzles me: Even if we agree that rvagg violated the Code of Conduct, I am not sure that this should be enough to remove him from the TSC (Technical Steering Committee). Here are the alleged violations, so that you can decide for yourself: https://twitter.com/ohhoe/status/899748838302302212.

From what I've seen Java/JVM AOT won't produce binary executables but shared libraries that will be loaded on startup by the JVM. When I first read about Java AOT-compilation I expected it to produce real executables that's why I think this is important to mention. But please correct me if I am wrong. So if this is true even with AOT compilation you still need the JVM as dependency (although I think you can get a minimal JVM in under 10MB). It also seems that the AOT compiled code needs to be recompiled on Java updates. Although I quite like Java and the JVM, I still wouldn't choose Java for writing simple command line tools.

Nevertheless it is quite useful for improving startup for tools like Gradle or server applications. But sure, I also don't expect Java startup performance to be a problem in the mid- to long-run.

Although this might really be true, I am skeptical that this has something to do with the inherent design of the Java bytecode compared to the CIL.

If there is a problem with java bytecode, then that is hard to verify. You need multiple passes over the bytecode, until you've reached a steady state. There is also the "issue" that Java bytecode allows arbitrary control flows with goto, while Java doesn't.

IMHO WebAssembly solves that better but I also need to admit that they could already learn from Java.

You are absolutely right.

What makes me a bit skeptical here is that Coraline just writes 'this teammate seemed to be benefiting from it'. But doesn't mention that the junior dev appreciated it or thanked her for her help. Didn't the junior complain about the missing mentoring after the intervention of the manager?

But who knows, probably I am reading way too much into these few sentences...

> Being in a mentor role does not mean you have to right to mentor.

Exactly. For what we know, the junior could have actively complained to the manager (wrongly or rightly) about her mentoring. OTOH the junior dev might have appreciated it. We can't say for sure.

Some people (myself included) prefer to get a general direction and then later to come back for further questions. Too much information in a short amount of time can be overwhelming, I need some time to absorb and read it up in the internet. A few keywords might be good enough to get someone going and figure it out themselves.

"learn at her own pace, without any pressure from you." This really sounds as if the manager had the junior dev's best interest in mind. I don't see how the manager said this to get back at Caroline, as was kind of implied in the article.

The same is true in C/C++: Function argument evaluation order is unspecified. BUT: that doesn't mean this is undefined behavior, it is just unspecified.

unspecified != undefined behavior

See this Stack overflow answer for an explanation: https://stackoverflow.com/questions/2397984/undefined-unspec...

Since, I don't know D, I am curious whether D-code is written in such a way that objects are assumed to be non-moving, especially when interfacing with C.

Out of interest: Could you please post the code?

Same for me, although I studied computer science. I enjoy to read such nice written articles about technology. Even though most of the text was about stuff I already knew, there still was something new (maybe I just forgot?) for me: retransmission via ACK messages. But even if not, I still appreciate reading about this stuff again to freshen my knowledge. If I don't work on/with these topics regularly, I tend to forget about some of the details.

AFAIK you cannot access the DOM from WebAssembly right now, although it probably will come in future versions.

But you can use the WebAssemblyExplorer https://mbebenita.github.io/WasmExplorer/: There is also a nice video about using WebAssemblyExplorer and even uses a simple WebAssembly-Module: https://www.youtube.com/watch?v=3XrGjSnPHGY&t=310s

There is another point to consider: Getting 20% less money, doesn't necessarily also mean 20% less money after taxes. When I was working part-time (20h per week) while studying, working full-time during summer meant this: ~90% more work (from 20h to 38.5h) but only ~60% higher salary (after taxes). So I just continued to work part-time in holidays and enjoyed summer. In my country higher salary means higher taxes, working less hours therefore means paying less taxes because of a lower salary. Taxes don't consider the number of hours you work. Although you need to consider that you also pay less e.g. into your pensions fund, some of your additional salary is "just" taxed away. When working 20h the difference for me was substantial, right now not so much. But that may be different for you.

Thanks, much better explanation than I could give ;)

> Prussia had recently adopted a new model of rifle: one that was bolt action and so allowed for rapid fire, in comparison to the Austrians’ outmoded muzzle-loading Lorenz rifle-muskets.

This really made a long-lasting impression, in Austria today (so 150 years later) we still use the phrase: "the prussians don't shoot that fast". We use it when there is still time and a solution isn't ready yet.

Why should Americans bother to have a passport? Their country is so huge, probably more than you could visit in a lifetime. Deserts, mountains, cities, ... In Europe countries and the continent are smaller, Vienna for example literally has 3 other countries in commuting distance. It is quite obvious that you are more likely to need a passport here in Europe. A much fairer comparison would be to only count Europeans that use their passport to travel to other continents.

JIT-Support is listed as a possible future feature for WASM: http://webassembly.org/docs/future-features/. Why shouldn't a WASM program not be able to generate WASM bytecode at runtime? The runtime-generated bytecode can be verified and then compiled by the WASM compiler, just like it is done for AOT-generated WASM bytecode. That said, I am not sure if WASM should support jitting. But if there is demand for it, then it will probably get done.

What I would really like to see is GC support in WASM. That would make it possible to AOT-compile managed languages like C#/Java to WASM. You wouldn't need to port the whole VM, "just" translate e.g. *.class-files to WASM which would seem a lot more feasible for the moment. That would sure only allow a subset of C#/Java, but since the web environment is distinct enough and the subset is large enough that would IMHO be acceptable.

How would you implement determining the root set? So how would you detect which local variables reference an object? The Gc needs to keep these objects alive.

AFAIK even conservative root-scanning is not possible right now. Please correct me if I am wrong: With the current bytecodes it is only possible to access the heap but not the stack. To make things worse, object references could also be in registers.

I am not sure what you mean? Both Python (PyPy) and Dart have a JIT (yes, you can also compile Dart to JS), so they don't lose type information in those VMs. See what the PyPy-Devs have to say about type annotations and performance (they have a faq entry for that!): http://doc.pypy.org/en/latest/faq.html#would-type-annotation... And here is what the Dart devs have to say: https://www.dartlang.org/faq#q-but-dont-you-need-sound-typin...

Your claim was "it probably wouldn't take that much effort to surpass JS performance with a custom TypeScript -> WASM compiler"

I guess you basically have two options:

1) Implement a JS-Engine on top of WASM. Which is a lot of work. But what could you do to get better performance than current JS-Engines? Every optimization you can implement on top of WASM, you can also implement for native JS-Engines. Quite the contrary it is even harder, since you are an abstraction layer higher and can only make use of WASM opcodes.

2) Define a fully-statically typed subset of Dart and compile to WASM. You could sure do that, but don't forget about e.g. the ubiquitous number type in JS/TS. You may have to use double (almost) everywhere if you want to match semantics of JS. How many non-trivial TypeScript programs could such a subset run successfully? I assume not a lot.

I don't see how you could write a TypeScript to WASM compiler without much effort. Care to explain?

Sure, but AFAIK TypeScript is not generally fully statically typed. You could just rename a .js file to .ts and call that TypeScript. Please correct me if I am wrong.

There are some dynamically typed languages like Python or Dart that allow (or are in the process to allow) type annotations. But all these languages I know about claim that type annotations do not help performance. I guess you could define a fully statically typed subset of TypeScript that allows you to compile it to fast WebAssembly bytecode. But that would probably also mean to change some semantics: see int vs double for numbers in JavaScript.

To be fair it probably also helped that Lua is a simpler language and therefore easier to optimize. A tracing JIT also has an inherent downside: the infamous example of an if in an inner loop with roughly the same probability for the then and else branch.

That said LuaJIT is an impressive piece of software. Would love to know what Mike Pall is up to now.

Sure, Anders is great but this not so easy. Basically you would have to re-implement all the features and optimizations of current JS-Engines. In WASM you are restricted to the given (statically-typed) opcodes, while a JS-JIT has more knowledge about program semantics and can thus apply optimizations more easily. In addition the JIT can also make use of hand-written assembly if it is needed for best performance.

I think JRuby does a similar thing for Ruby and Java Bytecode. TruffleRuby shows that it is possible to be faster, they do not compile to bytecode and use their own compiler.

But they still got a lot of media attention from that. It was reported in non-tech news and non-tech people were talking about it, at least here in Austria, Europe. Even if they do not buy that 3310, but these people heard at least once that Nokia is back.

It is obviously not an innovation, but IMHO it was a good PR move from Nokia.

Same for Austria. Immigrants are both over-represented both in prisons and criminal statistics.

Sure you need to be critical - but in both directions.

If you want to see the government trying to hide things, just look at Sylvester in Cologne and how long it took officials and the german TV channels to report/acknowledge what happened. If this information hadn't spread on Facebook, who knows if we would have ever known.

I am Austrian and until the migration crisis I've never felt misinformed. (BTW: Austria took more refugees per capita in than Germany) But this crisis changed that. It seemed the public media didn't just report, they wanted to persuade people to the right course. This is also about subtle things and therefore hard to prove: According to statistic refugees were about 70% male, but who was almost exclusively on the frontpage? Only women and children.

I can handle dubious or stupid Twitter/Facebook comments and chit-cat about what refugees supposedly did. The shocking thing was that public media was so one-sided. It is no coincidence that the name "lying press" got popular at this time. IMHO this was a general feeling that people had. That they didn't get the full story.

I thought the same thing (especially about structs), but after some time with Rust I actually like the explicitness about lifetime rules.

As soon as you are not fighting with lifetimes anymore, it's just a bit more to type. IMHO it actually makes code easier to read, since I don't have to remember a lot of weird rules.

But I have to admit that Rust already has some rules for lifetime elision (e.g. `fn getx(&self) -> &T { &self.x }`. I can only speak for myself but IMHO these rules have a pretty good cost/benefit ratio. For me introducing more rules adds just more cost for diminishing value.

True, but if you are willing to use some libraries or tools you can get pretty far. And if not, use them too :) you could always replace them later with your own tools.

IMHO you need to decide on what part of the compiler you want to focus on. You mentioned you already know how to write a lexer and parser. So maybe you should start with an IR like WebAssembly you could compile. Maybe you could even reuse your lexer/parser from your interpreter.

Compiling can be as simple as writing an interpreter, you "just" have to replace some code in the interpreter with `printf`s, that dump e.g. LLVM IR or Assembly. Then use LLVM or any assembler to get a binary. Even GCC basically works that way, gcc just dumps an assembly file and then passes it to assembler and linker. So GCC doesn't really emit ELF or Mach-O either, so don't let that stop you. That doesn't mean you don't have a "full" compiler.

If you don't know assembly use tools like gcc.godbolt.org to see what code gcc generates. The most important thing: Think what code to generate for each feature of your language or IR. If you have figured that out all the rest will be trivial. For example: What code to generate for `if`? So don't try to compile a language with many fancy features at first and please don't try to generate fast code. You want a translation that works in every case, although it might be somewhat inefficient compared to `gcc -O3`. Your first program to compile could be something like `int main() {}`. If you can compile and execute this program, you can start to add features.

This are the restrictions I would make at the beginning: * use a statically typed language, it is easier to generate (faster) code for that * start with global variables, add local variables later * support if, while and then functions (in this order) * only support few datatypes: int, int-array/pointer and string literals for printing.

This should be enough to run the benchmarks binarytrees and fannkuch from The Computer Language Benchmark Game. You will already beat many dynamically typed and interpreted languages for those.

Don't try to generate fast code at first, spill everything onto the stack so you don't have to care about register allocation. Even the V8 full-codegen jit works this way, so you don't have to be ashamed of it ;)

If you don't care about ELF, linking and stuff you could also avoid this by writing a JIT-Compiler: Just emit code into some buffer and then directly start to execute. Although I have to admit that a JIT can introduce some challenges of its own.

Ah and don't forget to write tests. Write a lot of tests from the beginning. Testing a compiler is pretty simple and is is also easy pretty easy to introduce subtle bugs. You will save a lot of time.