Do everything in Java…

[John Colvin via Digitalmars-d]

On Monday, 8 December 2014 at 11:40:25 UTC, John Colvin wrote:
> 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.

sorry, f is a function not a delegate.