Re: Fastest JSON parser in the world is a D project
If this is the benchmark I'm remembering, the bulk of the time is spent parsing the floating point numbers. So it isn't a test of JSON parsing in general so much as the speed of scanf.
Re: Fastest JSON parser in the world is a D project
On Saturday, 17 October 2015 at 16:14:01 UTC, Andrei Alexandrescu wrote: On 10/17/15 6:43 PM, Sean Kelly wrote: If this is the benchmark I'm remembering, the bulk of the time is spent parsing the floating point numbers. So it isn't a test of JSON parsing in general so much as the speed of scanf. In many cases the use of scanf can be replaced with drastically faster methods, as I discuss in my talks on optimization (including Brasov recently). I hope they'll release the videos soon. -- Andrei Oh absolutely. My issue with the benchmark is just that it claims to be a JSON parser benchmark but the bulk of CPU time is actually spent parsing floats. I'm on my phone though so perhaps this is a different benchmark--I can't easily check. The one I recall came up a year or so ago and was discussed on D.general.
Re: D2 port of Sociomantic CDGC available for early experiments
On Friday, 24 October 2014 at 06:50:05 UTC, Kagamin wrote: On Thursday, 23 October 2014 at 15:53:19 UTC, Sean Kelly wrote: We could experiment with separately linking the GC. It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies. Can't it work like any other user library? Well, on linux at least I think you might have to list it twice. Once before and once after libdruntime. I don't know if there's a portable linker flag that indicates that it should try and resolve dependencies in libraries listed later in the link line.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 14:02:33 UTC, Kagamin wrote: On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG wrote: It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order. At best, they won't clash :) If the default GC is not pulled by the linker, why should they clash? We could experiment with separately linking the GC. It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies.
Re: D2 port of Sociomantic CDGC available for early experiments
On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote: Sure, but past/current env vars being used are used *privately* to a single program. What you're suggesting here are env vars which will affect *all* D programs that see them. If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to. I'm not advocating the approach, but you could create a run_d app that simply set the relevant environment args and then executed the specified app as a child process. The args would be picked up by the app without touching the system environment. This would work on Windows as well as on *nix.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 16 October 2014 at 10:56:49 UTC, ketmar via Digitalmars-d-announce wrote: On Thu, 16 Oct 2014 08:10:38 + Dylan Knutson via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I'm sure there's a cross platform way to retrieve them without bring passed them directly there isn't. Runtime.args?
Re: D2 port of Sociomantic CDGC available for early experiments
On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote: On 10/8/2014 12:43 AM, Leandro Lucarella wrote: I think this is an unjustified fear, there are already many environment variables that can affect your program. That's why they are called... environment variables :) Being on the front lines of tech support for 30 years, it is not an unjustified fear nor a hypothetical problem. What you could do is propose a secret switch to all dmd generated programs that the druntime switch checks before main() gets control, such as: app --druntimeSet=usexxx ...the regular app args ... Back when Druntime was called Ares, it was possible to choose the GC at link time. Do we really need to defer the decision to run time? If so, switching GCs after the app has started should work in most cases, though I'm not sure offhand if memory allocated by the prior GC will be scanned through for references within the new GC.
Re: Digger 1.0
On Tuesday, 30 September 2014 at 09:35:20 UTC, Marco Leise wrote: So why would Apple be able to get away with 1GB on its just released iPhone 6? Maybe 1048576 kilobytes is enough for everyone? ARC is more memory efficient than mark sweep GC like Javascript uses. Though a lot of it is just that iOS developers are simply very careful about memory use. Writing a performant game in iOS is really quite hard because of the memory constraints.
Re: DVM - D Version Manager 0.4.3
On Wednesday, 3 September 2014 at 15:55:47 UTC, Chris wrote: Methinks DVM doesn't get it right. 2.065.zip is available here: ftp://ftp.digitalmars.com/dmd.2.065.0.zip (cf. http://forum.dlang.org/thread/ebvumaoniuukgjbow...@forum.dlang.org) But DVM tries to access it via http: Fetching: http://ftp.digitalmars.com/dmd.2.065.zip An unknown error occurred: tango.core.Exception.IOException@/home/doob/development/d/tango/tango/core/Exception.d(59): The resource with URL http://ftp.digitalmars.com/dmd.2.065.zip; could not be found. The link for 2.065 on http://dlang.org/changelog.html is broken as well. I don't think this particular issue can be blamed on DVM.
Re: DVM - D Version Manager 0.4.3
On Wednesday, 3 September 2014 at 19:34:26 UTC, Chris wrote: I know, but I thought maybe DVM tries different addresses, if one is not working. Anyway it should be on dlang.org/changelog.html. For what it's worth, if you do dvm install 2.065.0 it will find it. Not sure if DVM should try alternates or not though.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote: On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Please understand that I'm not suggesting we start refactoring druntime for 2.067. All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come. The reason these are in Druntime at all is because code in Druntime depends on them. So if they were split into a separate library then it would be a required library. And even if we completely eliminate any dependency on standard C functions, I don't see any way to avoid depending on platform-specific calls. Now I would be fine with including just a subset of declarations in Druntime (which is really what we have right now anyway), but if the remainder were split into a standalone library then things start to get weird. Please let me know if you have a solution to this problem.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 21:38:04 UTC, deadalnix wrote: The problem is that you don't always want to bring libc and libstdc++ with you with every single project you write. Thus it shouldn't be in the runtime (except the very bit you can't get rid of). It can still be core.stdc . To be fair, the only part you bring with you are the dependencies that Druntime itself has. And nearly all of core.stdc is declarations anyway, so the only code bloat is unused ModuleInfo objects (notice that in places where Druntime uses C structs it declares them as =void to avoid depending on default initialization). The remaining issue becomes one of maintenance. If Druntime only declares the functions it needs, then where does the other stuff live? If you want to use that other library to get everything, does it publicly import core.stdc for the basics? What if Druntime needs a new call for some reason that's in this separate library? Do we declare it in core.stdc and cause collisions? What if D is ported to a new platform? That may require a whole raft of new declarations, both in a common API like core.stdc and in something more targeted like core.sys.linux. Don't get me wrong, I hate having to maintain the modules in core.stdc and core.sys. It's the worst job ever. I'm just not aware of a better solution to this particular problem.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote: eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org... One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). An embedded system that can support all of D but doesn't have a cruntime? I don't believe it. If it has a cruntime then providing bindings is a non-issue, and if it can't support all of D then supporting only a subset (and then being free to exclude core.stdc) is inevitable. There was a D runtime years ago created as a separate project around the time that Druntime had its beginnings (as Ares) that had no dependencies on standard C. The creator went by Maide in IRC, and she was doing some really cool stuff with it that made D work kind of like ObjectiveC. I don't think it's in development any more, but it's probably possible to track it down with enough googling.
