Do everything in Java…
John Colvin via Digitalmars-d
digitalmars-d at puremagic.com
Mon Dec 8 03:40:23 PST 2014
On Monday, 8 December 2014 at 11:02:21 UTC, Rene Zwanenburg wrote:
> On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
>> On Sunday, 7 December 2014 at 22:46:02 UTC, Dmitry Olshansky
>> wrote:
>>> 08-Dec-2014 01:38, John Colvin пишет:
>>>> On Sunday, 7 December 2014 at 22:13:50 UTC, Dmitry Olshansky
>>>> wrote:
>>>>> 08-Dec-2014 00:36, John Colvin пишет:
>>>>>> On Sunday, 7 December 2014 at 19:56:49 UTC, Dmitry
>>>>>> Olshansky wrote:
>>>>>>> 06-Dec-2014 18:33, H. S. Teoh via Digitalmars-d пишет:
>>>>>>>> On Sat, Dec 06, 2014 at 03:26:08PM +0000, Russel Winder
>>>>>>>> via
>>>>>>>> Digitalmars-d wrote:
>>>>>>>> [...]
>>>>>>>>>> primitive are passed by value; arrays and user defined
>>>>>>>>>> types are
>>>>>>>>>> passed by reference only (killing memory usage)
>>>>>>>>>
>>>>>>>>> Primitive types are scheduled for removal, leaving only
>>>>>>>>> reference
>>>>>>>>> types.
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> Whoa. So they're basically going to rely on JIT to
>>>>>>>> convert those boxed
>>>>>>>> Integers into hardware ints for performance?
>>>>>>>
>>>>>>> With great success.
>>>>>>>
>>>>>>>> Sounds like I will never
>>>>>>>> consider Java for computation-heavy tasks then...
>>>>>>>
>>>>>>> Interestingly working with JVM for the last 2 years the
>>>>>>> only problem
>>>>>>> I've found is memory usage overhead of collections and
>>>>>>> non-trivial
>>>>>>> objects. In my tests performance of simple numeric code
>>>>>>> was actually
>>>>>>> better with Scala (not even plain Java) then with D
>>>>>>> (LDC), for
>>>>>>> instance.
>>>>>>
>>>>>> Got an example? I'd be interested to see a numerical-code
>>>>>> example where
>>>>>> the JVM can beat the llvm/gcc backends on a real
>>>>>> calculation (even if
>>>>>> it's a small one).
>>>>>
>>>>> It was trivial Gaussian integration.
>>>>> http://en.wikipedia.org/wiki/Gaussian_quadrature
>>>>>
>>>>> I do not claim code is optimal or anything, but it's line
>>>>> for line.
>>>>>
>>>
>>> [snip]
>>>
>>>> on my machine (Haswell i5) I get scala as taking 1.6x as
>>>> long as the ldc
>>>> version.
>>>>
>>>> I don't know scala though, I compiled using -optimise, are
>>>> there other
>>>> arguments I should be using?
>>>
>>> There is no point in -optimise at least I do not recall using
>>> it.
>>> What's your JVM ? It should be Oracle's HotSpot not OpenJDK.
>>
>> hotspot.
>>
>> After changing the benchmark to more carefully measure the
>> integration function (ldc was unfairly taking advantage of
>> knowing a and b at compile-time), scala does indeed win by a
>> small margin.
>>
>> I wonder what it's managing to achieve here? AFAICT there
>> really isn't much scope for optimisation in that while loop
>> without breaking IEEE-754 guarantees.
>
> I don't think 'f' will be inlined in the D version. What
> happens if you make it an alias instead?
The delegate is inlined, after the whole integrate function is
inlined into timeIt.
More information about the Digitalmars-d
mailing list