View mode: basic / threaded / horizontal-split · Log in · Help
December 13, 2012
Re: OT (partially): about promotion of integers
On 12/12/2012 5:51 PM, Timon Gehr wrote:
> A significant part of the D code is spent arranging data into the right layout,
> while the Haskell code does nothing like that.

So, please take the bait :-) and write a Haskell version that runs faster than 
the D one.
December 13, 2012
Re: OT (partially): about promotion of integers
On 12/12/2012 5:32 PM, bearophile wrote:
> One "important" firm uses OcaML for high speed trading because it's both very
> fast (C++-class fast, faster than Java on certain kinds of code, if well used)
> and apparently quite safer to use than C/C++. And it's harder to find OcaML
> programmers than C++ ones.

Fair enough, so I challenge you to write an Ocaml version of the input sorting 
program I presented in this thread in Haskell and D versions.
December 13, 2012
Re: OT (partially): about promotion of integers
On 12/12/2012 5:16 PM, Timon Gehr wrote:
> On 12/13/2012 12:43 AM, Walter Bright wrote:
>> On 12/12/2012 3:23 PM, Timon Gehr wrote:
>>> It is somewhat similar to (the still quite broken) 'pure' in D,
>>
>> Broken how?
>>
>
> - There is no way to specify that a delegate is strongly pure without resorting
> to type deduction, because

Are these in bugzilla?
December 13, 2012
Re: OT (partially): about promotion of integers
On Wednesday, 12 December 2012 at 21:05:05 UTC, Walter Bright 
wrote:
> On 12/12/2012 2:53 AM, foobar wrote:
>> One example that comes to mind is the
>> future version of JavaScript is implemented in ML.
>
> Um, there are many implementations of Javascript. In fact, I 
> have implemented it in both C++ and D.

Completely besides the point.
The discussion was about using ML in real life, not what you 
specifically chose to use. The fact that you use D has no baring 
on your own assertion that ML is effectively dead. Fact is _other 
people and organizations_ do use it to great effect.
Also, I said _future version_ of JS, meaning the next version of 
the ECMAscript standard. ML was specifically chosen as it allows 
to both be efficient and verify the correctness of the 
implementation.
December 13, 2012
Re: OT (partially): about promotion of integers
> it's both very fast (C++-class fast, faster than Java on 
> certain kinds of code, if well used) and apparently quite safer

Last I tried OCaml, "well used" in context of performance would 
mean avoiding many useful abstractions. One thing I remember is 
that using functors always has run time cost and I don't see why 
it should.
December 13, 2012
Re: OT (partially): about promotion of integers
On Wednesday, 12 December 2012 at 08:25:04 UTC, Han wrote:
> Walter Bright wrote:
>> Overlooked is the previous 10 years the band struggled in
>> obscurity.
>
> You KNOW that D has not been "overlooked". Developers and users 
> with
> applications give it a look (the former mostly) and then choose 
> something else.

Overlooked ? No. Using ? No. Disliked and abandoned ? No.

Quite a few times I've seen on the web people saying something 
like:
"D looks *really* nice, can't use it right now, but definitely 
keeping eye on it"

Same with myself. Keeping eye on it since mid-2010.


> Do you really think that D will ever have popularity to the 
> level of The Beatles?

From what I've seen so far, I'd say that's quite possible.


> Do you have a "Moses complex" (psychological) a little bit 
> maybe?

You do understand this doesn't add anything to the discussion, 
right ?
December 13, 2012
Re: OT (partially): about promotion of integers
On 12/13/2012 04:54 AM, Walter Bright wrote:
> On 12/12/2012 5:16 PM, Timon Gehr wrote:
>> On 12/13/2012 12:43 AM, Walter Bright wrote:
>>> On 12/12/2012 3:23 PM, Timon Gehr wrote:
>>>> It is somewhat similar to (the still quite broken) 'pure' in D,
>>>
>>> Broken how?
>>>
>>
>> - There is no way to specify that a delegate is strongly pure without
>> resorting
>> to type deduction, because
>
> Are these in bugzilla?
>

Now they certainly are.

http://d.puremagic.com/issues/show_bug.cgi?id=9148

