Slower than Python

Dmitry Olshansky dmitry.olsh at gmail.com
Sun Mar 3 01:10:24 PST 2013


03-Mar-2013 12:03, Russel Winder пишет:
> On Sat, 2013-03-02 at 12:52 -0800, Walter Bright wrote:
>> On 3/2/2013 12:08 PM, H. S. Teoh wrote:
>>> On Sat, Mar 02, 2013 at 12:02:08PM -0800, Walter Bright wrote:
>>>> On 3/2/2013 11:42 AM, Russel Winder wrote:
>>>>> On Sat, 2013-03-02 at 11:30 -0800, Walter Bright wrote:
>>>>>> On 3/2/2013 7:43 AM, Russel Winder wrote:
>>>>>>> For writing interpreters, RPython spanks C.
>>>>>>
>>>>>> What's RPython doing that makes it faster?
>>>>>
>>>>> Allowing PyPy to have a good JIT compiler.
>>>>
>>>> I don't understand. Does that JIT generate faster code than a C
>>>> compiler would generate?
>>>
>>> I don't know, but my wild guess is that a JIT optimizes the *right*
>>> hotspots based on real-time performance measurements, whereas a lot of C
>>> programmers are obsessed with optimizing what they *think* are the
>>> hotspots, but which really aren't.
>>
>> I meant what the C *compiler* generates.
>
> Yes because the C/C++/D/etc. compilers are attempting to predict the
> control flow of the program in execution and optimize all cases for all
> possibilities. JIT's are just focussing on the runtime bottlenecks with
> the actual data as being used. This allows for more focussed code
> generation in the actual context. I would suspect that in many cases the
> generated code is effectively the same but JITs can often do unexpected
> and faster codes because they have more data to optimize with and less
> optimization to do.
>

Only one thing missing here is that JITs typically has much less time to 
do all and any of this.

> To say more would require actual comparative data and I suspect no-one
> on this list will do that.
>
Indeed unlikely.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list