Re: Nim vs D
This post is really good which is describe in above but I have another issue when I tried to install the latest version of Windows 10 it shows an error [https://errorcode0x.com/resolve-epson-scanner-communication-error/](https://errorcode0x.com/resolve-epson-scanner-communication-error/), so I want a proper solution how to remove this error as soon as possible.
Re: Nim vs D
> On the other hand there were Java and Python frontends on the GCC, and where > are they now? I think only Ada and Fortran frontends are really good GCC > citizens along side with C/C++/ObjC. The main Modula-2 developer said at a 2016 GCC development conference that the developers' penchant for changing major subsystems makes things pretty hard on front end developers. The silver lining (his phrase) is "a cleaner front end." For Modula-2, where there really isn't much competition, where the language has stopped developing, and where the main developer is a guy who has spent his life implementing Modula-2 compilers, that probably isn't a problem. (Yet even now, after 20 years, it's still not part of GCC proper!) For Java, the open-source competition, the constant extension to the language, and the fact that other opportunities are available for the people who work on that sort of thing, probably spelled the end of the GCC effort. The GCJ developers said this explicitly, and I imagine that this is true of Python, especially with the Python2 -> Python3 revamp a decade ago.
Re: Nim vs D
Yeah, honestly I don't see this helping D's popularity all that much. It certainly doesn't hurt, but let's not panic or make it our goal to do the same. The most impactful way to increase Nim's popularity is to _write about it_ and _talk about it_ at conferences and with colleagues and friends.
Re: Nim vs D
Yes, but the DMD's fronend version in GCC 9.1 is like 8 versions behind the current one, this is kinda bad. On the other hand there were Java and Python frontends on the GCC, and where are they now? I think only Ada and Fortran frontends are really good GCC citizens along side with C/C++/ObjC.
Re: Nim vs D
> I wonder if that will affect D's popularity... What does "mainlined" mean? Ada and Modula-2 have had GCC frontends for decades now, but they're still basically invisible. One reason may be that they typically require you to download and/or build a separate compiler. In Modula-2 you have to download an earlier GCC, then compile it through a process that does not seem to work half the time. (I felt a huge sense of accomplishment when I made it work on one machine, then moved to another machine and couldn't replicate it.) For Ada you basically have to download gnat, which may or may not install an earlier version of GCC.
Re: Nim vs D
Back on topic, [the big news in Dland](https://www.phoronix.com/scan.php?page=news_item&px=GCC-9.1-Compiler-Released) is: "The D programming language front-end has finally been mainlined in GCC! There is now D support beginning with GCC 9." I wonder if that will affect D's popularity...
Re: Nim vs D
> It's may be a strange question, but what do you think about PureBasic ? I don't think about PureBasic, because it's proprietary. I don't hate proprietary software - I'm sure plenty of people find it useful - but I have no use for it personally. It seems like PureBasic had a _raison d 'être_ around the turn of the millennium, when BASIC / VB was popular in universities and business, and that carries some momentum to the present day. It added Mac & Linux/GTK support, and went a different path than MS VB did with .NET, which probably made it a better BASIC for many business needs. But in the current year there are better alternatives on every level. It can't run on other OSes (ex. FreeBSD) without emulation. Its GUI builder is no longer a competitive advantage given free [Glade](https://en.wikipedia.org/wiki/Glade_Interface_Designer) / [Qt Creator](https://en.wikipedia.org/wiki/Qt_Creator), which have bindings for many high-level languages. (Not to mention that Java and Mono are now portable and "free".) And the BASIC syntax is (IMHO?) much uglier than languages like Crystal, Swift, D, and especially Nim.
Re: Nim vs D
perhaps what you want is [quote](https://nim-lang.github.io/Nim/macros.html#quote%2Ctyped%2Cstring) proc?
Re: Nim vs D
yeah, that's a current limitation. You should either use `ref` or `FutureVar[T]`.
Re: Nim vs D
Thanks for implementing it! The only problem I ever had was how you can't bind var parameters, since it assumes you might be resuming the future in a different thread. object = await object.method(...) works for most of the time I'd want to pass a var object though.
Re: Nim vs D
I mean a string composed of tokens. You can't do say parseExpr{a * x + b} which
in D just syntax highlights everything normal even inside the {}. parseExpr"a *
x + b" requires the editor to treat everything between "a * x + b" as untyped,
untokenized string characters.
It's really a very minor quibble though. Nim has statement macros, which work
in much the same way.
Re: Nim vs D
If by token string you mean string mixins you can parseExpr"a * x + b" and parseStmt"var a: int" if you want to do string-based macros.
Re: Nim vs D
> The languages are pretty close in all the other aspects though, and I run > into async/await situations a lot. So, that's why I've been using Nim lately. Yay! Awesome to hear something I've implemented is pushing people towards Nim. Happy to help with any problems you run into btw, feel free to ping me on IRC :)
Re: Nim vs D
* _D_ \- concurrency uses kernel threads or longjmp, with little language support for async semantics * _Nim_ \- has await. Rewrites procedures to be async friendly. Futures that don't rely on kernel threads. That's basically the biggest factor in my mind for using Nim. Everything I can do in D, I can pretty much do in C, but async futures are not something I can do in C. The strategy in D is to make asynchronicity based on kernel threads, which while fine in theory, doesn't really perform well in IO bound applications, and actually comes with some serious problems since you can't make provable assertions about which thread will run when. Deadlocks, undetectable memory leaks, and all because nobody ever bothered to use D's powerful macro language to implement async/await. They have longjmp based fibers, but they're pretty rudimentary, with no futures, or CPS rewriting or anything. Though longjmp based fibers take a lot of memory, they are relatively fast and deterministic, so await style procedure rewriting isn't strictly necessary. And if you can prove it doesn't _matter_ when each thread is executing, you can make strong assertions about your algorithm, so threaded concurrency _can_ work in theory. So it might be nitpicking to criticize D there. The languages are pretty close in all the other aspects though, and I run into async/await situations a _lot_. So, that 's why I've been using Nim lately. Honestly I _love_ D's syntax to bits. I can't expect a human to be able to understand a language that a code editor cannot logically comprehend enough to auto-indent, so whitespace indented languages like Nim make me a little leery. Also D has those token strings, which aren't precisely hygenic macros, but are pretty easy for a code highlighter to parse. Oh, and Nim's grammar is poorly defined. You'll see terms in the grammar like "typeDescK" which you have to sort of psychically guess the meaning of, since the grammar just never defines it. So D wins in terms of syntax, but... I need my async/await. D's old so it's got a lot of cruft, for what that's worth. (They had to deal with the (ugh) wide character fad.)
Re: Nim vs D
Wow: rather curious analysis here. It's may be a strange question, but what do _you_ think about **PureBasic** ? Recently I found myself comparing with **Nim** : both converts their code to different languages before native code, both have portable runtime, both promote heavy macroengine usage.
Re: Nim vs D
> why "Projects like Nim and D can never be failures"? I've explained that point. At very least they brought value to the thousands of programmers that used them, but that's just one aspect of their achievement. D (since 2001) and Nim popularized the idea that a language can come close to the execution speed of C/C++ while giving programmers a ton of benefits like better developer productivity, a much better syntax (ex. [UFCS](https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax)), metaprogramming, modern library / module management, faster compile times, etc. Some of those ideas have made it back into C++ enhancement proposals, as well as newer languages (ex. Swift). This is how progress often happens in the world of free software: experimental innovations often start in less popular projects and spread to more popular ones if successful. OpenBSD and FreeBSD pioneered many security innovations that only later made it to Linux. NetBSD was used to bootstrap the GCC toolchain to obscure platforms before Linux support caught up. Etc. > what is the common between them? * Both compile to lean native binaries (unlike the majority of languages, which are either interpreted or executed on top of a VM). * They come [close to the speed of C](https://github.com/kostya/benchmarks) even with GC. And they can [replace C](https://dlang.org/spec/betterc.html) with manual memory management. * When I look through examples on Rosetta Code, I usually find that D and Nim are the only statically typed languages that don't make my eyes bleed. 🤮 * They are also 100% free and [legally unencumbered](http://copyfree.org) (ex. unlike Java, Ada, Delphi). They're also grass-roots projects; not advertising campaigns for Google (Go, Dart), Microsoft (.NET, TypeScript), Apple (Swift), etc. * Both Nim and D have multiple compiler backends. With Nim you can choose any C compiler backend, plus there's [NLVM](https://github.com/arnetheduck/nlvm). With D there's dmd, ldc (LLVM), and gdc (GCC). * * * > what do you think about redlang [Red/System](https://static.red-lang.org/red-system-specs.html) is interesting. I do like [the syntax](http://rosettacode.org/wiki/Category:Red). Cdecl FFI seems pretty easy. But in many ways it's not in the same league as Nim and D: * **Libraries:** Red doesn't have an organized [module ecosystem](http://www.modulecounts.com). I couldn't find things as simple as PostgreSQL support. GitHub has total_count of [280](https://api.github.com/search/repositories?q=language:red) Red projects, compared to [3,115](https://api.github.com/search/repositories?q=language:nim) for Nim / [10,325](https://api.github.com/search/repositories?q=language:d) for D. * **Performance:** I can't find Red/System included in any benchmarks with Nim or D, which is quite telling. It also doesn't seem to have a [competitive Web framework](https://www.techempower.com/benchmarks/). * **Portability:** Nim one of the most portable languages imaginable (though I can't vouch for the stdlib), easily including every living Unix (ex. [F](https://www.freshports.org/lang/nim)/[O](http://openports.se/lang/nim)/[N](http://pkgsrc.se/lang/nim)/[DF](https://github.com/DragonFlyBSD/DPorts/tree/master/lang/nim) BSD, [Darwin](https://pkgsrc.joyent.com/packages/Darwin/trunk/x86_64/All/nim-0.19.0.tgz), Solaris, AIX), [HaikuOS](https://github.com/haikuports/haikuports/tree/master/dev-lang/nim), etc. This means you can write a tool in Nim, and people will be able to `nimble install` it anywhere, including new / experimental / future OSes / microprocessors. D is behind in ports, but its [inclusion in GCC](https://pkgs.org/download/gdc) means very broad architecture support. Red only supports [12](https://github.com/red/red/blob/master/usage.txt) OS/CPU architecture combinations. It requires i386 binaries even on 64-bit Linux, and isn't included in ports for any more exotic OS. * **Static Binaries:** Red/System is indeed a very lean execution environment, but it doesn't seem to support static binaries (as far as I can immediately tell). A "Hello World" binary is lean, but depends on 2+ MB of i386 .so's.
Re: Nim vs D
The overall part which may be going to get the part perfectly to handle it in such part to enable it to [https://uaetechnician.ae/logitech-h111-mic-not-working-resolve-this-problem-quickly-just-in-few-easy-steps](https://uaetechnician.ae/logitech-h111-mic-not-working-resolve-this-problem-quickly-just-in-few-easy-steps) that require to manage it so which will be going to provide it.
Re: Nim vs D
why "Projects like Nim and D can never be failures"? what is the common between them? open source? what do you think about redlang [https://www.red-lang.org](https://www.red-lang.org)/ which is said to promote new idea of rebol language, however I think red lang is doomed to fail since it focuses on e-wallet last year.
Re: Nim vs D
Projects like Nim and D can never be failures. They've introduced or spread many new ideas. Many of those ideas have already crosspolinated to other languages. If some ideas don't spread, they were still a worthwhile experiment.
Re: Nim vs D
> Sorry, but same could be said about other languages that have better tooling > and community support. With the important difference that those other > languages will not blow up in your face due to the maintainers fiddling > around with new features. As regards maintenance, with D I used to lose a lot > of time fixing my code from one compiler version to the next (what a waste of > time) or trying to figure out what would be the best way to work around D's > messy string handling and how it would affect both the performance and the > flow / logic of the program. This has to be an epidemic now.
Re: Nim vs D
Because open source is not really sustainable. People act too entitled. Everyone is basically looking for a big banquet of all you can eat buffet but someone else has to foot the bill. Of course Nim,D,Crystal cant do that. They do not have the mega corporation paying top dollar for all the engineers. There's no momentum. But really even Google cant push Dart as far as they would and Rust is not such a success like people want you to believe. Yes there's more Rust positions out there than D positions but probably less than Go positions. Why is that ? Because Rust is hard and the costs of investing in Rust are steep. I would say the language has failed when there are no developers anymore interested in writing in that language and when there are no users using any services or products that used that language. In a sense there's very few languages that had failed. There were times when people doubted almost any language less popular than Java (or now JavaScript) as failed languages. Heck people even considered C# and PHP failed languages. I think people are just frustrated they dont get to use their favorite language at work. That's all.
Re: Nim vs D
People in the D community is actively discussing if D has failed: [https://forum.dlang.org/thread/ylwktmssgntvoddub...@forum.dlang.org](https://forum.dlang.org/thread/ylwktmssgntvoddub...@forum.dlang.org) It is kinda interesting and frustrating to see how big and old living project being pushed by very talanted programmers (like Bright and Alexandrescu for example) is still considered to be failing by many people in the community.
Re: Nim vs D
This post is really good but I have another issue when I tried to install windows 10 latest version then my system shows an error [https://errorcode0x.com/solved-dell-error-code-2000-0333/](https://errorcode0x.com/solved-dell-error-code-2000-0333/), so I really want a proper solution how to remove this error as soon as possible.
Re: Nim vs D
This post is really good but I have another issue when I tried to install windows 10 latest version then my system shows an error [https://errorcode0x.com/solved-dell-error-code-2000-0333/](https://errorcode0x.com/solved-dell-error-code-2000-0333/), so I really want a proper solution how to remove this error as soon as possible.
Re: Nim vs D
opudcyuh
Re: Nim vs D
ojiugdujhn
Re: Nim vs D
This post is really good but I have another issue which is related to my printer when I connect my printer with wifi it shows an error [https://itunessupport.org/blog/fix-error-54-itunes/](https://itunessupport.org/blog/fix-error-54-itunes/), so I really want a proper solution on this error as soon as possible.
Re: Nim vs D
This will be going to manage it in such part where the user will liable to proceed it with the [https://netgears.support/blog/netgear-r6700-nighthawk-ac1750-review](https://netgears.support/blog/netgear-r6700-nighthawk-ac1750-review)/ so just follow the function.
Re: Nim vs D
I agree with some points but that > The NIM project founder is sort of a one person show in development and > promotion. is plain wrong. Not having a large organization like Mozilla behind it Nim can obviously not compete with some "competitors" in terms of how many full time developers it has - but it does have some, plus some who more devs who are not in the core team but who significantly contribute to Nim.
Re: Nim vs D
The NIM project founder is sort of a one person show in development and promotion. I wouldn't say it is not ready for real (commercial) use without being objective, as you have to really characterize what those requirements are. If one considers commercial criteria to be something like: toolchain quality, IDE support, documentation, platform support, sustainable community, fair licensing terms, significant technical merits, actual adoption in the enterprise or research community, and commercial support available. I'd agree that if your graded NIM across these criteria, it doesn't score high. What impresses me about it are the technical merits, platform support, and its toolchain.
Re: Nim vs D
The process where it will be going to provide the perfection for the user to proceed it. So this will be taking guided by the https://epsonsupports.net/blog/epson-printer-not-printing/";>epson](https://epsonsupports.net/blog/epson-printer-not-printing/";>epson) printer not printingfor finding the valuable work which will be going to acquire the part.
Re: Nim vs D
The process where it will be going to provide the perfection for the user to proceed it. So this will be taking guided by the https://epsonsupports.net/blog/epson-printer-not-printing/";>epson](https://epsonsupports.net/blog/epson-printer-not-printing/";>epson) printer not printingfor finding the valuable work which will be going to acquire the part.
Re: Nim vs D
Let me help you out. I'll emphasize the relevant word to make it easier for you. > I can let other opinions stand and have no need to "facepalm" or similar to > otherwise belittle or attack **anyone** here Maybe, just maybe one might take my opinion re. D as "attack" or belittling IFF I had it written in the _D_ forum. Which, however, is not the case. More generally: Why are you all here, why are you using (and liking I hope) Nim? Because you think that at least for certain jobs it's better than other languages. Maybe even because you think (like myself) that Nim is generally a better language. Some here might be well advised to think about that before getting excited. I did _not_ call Mr. Bright or any D developer stupid or anything negative. I merely stated my personal opinion about D the language - not about any people involved with D.
Re: Nim vs D
Re: Nim vs D
So? You have your opinion and I have mine - and as you saw (with my no further discussing with someone else) I _can_ let other opinions stand and have no need to "facepalm" or similar to otherwise belittle or attack anyone here. In fact I assume the differences in our views largely stem from different points of views, needs, priorities and not from ill will. But well, that attitude seems to not be in reach for everyone.
Re: Nim vs D
I was hoping for a more adult analysis of [Alexandrescu's introspection talks](https://www.youtube.com/results?search_query=Alexandrescu+Introspection) and Nim vs D... > FWIW I had a look at D multiple times and learned to fervently dislike it. My > personal summary is that D is but yet another better C/C++ attempt with funny > gadgets added and an utter lack of consistence in concept and design. You are entitled to your opinion, and I partially agree, but this crude attitude is not very persuasive. I suspect that much of this dislike is only [skin-deep](https://forum.nim-lang.org/t/2811). Some people reject Nim for its [off-side syntax](https://en.wikipedia.org/wiki/Off-side_rule#Off-side_rule_languages); some dislike D for its [wooden joints](https://www.seas.upenn.edu/~andre/courses/CS294F98/parthenon.html) and semicolons... Adding an alternative parser / skin / compiler front-end to either would be a relatively small effort compared to everything else involved in creating a compiler, tooling, and library ecosystem. It's sad that this leads to so much fragmentation and duplication of effort... In VM ecosystems people can "agree to disagree" on the syntax (ex. Scala, Kotlin, Groovy, [etc](https://en.wikipedia.org/wiki/List_of_JVM_languages)) while sharing almost everything else, but native systems languages are stuck reinventing the wheel... > To even put Nim and D next to each other is ridiculous. Facepalm... I agree with @mratsim about the similarities. I've long said that D is Nim's nearest competitor. Both languages are GC-by-default feature-rich system languages with [similar features](https://github.com/timotheecour/D_vs_nim) and [performance qualities](https://github.com/kostya/benchmarks). Both are a lot less popular than they deserve to be. They are also top contenders for people who care about [ecosystem independence](https://voat.co/v/programming/2853775) and [legal unencumberedness](http://copyfree.org).
Re: Nim vs D
> Well noted, I could provide more detail (and I did for Nim which is worth it) > but I don't for D. No you didn't develop for Nim as well. > With all due respect I'm not interested in your list. Those things are > technicalities. A good language, however, needs deeper insights (I'd even say > wisdom). Your argument basically boils down to braces vs no-braces, while you dismiss my list as technicalities I could also dismiss yours as superficiality.
Re: Nim vs D
Hmm, I see. A classical political correctness and Über-Ich argument ... Well, no. I clearly said "personal summary" and I have no obligation to meet any arbitrary conditions like e.g. "examples!" Well noted, I _could_ provide more detail (and I did for Nim which is _worth it_ ) but I don't for D. But I will provide one hint as a token of good will: readability. Unlike Nim D stayed stuck in the braces and "let's save some characters for efficiency" paradigm - which has been demonstrated to be a _major_ source of errors. Summary: D is, just as I said, just yet another "let's make a better C/C++" (with some thrown in/glued on modern stuff. With all due respect I'm not interested in your list. Those things are technicalities. A good language, however, needs deeper insights (I'd even say wisdom). Araq demonstrably has that insight while Mr. Bright actually comes from a decades long C compiler background. Nothing against Mr. Bright, he is probably a nice and smart man, but he even said himself (!) that D came into existence to be a better C/C++. Classical premise problem.
Re: Nim vs D
There's no need for disparaging other languages, especially without examples to give more substance to your claims. I do feel like in terms of design goals and at a high level, D is the closest cousin of Nim. * statically compiled * strong meta-programming and CTFE * C and C++ FFI * Procedural programming with a bloat-free syntax * fast compilation speed * GC with escape hatch (?)
Re: Nim vs D
FWIW I had a look at D multiple times and learned to fervently dislike it. My personal summary is that D is but yet another better C/C++ attempt with funny gadgets added and an utter lack of consistence in concept and design. To even put Nim and D next to each other is ridiculous.
Re: Nim vs D
" **I believe we are the language with the best static introspection in the world** " — [AA](https://en.wikipedia.org/wiki/Andrei_Alexandrescu) @ [Dconf 2018 in Munich](http://dconf.org/2018/index.html), three minutes into "[Ask Us Anything](https://www.youtube.com/watch?v=3XOfUcv6sjk&index=5&list=PLIldXzSkPUXXtAvzS0RDCi3Cm0t5h4B-a&t=175s)"... _OH SNAP!_ Metaprogrammingnerdkrieg... ;-)
Re: Nim vs D
I've created a git repo to compare D vs nim, with the goal of having an up to date comparison of features between D and nim and 1:1 map of features and libraries to help D users learn nim and vice versa. Better as a git repo than a forum to have all info organized in 1 place. PR's are welcome and merged quickly. Thanks! [https://github.com/timotheecour/D_vs_nim](https://github.com/timotheecour/D_vs_nim)/
Re: Nim vs D
I like D quite a bit, and there's clearly been some convergent evolution (UFCS) with Nim. The D story with respect to memory management is still unfolding. As was already said, I think the language could have been designed to make GC easier, perhaps separating **ref** and **ptr** like Nim. Then it might not be in the current mess with the GC. I like Nim the language more. I'd like it if Nim modules could be locally imported, like D ones, but I'm pretty sure Araq doesn't like that idea. IMO, the main advantage of D vs Nim is that the language is already well past it's '1.0' release and has a larger community. It feels like a safer bet for many industrial users, though not as safe as any mainstream language. Nim is still more of a work in progress than D, [parts](file://Users/bpr/Applications/Nim/doc/html/manual.html#generics-vtable-types) of the manual aren't implemented, the OO and async stories are unfolding, the community is tiny, and most discussion appears to happen on the IRC. It's still an 'early adopter' language.
Re: Nim vs D
This recursion unpacking/unrolling trick that gcc does (at call-site if insulated by call via volatile function ptr, and always inside the recursive impl) is, in my experience, a rare compiler optimization, but maybe it will catch on. clang does _neither_. If you `objdump -D` the executable (or disassemble in `gdb`/etc.) you will see the single `callq` to Fibonacci at the entry with the full N and a pair of `callq` inside the impl. So with clang the full [1.618**n work](https://stackoverflow.com/questions/360748/computational-complexity-of-fibonacci-sequence) happens. On my i7-6700K Linux with gcc-7.1.0&clang-4.0.1, I get a time ratio of about 15.3 to 1 (53.5s/3.5s). For what it's worth, it's likely the compiler writer guys think of this as mostly a "remove a few funcalls here and there" type optimization..maybe use SSE/AVX/branch predictor a bit better, maybe save a little dynamic stack usage, etc. This doubly recursive Fibonacci approach just happens to be about as sensitive as possible to that particular optimization because it can save exponentially many funcalls.
Re: Nim vs D
I am using mingw64/clang64 in Msys2. But I found that the exe file build by clang runs very slower than exe by gcc. The nim is a fresh build from github source yesterday $ nim Nim Compiler Version 0.17.1 (2017-07-07) [Windows: amd64] Copyright (c) 2006-2017 by Andreas Rumpf for the mentioned nim file (a.nim) proc fibonacci(n: int): float = if n < 2: result = float(n) else: result = fibonacci(n-1) + fibonacci(n-2) echo fibonacci(50) first, for cc = gcc in nim.cfg $ gcc --version gcc.exe (Rev2, Built by MSYS2 project) 6.2.0 Copyright (C) 2016 Free Software Foundation, Inc. $ nim c -d:release --out:a_gcc.exe a.nim $ du -b ./a_gcc.exe 457546 ./a_gcc.exe $ time ./a_gcc.exe 12586269025.0 real0m5.164s user0m0.015s sys 0m0.015s Then use cc = clang in nim.cfg $ clang --version clang version 3.9.1 (tags/RELEASE_391/final) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: E:\msys64\mingw64\bin $ nim c -d:release --out:a_clang.exe a.nim $ du -b ./a_clang.exe 423480 ./a_clang.exe $ time ./a_clang.exe 12586269025.0 real2m2.055s user0m0.000s sys 0m0.015s
Re: Nim vs D
I get the same perfect line with the Nim fib(47..57) as well. { Well, slightly
slower: log_1.618(wall) =~ N - 47.35. So, 1.618**(47.67-47.35) = 1.16 or around
16% slower. }
Re: Nim vs D
@cblale I was actually talking about the Nim fib(55)
Re: Nim vs D
@aedt - with that C program I posted and just changing the numbers, I see no change in behavior at all: N fib(N) log_2(Fib(N)) WallTimeUsrCPU log_1.618(Tm) 57 365435256832 38.410825 88.338572 88.29 9.31268150798 56 225851408384 37.716583 54.570624 54.54 8.31166257771 55 139583848448 37.022341 33.718429 33.7 7.31112152655 54 86267559936 36.328100 20.863663 20.85 6.31352254278 53 53316284416 35.633857 12.885360 12.87 5.31201286047 52 32951275520 34.939615 7.9617497 7.95 4.31148872869 51 20365008896 34.245373 4.9201932 4.91 3.31125979281 50 12586267648 33.551131 3.0422103 3.04 2.31214787174 49 7778741248 32.856890 1.8785994 1.87 1.31034617400 48 4807526400 32.162648 1.1626232 1.16 0.31313742467 47 2971214848 31.468406 0.7182663 0.71 -0.68769978950 46 1836311680 30.774164 0.4441032 0.44 -1.68685323404 45 1134903040 30.079922 0.275319635 0.27 -2.68048037749 Indeed the fit is basically a perfect straight line: log_1.618(time) = N - 47.67. The integer is only passed around as an argument. The arithmetic is all float32 (or maybe float64 depending on impl). So, to me this is as should be expected. I believe that is the case in all your benchmark versions, too. Not sure what is going on for you.
Re: Nim vs D
I think the difference is in the details, but the details matter. I would really be interested to get some experience from people who actually had projects in both languages. Because then you get to know about differences that actually matter. A tiny feature of the Nim language, the dot call syntax for simple procedures in combination with the generics really changed a lot of how I structure my code. My mind is now free of class hierarchies mixins traits and all that other crap I simply don't need anymore. Maybe here and there, but I don't want it anymore, and I don't try to use it anymore to solve my problems. I did not expect this to be so nice to work with. D is more with the old fashioned class systems, at least that is what I expect it to be. I did not actually use D, I just read the documentation and presentations about it.
Re: Nim vs D
The [recent blog post](https://nim-lang.org/blog/2017/05/25/faster-command-line-tools-in-nim.html) I wrot eon the Nim blog also explored performance and build times in D/Nim based upon a blog post on the D site. In it you can see that D and Nim achieve similar speeds in that particular benchmark (with Nim being faster when using Clang, but slower when using GCC according to [this issue](https://github.com/euantorano/faster-command-line-tools-in-nim/issues/1)). What I found most interesting in that performance comparison though was how easy it was to write an optimal version of the Nim program - the standard library CSV parser was my first choice of tool and I didn't have to then dig around for more optimisations (like D's 5 steps to get an optimal version using things like "splitter" and "appender!") which says a lot about how well written Nim's standard library and the language itself is in my eyes.
Re: Nim vs D
@cblake Also I have noticed that if you do a fib(55) the time increases significantly. This is probably because of integer precision choices, but I may be wrong. @Araq I agree. The generated C codes always add a great deal of tedious optimizations that users will tend to forget about.
Re: Nim vs D
Oh, sure. There isn't _usually_ a 1.618**4 kind of work reduction in play, though. Araq would know, but I doubt the reason NimMainInnner is called through a volatile function pointer is to trick gcc's optimizer, though that is a happy side effect. To me, this was just a performance mystery that I found curious and thought others might appreciate the answer to. Also, more Nim-relevant might be the [automatic memoization thread](https://forum.nim-lang.org/t/1343) which is a more dramatic optimization aedt might appreciate. Of course, an in-line array or even just the closed-form formula are faster still for Fibonacci, but presumably the point of this benchmark from xyz32/aedt was to stress test recursion in a programming language. They may want to reconsider that benchmark to something with less exponential sensitivity to unrolling tricks - unless, of course, the intent is to measure unrolling tricks.
Re: Nim vs D
The produced C code by Nim tends to optimize well in general though.
Re: Nim vs D
Ok. This works (replicates Nim performance) for me (on gcc-7.1.0 x86_64 Linux -
not sure what others):
float fibonacci(int x) {
return x < 2 ? (float)x : fibonacci(x - 1) + fibonacci(x - 2);
}
#include
void NimMainInner() {
printf("%.0f\n", fibonacci(50));
}
int main() {
void (*volatile inner)(void) = NimMainInner;
inner();
return 0;
}
Evidently, gcc can only figure out how to unroll the top levels of the
recursion {to call just fibonacci(38..44)} only if the call site has been
isolated by being called through a volatile function pointer which Nim happens
to do.
Re: Nim vs D
In case anyone else is curious about aedt's fibonacci benchmarks, I found an explanation for the approx 6..8X time difference of C vs Nim (with gcc as a backend, on Linux). It took digging into assembly to figure it out, though. With the Nim version, the nested calls/various module boilerplate allow gcc to unpack the top several entries of the recursion _at the call site_. It is not a properly memoized/fully made iterative tail call, though as in aedt's editted comment. (Both versions unpack a few levels in the fibonacci function itself). So, really the doubly recursive call is invoked with a number 4 or 5 smaller than the pure C implementation and so runs much faster since the running time is exponential in N. So, this is mostly just good luck for Nim-gcc in this highly specific benchmark, not something fundamental in the language or impls that would generalize all that well. (I haven't figured out how to tweak the pure C to get gcc to engage that optimization, but presumably someday the gcc folks will do so behind the scenes or maybe there's already a magic -f flag I'm unaware of.)
Re: Nim vs D
@aedt Don't get me wrong, Andrei Alexandrescu and Walter Bright are on my list of the smartest people and are there to stay. Some time ago I considered D to be the best language ever. But you know, opinions may change over time =) Nim also has CTFE, but it is more powerful, because it allows to run other processes, and FS access. Also Nim's CTFE is a register VM, while in D it is an interpreter. Theoretically this makes Nim CTFE faster, but surely it's just an implementation detail that may change eventually. Nim's macro system is so powerful, that you can implement D string mixins in it like so: import macros macro stringMixinLikeInD(s: static[string]): untyped = parseStmt(s) # This is the implementation of string mixins. Period. const myNimCode = """ echo "hello world" """ stringMixinLikeInD(myNimCode) But you're not likely to do such things in Nim, because macros are smarter than that. When you get the hang of Nim you will start asking questions why in D statically computed values are called enums =). I know, it's C++ legacy, but just think of it. In Nim those are consts, just like it should be.
Re: Nim vs D
For me the killer feature is readability: no bracket, no semicolon. Also when reading other's Nim code, most of the code I see is really clean and in short self-contained functions.
Re: Nim vs D
**gokr:** _I don't know D, but I am quite sure that Nim beats D on these three specific meta programming aspects (just looked them up quickly)._ This is arguable. While Nim's AST manipulations are generally more powerful, the "string mixin hacks" are often plenty sufficient to get the job done and generating strings is generally much easier than generating AST structures. What I really want is both, not one or the other. **gokr:** _Nim uses a VM (!) during compilation (also the basis of Nimscript) which means meta programming and const procs etc can be run at compile time._ D also has CTFE. That's not a significant difference. For what it's worth, the killer difference between D and Nim for me is the GC. D doesn't have an incremental GC (let alone a generational one), and the (fully conservative, stop-the-world) one it has just isn't very good. While there's some interest in improving the situation, the language design of D makes it difficult to fix the core issues involved. This leads to D having the problem of trying to work around the GC not just where a GC isn't a suitable option, but also where D's GC runs into its limitations. In short, D sometimes would force me to revert to manual memory management, which I have no interest in whatsoever. There are other things that I really like about Nim, but that's the do-or-die aspect of it. (As a result, Nim competes with OCaml for most of the work I'm doing, not D.) Other than that, there's a lot of good stuff in D that I really, really like (Walter Bright and Andrei Alexandrescu have probably forgotten more about language design and implementation than I know) and where I wouldn't mind if Nim borrowed a thing or two.
Re: Nim vs D
@aedt Regarding CTFE, static ifs and Mixins: Araq (author of Nim) already mentioned **"A real hygienic macro system, no string mixin hacks."**. I don't know D, but I am quite sure that Nim beats D on these three specific meta programming aspects (just looked them up quickly). Nim uses a VM (!) during compilation (also the basis of Nimscript) which means meta programming and const procs etc can be run at compile time. Also, the AST is yours to manipulate using macros/templates in Nim running via the same VM, so ... it's pretty darn neat. I haven't personally dwelved much into Nim's meta capabilities, but anyone following Nim will find that it's the basis of a LOT of good nice stuff in Nim.
Re: Nim vs D
D may be more "complete" as it is older. Nim has compile time function execution and Mixins, but D's Mixins may be different, I don't know. Static ifs -- maybe that is what Nims when expression is. From the current version of the book it may be not possible to learn all the advanced stuff of Nim, you may also consult the manual and read the forum postings of the smart people in the last years.
Re: Nim vs D
@ yglukhov While you make good points, I would argue that D feels more ... ... "complete". Don't get me wrong, I like Nim. However D is self hosted, and it has nice features like CTFE, static ifs and Mixins etc. I'm currently reading through the Nim book so I don't quite know if Nim has these. Both D and Nim are great imo, but D has had the blessing of genius minds like Andrei Alexandrescu and Walter Bright. Tldr: Haven't finished the book yet, Nim looks pretty promising but I can't compare them yet. If anything, both these are easier to work with than C++.
Re: Nim vs D
I've used to use D a while ago, but here are the things that made me switch and i'm not going back. * Nim is magnitudes of orders easier to contribute to. Not only the compiler code is easier to reason about (at least for me), but PRs are accepted a lot more willingly. I bet such openness of the core devs makes Nim evolution faster and I hope it's gonna stay that way no matter 1.0. * Nim emits C code and you can break in with emit pragma. That means that in no case should you write C code outside your nim file, no matter which platform you're targeting. * AST macros which D doesn't have is the gatling laser gun feature that should blow the minds of the most pervert metaprogramming junkies. Although with Nim you start thinking about metaprogramming in a different way from D/C++. * Nim's type system is different (IMO it is simpler (but not subset) and better at the same time), because Nim thinks that some things in D/C++ type system don't "matter" that much and only create friction, instead it focuses on some other things that "matter". * Nim is generally a fresher look at the current state of procedural programming languages, than D or something that tries to be C++, but better. * Nim's GC is precise, thread-local, a bit more deterministic and a lot faster, you can even timeframe it if you need consistent 60fps for example. There is some cost though that you always have to scratch your brain when going multithreaded. I hope though that this problem will be solved eventually. * Lots more, read the manual! =)
Re: Nim vs D
> Without main function: 5.004 s With main function: 3.126 s That is really some magic which we should investigate, document and remember.
Re: Nim vs D
Without main function: 5.004 s With main function: 3.126 s
Re: Nim vs D
> and using an explicit main function: Really? I would be (again) very surprised, as fibonacci() was already a standalone proc, and all execution takes place inside this function. I can not imagine that the symbol "main" does any magic, and that echo is faster inside main should be not really relevant.
Re: Nim vs D
I don't understand why the other languages are slower, but you can make the Nim version faster by using smaller types (same as your other languages) and using an explicit main function: proc fibonacci(n: int32): float32 = if n < 2: result = float32(n) else: result = fibonacci(n-1) + fibonacci(n-2) proc main = echo fibonacci(50) main()
Re: Nim vs D
@aedt Your numbers are vastly off what other people report. Something has to be wrong with your way of measuring things.
Re: Nim vs D
This is very interesting. I am a big fan of D, and I use D as my to-go
language. I like Nim too. But how come the difference between D, C++ and Nim be
so big? This is impressive and it's a little bit too good to be true! In my
machine,
//D
import std.conv, std.stdio;
void main()
{
fibonacci(50).writeln;
}
float fibonacci(int n)
{
if (n < 2)
return n.to!float;
else
return fibonacci(n-1) + fibonacci(n-2);
}
LDC/D with
-release -O4
takes 76.9s
//C++
#include
using namespace std;
float fib(int x) {
if (x < 2)
return float(x);
else
return fib(x-1)+fib(x-2);
}
int main() {
cout << fib(50) << endl;
}
GCC/C++ with
-O3
takes 39.9s
//Rust
fn main(){
println!("{}", fib(50));
}
fn fib(n: i32) -> f32 {
if n < 2 {
return n as f32;
} else {
return fib(n-1) + fib(n-2);
}
}
Rust's release build takes 80.13s.
//C
#include
float fibonacci(int n)
{
if (n < 2)
return (float)n;
else
return fibonacci(n-1) + fibonacci(n-2);
}
int main()
{
printf("%f", fibonacci(50));
return 0;
}
GCC/C with
-O3
takes 40.5s
And
#Nim
proc fibonacci(n: int): float =
if n < 2:
result = float(n)
else:
result = fibonacci(n-1) + fibonacci(n-2)
echo fibonacci(50)
Nim's release build takes 5.6s only! What optimization took place in the Nim
build?
