headers
David Nadlinger | 10 Feb 2012 01:24
Picon
Favicon
Gravatar

Re: Message passing between threads: Java 4 times faster than D

On 2/9/12 11:17 PM, Sean Kelly wrote:
> On Feb 9, 2012, at 11:57 AM, Martin Nowak wrote:
>> I didn't yet got around to polish my lock-free SList/DList implementations,
>> but mutexes should only become a problem with high contention when you need to block.
>> You'd also would need some kind of blocking for lock-free lists.
>
> No blocking should be necessary for the lock-free list.  Just try to steal a node with a CAS.  If the result was
null (i.e. if the list ended up being empty), allocate a node via malloc/GC.

And the neat thing is that you don't have to worry about node deletion 
as much when you have a GC…

David
Permalink | Reply | 0 comments |
headers
Andrew Wiley | 10 Feb 2012 01:44
Picon
Gravatar

Re: Message passing between threads: Java 4 times faster than D

On Thu, Feb 9, 2012 at 3:06 AM, Nicolae Mihalache <xpromache <at> gmail.com> wrote:
> Hello,
>
> I'm a complete newbie in D and trying to compare with Java. I
> implemented  a simple test for measuring the throughput in message
> passing between threads. I see that Java can pass about 4mil
> messages/sec while D only achieves 1mil/sec. I thought that D should
> be faster.
>
> The messages are simply integers (which are converted to Integer in Java).
>
> The two programs are attached. I tried compiling the D version with
> both dmd and gdc and various optimization flags.
>
> mache

I recently completed a message passing library in D that lets the
messages be passed between actors that don't necessarily correspond to
threads (as std.concurrency requires). I'll see how it does on your
benchmark.
Permalink | Reply | 1 comment |
headers
Adam D. Ruppe | 10 Feb 2012 04:32
Picon

Re: OT Adam D Ruppe's web stuff

On Tuesday, 7 February 2012 at 20:00:26 UTC, Adam D. Ruppe wrote:
> I'm taking this to an extreme with this:
>
> http://arsdnet.net:8080/

hehehe, I played with this a little bit more tonight.

http://arsdnet.net/dcode/sse/

needs the bleeding edge dom.d from my github.
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

Here's the code, not very long.
http://arsdnet.net/dcode/sse/test.d

The best part is this:

  document.mainBody.addEventListener("click", (Element thislol, 
Event event) {
    event.target.style.color = "red";
    event.target.appendText(" clicked! ");
    event.preventDefault();
  });

A html onclick handler written in D!

Now, like I said before, probably not usable for real work. What
this does is for each user session, it creates a server side DOM
object.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Walter Bright | 10 Feb 2012 05:37
Favicon
Gravatar

Re: Carmack about static analysis

On 2/9/2012 12:09 PM, Bruno Medeiros wrote:
> Nice article! I particularly liked this comment:
> "The classic hacker disdain for “bondage and discipline languages” is short
> sighted – the needs of large, long-lived, multi-programmer projects are just
> different than the quick work you do for yourself."

I implicitly agree with you. But people have written large programs in dynamic 
languages, and claim it works out equivalently for them. I don't have enough 
experience in that direction to decide if that's baloney or not.
Permalink | Reply | 6 comments |
headers
bcs | 10 Feb 2012 06:24

Re: RedMonk rankings

On 02/09/2012 09:28 AM, Simen Kjærås wrote:
> http://redmonk.com/sogrady/2012/02/08/language-rankings-2-2012/
>
> Kinda interesting, but as with all these things, don't take it as the
> word of god. Nice to see D all the way up there, I'd honestly expect it
> be lower.

D is neck-n0neck with Go (:D) and behind LISP?!
Permalink | Reply | 0 comments |
headers
Matt Soucy | 10 Feb 2012 06:28
Picon
Gravatar

Re: RedMonk rankings

On 02/09/2012 12:28 PM, Simen Kjærås wrote:
> http://redmonk.com/sogrady/2012/02/08/language-rankings-2-2012/
>
> Kinda interesting, but as with all these things, don't take it as the
> word of god. Nice to see D all the way up there, I'd honestly expect it
> be lower.
I noticed LinkedIn mentioned in the article...so apparently D isn't a 
valid skill there. I can enter it, but it's not standardized.
Permalink | Reply | 0 comments |
headers
Robert Jacques | 10 Feb 2012 06:48
Favicon
Gravatar

Re: std.uuid is ready for review