The following you can close if you think 'const' should not guarantee no 
mutation. It does not break other parts of the type system:
http://d.puremagic.com/issues/show_bug.cgi?id=9149
December 13, 2012
Re: OT (partially): about promotion of integers
On Wednesday, 12 December 2012 at 20:01:43 UTC, Timon Gehr wrote:
> On 12/12/2012 03:45 AM, Walter Bright wrote:
>> On 12/11/2012 5:05 PM, bearophile wrote:
>>> Walter Bright:
>>>
>>>> ML has been around for 30-40 years, and has failed to catch 
>>>> on.
>>>
>>> OcaML, Haskell, F#, and so on are all languages derived more 
>>> or less
>>> directly
>>> from ML, that share many of its ideas. Has Haskell caught on? 
>>> :-)
>>
>> Haskell is the language that everyone loves to learn and talk 
>> about, and
>> few actually use.
>>
>> And it's significantly slower than D,
>
> (Sufficiently sane) languages are not slow or fast and I think 
> the factor GHC/DMD cannot be more than about 2 or 3 for roughly 
> equivalently written imperative code.
>
> Furthermore no D implementation has any kind of useful 
> performance for lazy functional style D code.
>
> In some ways, D is very significantly slower than Haskell. The 
> compilers optimize specific coding styles better than others.
>
>> in unfixable ways.
>>
>
> I disagree. That is certainly fixable. It is a mere QOI issue.

Actually, a factor of 2 to 3 can be huge. Consider that java is 
around a factor 2 or less to C++ in the Computer Languages 
Benchmark Game, and yet, you easily feel the difference everyday 
on your desktop applications.
But although the pure computation power is not very different, 
the real difference I believe lies the memory management, which 
is probably far less efficient in Java than in C++.
December 13, 2012
Re: OT (partially): about promotion of integers
On Thursday, 13 December 2012 at 01:32:23 UTC, bearophile wrote:
> Walter Bright:
>
>> Java makes no attempt to detect integer overflows.
>
> There are various kinds of code. In some kinds of programs you 
> want to be more sure that the result is correct, while other 
> kinds of programs this need is less strong.
>
>
>> I personally know people who write high speed trading 
>> software. These people are concerned with nanosecond delays. 
>> They write code in C++. They even hack on the compiler trying 
>> to get it to generate faster code.
>>
>> It doesn't surprise me a bit that some people who operate 
>> server farms use slow languages like Ruby, Python, and Perl on 
>> them. This does cost them money for extra hardware. There are 
>> always going to be businesses that have inefficient 
>> operations, poorly allocated resources, and who leave a lot of 
>> money on the table.
>
> One "important" firm uses OcaML for high speed trading because 
> it's both very fast (C++-class fast, faster than Java on 
> certain kinds of code, if well used) and apparently quite safer 
> to use than C/C++. And it's harder to find OcaML programmers 
> than C++ ones.
>
> Bye,
> bearophile


According to the Benchmark game, performance of Ocaml is good, 
but not fantstic. And certainly not "C++-class" fast. It's more 
like "Java-class" fast. (in fact it's slower than Java 7 on most 
tests, but uses much more memory).
Unfortunately, D hasn't been on the game for a long time, but 
last time it was, it was effectively faster than g++.

So really, we are not talking the same kind of performance here. 
D is likely to be MUCH faster than Ocaml.
December 13, 2012
Re: OT (partially): about promotion of integers
On Thursday, 13 December 2012 at 01:51:27 UTC, Timon Gehr wrote:
>
> Certainly, you can argue that the faster version should be in a 
> prominent place in the standard library, but the fact that it 
> is not does not indicate a fundamental performance problem in 
> the Haskell language. Also, note that I am completely ignoring 
> what kind of code is idiomatic in both languages. Fast Haskell 
> code often looks similar to C code.
>
Well, you can write C code in D.
You can compare top performance for both languages, but the fact 
is, if you write Haskell code extensively, you aren't going to 
write it like C, so comparing idiomatic Haskell vs idiomatic D 
does make sense. And comparing programs using the standard 
libraries also makes sense because that's how languages are used. 
It probably doesn't make much sense in a microbenchmark, but in a 
larger program it certainly does. And if the standard library is 
twice as slow in implementation A than in implemention B, then 
most programs will feel *at least* twice as slow, and usually 
more, because if you call a function f that's twice as slow in A 
than in B from another function that's also twice as slow in A 
than in B, then the whole thing is 4 times slower.
5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home