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