Interesting performance changes over time in Kostyas benchmarks
Kostya has updated his benchmarks today and moved from: gdc 5.2.0 to 6.3.0 LDC 0.15.2 beta1 to 1.4.0-beta1 (LLVM 4.0.1) https://github.com/kostya/benchmarks/commit/73e0cb0e755f8e45d79fd2083b217d107e1185a9 The results are interesting to see as there over a year and half development between versions. LDC seems to have slowed slightly in some benchmarks. GDC shows a more steady improvement. The most noticeable jumps are the Json encoding what is a direct result from the library improvements, where we see results drop van 25 -> 8 and 27 -> 7 ( but a large increase in memory usage ). Brainfuck v2.0 -| D Gdc | 3.05| 1.4 | +| D Gdc | 2.61| 1.4 | -| D Ldc | 2.02| 0.9 | +| D Ldc | 2.85| 1.0 | mandel.b -| D Gdc | 29.49 | 2.4 | +| D Gdc | 27.40 | 2.4 | -| D Ldc | 24.90 | 1.4 | +| D Ldc | 31.21 | 1.8 | Base64 -| D Gdc | 2.52| 33.3| +| D Gdc | 3.04| 54.1| -| D Ldc | 3.14| 53.1| +| D Ldc | 2.01| 54.4| Json -| D Gdc Fast | 0.34| 226.7 | +| D Gdc Fast | 0.35| 234.1 | -| D Gdc | 25.86 | 926.1 | +| D Gdc | 8.89| 1357.2 | -| D Ldc | 27.23 | 919.6 | +| D Ldc | 7.13| 1357.0 | Matmul -| D Gdc | 2.33| 73.0| +| D Gdc | 2.30| 73.0| -| D Ldc | 2.01| 68.9| +| D Ldc | 2.17| 73.0| Havlak -| D Gdc | 31.79 | 197.6 | +| D Gdc | 24.98 | 451.6 | -| D Ldc | 25.15 | 214.9 | +| D Ldc | 22.41 | 467.9 | As we see with the json results, massive speed differences can be hiding ( in exchange for more memory consumption ). Unfortunately, he has not updated DMD but i expect that we may see the same jump in the Json test. The Havlok results stand out a lot with twice the increase in memory but a relative low gain ( vs the memory increase ). The LLVM results surprised with LLVM 4.0.1 not showing much improvement and resulting in noticeable slower times in several tests.
Re: Editor recommendations for new users.
On Monday, 28 August 2017 at 21:17:19 UTC, Moritz Maxeiner wrote: Why "again"? You've not stated so before AFAICT. Regardless, I disagree that discussing the validity of recommendations in a thread specifically made to gather such recommendations is a distraction from the topic; I would contend that it lies at the heart of the topic. The poster asked for programs that fit his (vague) criteria, it is NOT up to you to determine what those criteria are and then belittle people there posts that try to help out with there own recommendations. The fact that you can not see this even now, really is a issue. And i am not referring to this topic alone or those that i personally post in. There are many where the same patterns are viable and i notice the pattern, that its always your name next to those posts. Is it so hard for you to not always override topics here and constant "straw man" or other terms calling. And i use this term because because you constantly write "irrelevant", "straw man argumentation", "but I don't care" and other belittling statements that seem to indicate that your opinion means more then others. Or how you supposedly do not care and have no issue pointing it out half a dozen times. It gets very fast tiresome. You are the only poster that i see here that is non-stop doing this. If you do not like something or find it irrelevant, then do not respond to it. But they way you act, like posts are below or irrelevant to you... This is the "again" i refer to. You do this is a lot of topics. You dissect people there posts and write how it is irrelevant to you or some other clever looking down terminology. It totally distracts from the topic at hand and frankly, makes people less likely to continue topics. Its this kind of attitude that in MY personal opinion makes this mailing board toxic for new users. While you are not impolite, the way you act upon people the posts makes it hard to have a honest discussion with you without it turning off-topic or simply scaring away people. So again polity again, to refrain from acting like this and let people have there own opinion without you dissecting every piece. Its turns topic off-topic and adds no value to the discussion. I await your next well written comment how what i wrote is irrelevant and how you do not notice this behavior. This site really needs a proper forum with the ability to block specific posters and make this board less toxic. Because 99.9% of the people here are nice but your behavior is hard to deal with. And i am sure you will disagree with this. Stay out of my posts and stop looking down on people and we will get along. This is my last post on this off-topic issue.
Re: Editor recommendations for new users.
On Sunday, 27 August 2017 at 18:08:52 UTC, Moritz Maxeiner wrote: It's nearly ten times the size, so yeah, it is relative to Textadept. You can say the same thing in comparison with vim which is only a 2MB install size, 20MB in comparison is gigantic. Indeed, but that's only the raw executable, not the full package (which includes things like syntax highlighting), which adds another 26MB. But, yes, Textadept and vim+vim-core (Gentoo speak) are both gigantic required to bare bones vim. But bare bones vim doesn't fulfill the syntax highlighting requirement IIRC. The requirements are rather vague, you can interpret it in a number of ways. The sensible interpretation imho is "as low an install footprint as possible while still fulfilling the other requirements". I'm not aware of anything below ~20MB install footprint that fulfills the other requirements, but I'd be interested if you know any. As the OP did not state any requirement, he can consider 2GB as small. Vague requirements do not invalidate the recommendation. Laptops have 1TB harddrives as good as standard. Even on a "small" 128GB SSD, it pales in comparison to the 10GB that Windows alone takes. Let alone the page file, swapfile, hibernation file etc... I wouldn't consider 200MB gigantic in comparison to 20MB cause there is literally no difference of use for me. The thread is about OP's requirements. You'd have to have a really shitty laptop for it to be an issue. Not relevant. As the OP has not stated the size of the laptops it needs to be installed upon, the discussion about 180MB vs 20MB or 2MB is irrelevant. We are not talking a 4GB Visual Studio installation. And its 160MB for the 32Bit version. :) So if the OP has other requirements, HE can state them in this topic, instead of you making up ideas as to what YOU consider small. Your comments are irrelevant without knowing the OP his expectations. So again please do not distract from the topic.
Re: Promoting TutorialsPoint's D tutorial
On Sunday, 27 August 2017 at 18:51:00 UTC, Moritz Maxeiner wrote: Thanks, but as I pointed out, the website's design is of no interest to me personally. As I said, you aren't going to change my interests (and I'm reasonable convinced you won't change other peoples', either). Add my voice to that corpus - I honestly don't care what the website looks like. This whole topic is about improving the website. The fact that you are already a well versed D programmer that sees no usefulness in actually improving the readability of the site is irrelevant. The constant repeating that it does not interest you, simply discourages people. Same with pointing out that ( you think ) he can not change other people his minds. I personally think he is right and the site is not information friendly. Lots of content does not mean its useful if that content is badly presented. If somebody is spending a lot of time simply writing issues that they think can be improved, let them try. Even if it dies later in the topic. If this topic did not exist, i will not have found out that Adam has a experimental library, that hands over heels wins compared to the current massive text blob. Even if its a few versions behind, its way more clean and easy to use the what is now on the website. http://dpldocs.info/experimental-docs/std.html So at minimum one positive thing came from the topic.
Re: Editor recommendations for new users.
On Sunday, 27 August 2017 at 10:05:29 UTC, Nicholas Wilson wrote: So I will be doing a workshop on programming for the biology department at my university and I was wondering what would best suit the users. The following are a must: support windows & mac ( the more consistent between the two the better) free no large install footprint, preferably simple install procedure (running on laptops) syntax highlighting straightforward to use anything else is a bonus. Whats your experience with what you use? Visual Studio Code seems to be what you need. https://code.visualstudio.com/ Easy to install, Support Windows, Linux, Mac. Has plugin support from WebFreak001 his Code-D / Serve-D(beta) plugin. Kitchen and sink support. Easy to use ( as seen with the popularity ). Relative low memory footprint for the functionality ( compared to several IDEs that do the same ). Moved to Visual Studio Code a long time ago and loving it. They are now adding multiple workspaces to the editor, to make things more easy for people and plugin architecture. Did i mention massive plugins? Git Integration to make it easier to teach people what Git is and what the difference it makes in programming projects.
Re: Promoting TutorialsPoint's D tutorial
On Sunday, 27 August 2017 at 00:05:00 UTC, Adam D. Ruppe wrote: On Saturday, 26 August 2017 at 23:53:27 UTC, Ryion wrote: I have the same issue with the Library. The flow of information is bad, too much walls of text, with too much assumption that Have you tried my alternative? It is the same content (well it lags a version or two cuz i haven't updated my computer yet) but laid out differently. http://dpldocs.info/ http://dpldocs.info/experimental-docs/std.stdio.html for example It looks a lot better Adam, especially compared to the D website design. I am even willing to bet that it has much better results with Search Engines, because it has separate pages. In my opinion its much more inline with my expectation for a programming language documentation. Nice job Adam! Going to bookmark it and use that as my reference.
Re: Promoting TutorialsPoint's D tutorial
On Saturday, 26 August 2017 at 22:26:00 UTC, Ecstatic Coder wrote:
I've no problem with that, but would it be possible to consider
adding also a link to this tutorial in the same paragraph ?
https://www.tutorialspoint.com/d_programming/
It's not because TutorialsPoint pay me, but because it may be
one of the best D tutorials out there for both beginner D
programmers.
And honestly, at the moment it's not really that easy to reach
this tutorial from the dlang website.
First you have to push on "Tutorials", then in the middle of
the page you see a boring flat grey icon with this text beside :
"D programming
Unknown
January 1, 2015
A nice introductory tutorial to D programming. Available
on-line and in the PDF format.
Website"
The text is fine, but unfortunately the impersonal icon and
text ("D programming") aren't that inviting...
If you don't want to put the link on the "Further reading
page", maybe would you consider putting this nice tutorial for
beginners just under the four official D books, before the more
advanced readings ?
I guess many beginner D programmers will thank you :)
Because a few month ago I've been that beginner D programmer,
and sadly I've completely missed this perfect tutorial. And
I've just explained you why...
So why not supposing other programmers will have the same
problem, and maybe miss it just like me ?
No, i have the same issue with the website. Tutorialspoint may
have issues as ag0aep6g pointed out but its very much to the
point. I prefer to look up information on tutorialspoint compared
to the D website.
Lets say Arrays:
* D website starts with Pointers, then Static Arrays, then
Dynamic Arrays then ... A person may simply say: "I just want to
know how to write a array, i do not need a tutorial talking about
the different types, because most of my work is simply standard
arrays".
Instead of splitting the information in different chapters, its
so much text on a single page. Tutorialspoint simply shows the
basic information and that is what i need 90% of the time.
How about Modules:
* D website starts with a big blog of texts Module,
ModuleDeclaration DeclDefs DeclDefs. What am i reading. Chinese?
By the time you see the visual text how to declare a module, you
are already 2 pages down.
Tutorialspoint simply shows how to declare modules. Basic, fast
...
Tutorialspoint indeed misses a lot of information but D website
has unreadable information overload. Useful for people who have
time to read half a day but as somebody programming and wanting
to quickly look up information. D website is not useful. Its
actually counter intuative.
It feels academic in design, not functional. You expect to get
simple example and the more advanced items under "advanced".
I have the same issue with the Library. The flow of information
is bad, too much walls of text, with too much assumption that the
programmer reading it is familiar with the more advanced features
or programming knowledge. Links and references to variables that
frankly, are unneeded. If it takes 15 minutes to know in
std.parallelism that you can not get a thread ID in a simply
way... then the purpose as a information source fails.
A simple:
https://dlang.org/phobos/std_datetime_date.html
Why do you need to wade past 2 pages for
jan
feb
mar
apr
may
jun
jul
aug
sep
oct
nov
dec
sun
mon
tue
wed
thu
fri
sat
...
Then the whole Jump to: 2, Jump to: 2, Jump to: 2 ...
Function naming...
Expect: bool validTimeUnits(string[] units...);
Gets: pure nothrow @safe bool validTimeUnits(string[] units...);
... Visual noise that is not important. Details like that need to
be in a sub page.
People care about the function, parameter, return type. The rest
is "advanced" and only useful under specific sitations.
After months i still do not use the library/documentation. I end
up googling for examples or use tutorialspoint for some quick
basic lookup's. If i am really stuck i may go into the library
and get frustrated with the wall of text. Its is too much a time
sink, while its supposed to be a help.
I do not know how to explain it but the documentation is at times
more frustrating then the issue i am trying to solve. If i had to
give a score, the D documentation is at best 4/10. Its not the
lack of information but the simply bad presentation, overflow of
information where you do not need it. No clear separation. Mobile
friendly it is NOT. Even 4K friendly it also not. And plenty of
other issues.
Re: newCTFE Status August 2017
On Monday, 14 August 2017 at 11:25:14 UTC, Stefan Koch wrote: Release is coming closer! Nice, keep up the good work.
Re: What are we going to do about mobile?
On Thursday, 24 August 2017 at 14:28:07 UTC, Joakim wrote: Unfortunately, not everything works great. Like LDC being version 0.14.0 ( 2014! ) on the Pi3 Debian images. And well, "_Unwind_RaiseException failed with reason code: 2128056904", on a simply compile. Not exactly hopeful. Have you tried this more recent build of ldc 1.1.0 (third link in Downloads section at bottom)? https://github.com/ldc-developers/ldc/releases/tag/v1.1.0 Thanks. I checked the 1.3.0 but there was no ARM build. Did not realize there is one for 1.1.0. For anybody finding this using google search, simply do the following to install: wget https://github.com/ldc-developers/ldc/releases/download/v1.1.0/ldc2-1.1.0-linux-armhf.tar.xz sudo tar -C /usr/local -xf ldc2-1.1.0-linux-armhf.tar.xz export PATH=$PATH:/usr/local/ldc2-1.1.0-linux-armhf/bin My code now works correctly again. Doing some benchmarks Apache+PHP vs Go vs D on the Raspberry Pi 3. n=10 c=500 Apache: 1488 seconds Requests per second: 67.20 Go+Gin: 123 seconds Requests per second: 812.23 D: 149 seconds Requests per second: 629.46 D is running a simple socket + limited HTTP 1.0/REST framework that i gobbled together. No optimizations. Go is running a complete HTTP/REST framework so it has more overhead. Apache+PHP5.6 simply suffer beyond belief. Take in account, the D has only been done on a single core! Where all the others used all 4 cores. Impressive even if its not apples to apples comparison.
Re: What are we going to do about mobile?
On Thursday, 24 August 2017 at 10:47:07 UTC, James W Hofmann wrote: I happened across this old thread in a search for "mobile app dlang". I got a Chromebook recently and it represents a substantial phase shift in devices for me: Arm has indeed become a more compelling platform, especially with all the SBC that exist today. Nothing more fun as compiling code on a Pi3 and seeing that little monster working like the big boys ( of course slower ). Unfortunately, not everything works great. Like LDC being version 0.14.0 ( 2014! ) on the Pi3 Debian images. And well, "_Unwind_RaiseException failed with reason code: 2128056904", on a simply compile. Not exactly hopeful. C works great. C++ same. GoLang version 1.3.3 and later perfect. FreePascal totally useless with "An unhandled exception occurred at $00084234". Its interesting to see what languages work and those that bum out with default debian installations. So its a mixed bag on ARM development. But people underestimate how fast the ARM platform is evolving regarding speed. The Pi3 has 4 Armv8 A53 cores but you got now systems like Helion X20 with 2 * A72, 4 * A53 and another 4 * A35... Getting to being only 1/4 then a full blown Intel 7600. All that for a 15W max package. And this year we are getting 10nm X30 with more updated cores. Good times... The PC evolution market in regards to CPU technology has been frankly very dead for the last few years. Small gains each generation but nothing impressive. The only impressing thing has been the AMD Ryzon's that finally pushed 8 cores into consumer hands for a cheap price ( and the thread ripper for 16 for a "reasonable" price, unlike Intel there prices for ages ).
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Wednesday, 9 August 2017 at 07:59:46 UTC, Ryion wrote: And that person pushing has much more effect :) And a actual forum with a edit button may also be useful. Instead of this mail system.
Re: Jetbrains announce support for rust plugin, show them we want one too!
Maybe i made myself not very clear. Sorry about that. I mention this as reading topics here shows the same behavior. People complain. Specific people here keep responding how the complainer needs to do it themselves or pay for it. Tracing the people that "complained" there post history, shows that most of them simply do not post anymore, after being told to do it themselves. I do not want to wast people there time, i only responded to this here because its obvious pattern. I agree that this seems to be a very small community and it is hard to get things done in a small community. But it is counter productive to constantly tell people that there is no solution, they need to do it or pay for it. Its like hearing a broken record that keeps skipping to the same beat. People who have the time and willingness to do so, WILL do it themselves without being told on a forum. All the rest is simply negative PR for the people who lurk ( not post ) and read the comments. The 'we' refers to me and my colleague. And 'we' do mean that the amount of posting here that ask people to do the work is way more then on other language forums. We understand the reasoning but its about first impressions. And when anybody reads comments stating the above too many times, it simply feels like the community is too small to support the language. Causation and effect. The more pushing does not result in more people actually contributing. It can have the reverse effect of actually pushing people away. Its beating a dead horse because i expect that months from now, the same pattern will still be here. Need to get back to actual work or the boss will be less happy. And that person pushing that much more effect :)
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Sunday, 6 August 2017 at 19:15:59 UTC, bachmeier wrote: Your claim to have limited D skills doesn't prevent you from writing a blog post detailing the things that are missing for Windows development and showing how other languages deal with them. A lot of work with tooling doesn't require D skills for that matter (for instance, Eclipse plugins are not written in D AFAIK). You can ask the current tool developers how to help, report bugs, make suggestions, fix small bugs, The least effective thing to do is to post on the forum that the tools aren't good enough. I applaud the people who contribute but reading posts here that pushing people ( on a lot of topics ) to contribute does not exactly motivate. It shows a rather desperation that we do not see in other languages forums. Having people write plugins is one thing. Having them supporting those plugins for years to come, that is another. Its not the actual the written the plugins that is a issue. There are plenty of D plugins out there. But people get discourages, lack of time, run into issues they can not figure out, new D version, new IDE changes... whatever changes that break the plugins. There are plenty of plugins for almost every editor/ide but few are well supported because it ends up being one man development teams. So what is the point in pushing people: write plugins, put time into them, ... when even the people know that with there day job, family life they can not keep supporting / expanding the plugins. It feels like this approach is just wrong... When people are motivated, they so so from themselves and do not need the "gentle" pushing on a forum to do so.
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Sunday, 6 August 2017 at 14:49:47 UTC, Moritz Maxeiner wrote: 1) Anecdotes are not useful here 2) macOS is UNIX, same as Linux, so I'm not sure why the distinction matters as a reply to me Same two points as above. Thanks for the interesting reply. /S
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Sunday, 6 August 2017 at 14:16:20 UTC, Moritz Maxeiner wrote: A developer who mostly targets Windows wouldn't. But if you look at the statistics [1] you'd see that in the category of systems accessing the web mobile systems (and we are excluding servers here, who are virtually all UNIX systems anyway) have been steadily overtaking classic desktop systems in market share, from which it can be reasonably argued that it's only a matter of time until the amount of development for Windows relative to overall development is declining (regardless of how little it already has). How sure are you even with statistics... On my work half the developers are on Mac, the other half are on Windows. There is not a single Linux system. From the windows developers 2 use "bash" on Windows regularly. Most firms i have been its always a mix of Windows and Macs. The few Linux guy are die hard fresh from school guys, that are insisted on there Linux system. What some may consider "Ultra Geeks". :-) It all depends on how you define development. For web development the target is Linux but the development environment is often Windows. So what is the correct a statistical target? The best view is to see what is going on around one self and its mostly Windows/Mac with Linux deployment/testing for both systems. Windows Bash making that task more easy for the Windows guys.