On Thu, 09 Feb 2012 03:57:21 -0600, Johannes Pfau <nospam <at> example.com> wrote:
> Thanks for your feedback! Comments below:
> Am Wed, 08 Feb 2012 23:40:14 -0600
> schrieb "Robert Jacques" <sandford <at> jhu.edu>:

[snip]

>> All the generators have the function name [name]UUID. Instead, make
>> these function static member functions inside UUID and remove the
>> UUID from the name. i.e. nilUUID -> UUID.nil randomUUID ->
>> UUID.random., etc. I'm not sure if you should also do this for
>> dnsNamespace, etc. (i.e. dnsNamespace -> UUID.dns) or not.
>
> UUID.nil makes sense and looks better. I don't have an opinion about
> the other functions, but struct as namespace vs free functions
> has always led to debates here, so I'm not sure if I should change it.
> I need some more feedback here first. (Also imho randomUUID() looks
> better than UUID.random(), but maybe that's just me)

Hmm... I'd agree that randomUUID reads better than UUID.random. IMO well named free-functions are
generally better than fake namespaces via structs. However, fake namespaces via structs a generally
better than fake namespaces via free-function naming convention (i.e. [function][namespace] or
[namespace][function]. That said, I think the bigger problem is that all these functions are
effectively constructors. I'd suspect that overloading UUID(...) would be a clearer expression of the
concepts involved. As for syntax, maybe something like: UUID(Flag!"random", ... ) to disambiguate when necessary.

[snip]

>>
>> There's an additional toString signature which should be supported.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Oliver Plow | 10 Feb 2012 08:02
Picon
Picon

Re: Message passing between threads: Java 4 times faster than D


> I recently completed a message passing library in D that lets the
> messages be passed between actors that don't necessarily correspond to
> threads (as std.concurrency requires). I'll see how it does on your
> benchmark.

Sounds quite interesting. You created some kind of thread pool for your library? Is this work "company
internal" or will it be published? Would be cool to have something like that for D.

Cheers, Oliver

--

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Permalink | Reply | 0 comments |
headers
Jacob Carlborg | 10 Feb 2012 09:00

Re: Mac OS X 10.5 support

On 2012-02-09 21:12, Sönke Ludwig wrote:
> Am 09.02.2012 17:20, schrieb Walter Bright:
>> On 2/9/2012 1:37 AM, Sönke Ludwig wrote:
>>> I have a project that we actually plan to use in production in the
>>> company for
>>> which I work. They still require 10.5 support for their products so
>>> removing
>>> that support would make for a very bad situation here.
>>>
>>> But it should be possible to get a 10.5 retail DVD and install it
>>> inside a VM..
>>> I actually planned to do exactly this to support 10.5 nightbuilds for
>>> my own D
>>> stuff.
>>>
>>> If support should be dropped anyway, are the issues only build-related
>>> so that
>>> e.g. gdc would still continue work on 10.5 without further work?
>>
>>
>> Would it also be possible for you to:
>>
>> 1. debug what has gone wrong with the 10.5 support? I'll be happy to
>> fold in any resulting patches.
>>
>> 2. provide a remote login shell so we can figure it out?
>>
>> 3. use git bisect to determine which change broke it?
>
> I will try and see if a regular retail version of 10.5 can somehow be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iain Buclaw | 10 Feb 2012 09:35
Favicon
Gravatar

Re: Mac OS X 10.5 support

On 9 February 2012 09:37, Sönke Ludwig <ludwig <at> informatik.uni-luebeck.de> wrote:
> Am 09.02.2012 04:52, schrieb Walter Bright:
>
>> Lately, dmd seems to have broken support for OS X 10.5. Supporting that
>> system is problematic for us, since we don't have 10.5 systems available
>> for dev/test.
>>
>> Currently, the build/test farm is OS X 10.7.
>>
>> I don't think this is like the Windows issue. Upgrading Windows is (for
>> me, anyway) a full day job. Upgrading OS X is inexpensive and relatively
>> painless, the least painless of any system newer than DOS that I've
>> experienced.
>>
>> Hence, is it worthwhile to continue support for 10.5? Can we officially
>> say that only 10.6+ is supported? Is there a significant 10.5 community
>> that eschews OS upgrades but still expects new apps?
>
>
> I have a project that we actually plan to use in production in the company
> for which I work. They still require 10.5 support for their products so
> removing that support would make for a very bad situation here.
>
> But it should be possible to get a 10.5 retail DVD and install it inside a
> VM.. I actually planned to do exactly this to support 10.5 nightbuilds for
> my own D stuff.
>
> If support should be dropped anyway, are the issues only build-related so
> that e.g. gdc would still continue work on 10.5 without further work?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane