On Friday, 21 September 2018 at 01:04:51 UTC, Joakim wrote:
> On Friday, 21 September 2018 at 00:47:27 UTC, Adam D. Ruppe wrote:
>> Of course, D can also take ages to compile one line of code. It all depends on that that line is doing... ctfe and templates are slow. C or Java style code compiling in D is very fast.
>
> I was going to say this too, ie how much of that Jai code is run at compile-time, how much is uninstantiated templates that is just skipped over like D does, and how much is templates instantiated many times? Lines of code is not a good enough measure with those programming constructs.
>
> I was just building the stdlib tests with LDC yesterday and they took so much memory on a new Linux/x64 VPS with 2GB of RAM that I had spun up that I couldn't even ssh in anymore. I eventually had to restart the VPS and add a swapfile, which I usually have but simply hadn't bothered with yet for this new Ubuntu 18.04 VPS. The stdlib tests instantiate a ton of templates.

Sure, all true, but from what I've seen of Jai, it's not a simple language, and it does a decent amount of compile time stuff, but who knows, maybe the code is simple indeed. I remember a demo where he ran a game at compile time and was also fast AFAIR. I think that his goal is to keep it fast regardless of which features are used though. I hope.

Regardless, you can't really claim X compiles fast if that's only true on a subset of the language features. Cause otherwise the statement "X compiles fast" is, well, just not true ;)

On Friday, 21 September 2018 at 05:39:35 UTC, Vladimir Panteleev wrote:
> On Friday, 21 September 2018 at 05:11:32 UTC, mate wrote:
>> Note that the build can be done at compile time because the metaprogramming capabilities of the language are not limited in terms of system calls.
>
> Good luck bisecting that code base when any version of it did anything even mildly specific to the author's PC.

Where your build system lives makes zero difference to bisecting. You can have author-PC specific behavior in the build recipe whether that's in a source file or a "build script".

I guess it would be more compartmentalized though. But being able to say "the code here needs this feature" (which is not something you can do when the code doesn't know how to compile itself) could seems pretty useful.

On Friday, 21 September 2018 at 09:21:34 UTC, Petar Kirov [ZombineDev] wrote:
> On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote:
>> Alo!
>>
>
> I have been watching Jonathan Blow's Jai for a while myself. There are many interesting ideas there, and many of them are what made me like D so much in the first place. It's very important to note that the speed claims he has been making are all a matter of developer discipline. You can have an infinite loop executed at compile-time in both D and Jai. There's nothing magical Jai can do about that - the infinite loop is not going to finish faster ;) You can optimize the speed of compile-time computation just like you can optimize for run-time speed.

Haha well, yes of course, can't argue with that :p I guess it makes more sense to compare the "intuitive" coding path of a given language. Eg: if I iterate a million objects in a for loop, because i want to process them, there is no other non-compile time way to do that. If language X takes an hour and language Y takes a millisecond, I'm pretty sure language X can't say it compiles fast, as that just seems like a pretty common-scenario and is not using the language in any way it was not meant to be used.

>
> What your observing with D is that right now many libraries including Phobos have tried to see how much they can push the language (to make for more expressive code or faster run-time) and not as much time has been spent on optimizing compile-time. If you take a code-base written in Java-like subset of the language, I can grantee you that DMD is going to very competitive to other languages like C++, Go, Java or C#. And that's considering that there are many places that could be optimized internally in DMD. But overall most of the time spent compiling D programs is: a) crazy template / CTFE meta-programming and b) inefficient build process (no parallel compilation for non-separate compilation, no wide-spread use of incremental compilation, etc.). AFAIR, there were several projects for a caching D compiler and that can go a long way to improve things.

Ah I see. Ok so there's quite a bit of big wins it seems (parallelization e.g.).

>
> On the other hand, there are things that are much better done at compile-time, rather than run-time like traditional meta-programming. My biggest gripe with D is that currently you only have tools for declaration-level meta-programming (version, static if, static foreach, mixin template), but nothing else than plain strings for statement-level meta-programming. CTFE is great, but why re-implement the compiler in CTFE code, while the actual compiler is sitting right there compiling your whole program ;)

Yeah I've always wondered this. But I just boiled it down to me not understanding how compilers work :)

>
> P.S.
>
> Jai:
> loadExecutableIcon(myIcon, exeLocation)
>
> D:
> static immutable ubyte[] icon = import("image.png).decodePng;

Si si, but i believe the loadExecutableIcon actually calls windows APIs to set an icon on an executable, and they'd probably @system which means I don't think that could be done in D.

>
> (In D you have read-only access to the file-system at compile-time using the -J flag.)
>
> [0]: https://github.com/atilaneves/reggae

On Friday, 21 September 2018 at 09:21:34 UTC, Petar Kirov [ZombineDev] wrote:
> I have been watching Jonathan Blow's Jai for a while myself. There are many interesting ideas there, and many of them are what made me like D so much in the first place. It's very important to note that the speed claims he has been making are all a matter of developer discipline. You can have an infinite loop executed at compile-time in both D and Jai.

You're going to OOM pretty fast in D if you try :)

On 9/21/18 10:19 AM, Nicholas Wilson wrote:
> On Friday, 21 September 2018 at 09:21:34 UTC, Petar Kirov [ZombineDev] wrote:
>> I have been watching Jonathan Blow's Jai for a while myself. There are many interesting ideas there, and many of them are what made me like D so much in the first place. It's very important to note that the speed claims he has been making are all a matter of developer discipline. You can have an infinite loop executed at compile-time in both D and Jai.
> 
> You're going to OOM pretty fast in D if you try :)

I can see the marketing now, "D finds infinite loops in compile-time code way faster than Jai!".

-Steve

On Friday, 21 September 2018 at 13:28:47 UTC, aliak wrote:
> Sure, all true, but from what I've seen of Jai, it's not a simple language, and it does a decent amount of compile time stuff, but who knows, maybe the code is simple indeed. I remember a demo where he ran a game at compile time and was also fast AFAIR. I think that his goal is to keep it fast regardless of which features are used though. I hope.

We don't have access to the source code being tested. We don't have access to the compiler. Until the language is actually made public, we can't make any substantive conclusions about its speed.

On Fri, Sep 21, 2018 at 10:53:39AM +0000, Vladimir Panteleev via Digitalmars-d wrote:
> On Friday, 21 September 2018 at 07:58:16 UTC, mate wrote:
> > Different sensibilities on where to put restrictions clearly lead to different designs. I am not sure myself what is best.
> 
> The more people you have on your team, the more you appreciate the restrictions. If you are working on a personal project alone, you are in control and have full knowledge of the entire codebase, so restrictions are a hindrance. When you are collaborating with someone you know only by name from across the globe, being able to reason what their code might or may not do is considerably helpful.

+100.  Many things I could get away with in my own personal projects, I wouldn't do in a team project (which is basically *any* non-trivial project these days).  Unrestricted freedom to do whatever you want greatly reduces the ability to reason about the code, which is why these days structured programming constructs like if/else, while-loops, functions, etc., are preferred over unrestricted goto's, even though they are technically "more restrictive".

The challenge is in finding the balance between restriction and not hampering the programmer's ability to express what he wants without jumping through hoops (Java's verbosity comes to mind... although, to be fair, given your typical "enterprise" development environment, this is not necessarily a bad thing, since it forces even bad code to conform to a certain predictable structure, which makes it easier to rewrite said bad code :-P when one of your coworkers turns out to be a cowboy programmer).  Not an easy balance to strike, which is why designing a successful programming language is so hard.


T

-- 
Unix is my IDE. -- Justin Whear

On Fri, Sep 21, 2018 at 07:58:56AM +0000, mate via Digitalmars-d wrote: [...]
> I realize that with build instructions written in unrestricted language it is easier to create a dependency on something else than the compiler, such as the OS. Maybe they plan to solve this problem with appropriate facilities and discipline.
[...]

Relying on discipline, or rather, assuming discipline on the part of your coworker, never works, as shown by the past 20 years of failures in software.  All it takes is for *one* person in a team of arbitrary size to do something stupid, and the entire tower of cards comes crashing down.  You need actual, hard restrictions guaranteed by the compiler, not mere "programming by convention".


T

-- 
It's bad luck to be superstitious. -- YHL

On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote:
> 
> And is there anyway to get even near the performance of Jai when it comes to compilations

I watched the same video today. What a coincidence.

In Jai example 80 000 lines of "code" include comments and empty lines. Since we know that that Jai example was written in parallel to language we can safely assume that most of that code is simple therefore its not surprising that Jai compiled that fast. Write C style code and DMD will perform similarly.

Can we improve D compiler speed? Ofcourse but core developers are more focused on stability and very needed functionality than speed. Thats good because I rather have c++ interop than 10% faster compilation speed.

Jai compiler perform parsing and lexing in different thread so its kinda multi threaded. Its possible to do the same with D front end. We can start here but there are plenty of low hanging fruits in compiler you just need to run profiler to find them

On Friday, 21 September 2018 at 13:37:58 UTC, aliak wrote:
> Si si, but i believe the loadExecutableIcon actually calls windows APIs to set an icon on an executable, and they'd probably @system which means I don't think that could be done in D.

You don't need an API call to do that. You just provide the icon in a resource to the linker or a separate resource thing. Some C++ environments do it via pragmas, or you can do it traditionally in a makefile/build command line pretty easily; no need to run fancy code.