Re: Version after Version

On Sun, 30 Oct 2005 11:51:40 +0100, "Frank de Groot"
<franciad@xxxxxxxxx> wrote:

>"J French" <erewhon@xxxxxxxxxx> wrote

>> You appear to think that we should abandon the Delphi compiler and
>> find another one optimized for 64 bits.

>A. What does this have to do with the argument that 64-bits rewrites can
>make 32-bits software faster, as opposed to your argument that this is not
>true? Are you now saying that in fact you have been arguing that this is not
>true, merely because Delphi has no 64-bit compiler?

It will only make things faster if the compiled code explicitly tells
the processor to use 'enhanced' 64 bit features

You brought up MMX
- Google Definition: MMX and look at what it gives you

Basically an integral Multi Media co-processor - big deal

>B. Why on earth would I want you to abandon anything? What is my stake in
>YOUR compiler?

Oh, so I have to re-write everything in a new compiler, that will only
give me any benefits if I am doing things that benefit from a 64 bit
CPU - which is not that often

>C. What is the problem with Delphi not being 64-bit? Borland said last week
>again they are commited to making a 64-bit compiler, 2007 being the target.
>Why change when there is a commitment from Borland?

Yes, well, if I use Delphi 2007 and take up programming totally
different types of applications, then I might see a 64bit benefit

To see a benefit it kind of limits the type of Apps I can write ...

>> Processors only do what they are told to do, adding 57 new multi media
>> targeted instructions and increasing the size of the cache to 32,000
>> bytes and adding a glorified REP instruction will make code written
>> to take advantage of such novelties run faster
>> - simply because microcode runs faster than external code

>> That has nothing to do with the number of address lines on the CPU

You brought up MMX as an example - that is a description of MMX

>Who has been talking about adress lines? I was talking about the width of
>the DATABUS,

Gawd's sake, what do you think reads memory ?

>perhaps you are confused with someone else but it was I who has
>repeatedly said that the increased adressing range is **not very interesting
>or useful**, and I said that the big gain was in parallel execution of
>32-bit data in 64-bit registers. FYI, that means ** databus **. I can't know
>how old you are, I might be wasting my time with a 14 y.o. bored kid here.

As a point of fact I'm 49 years old
- you sound to me as if you are about 25
- I was probably coding before you were born

Do you know any ASM ?

>I assume that people only discuss topics they know something about, or want to
>learn about, not pushing some weird opinion without arguments and without
>listening to, or understanding arguments.

I'm certainly failing to understand what you think you are talking
about

>Blabbering about "microcode" is no argument. I say: instead of doing ten
>32-bit additions, do five time a 2 x 32 bit addition in a 64-bit register.

Heck, what do you think goes on inside a CPU ?
- the CPU is hard coded - guess what that hard coding is called

While a CPU might be given instructions to perform two 32 bit
additions on two adjacent DWORDs ... what on earth makes you think
that is going to do to speed things up ...

Adding what to what ?

>Because you load 64-bits at a time, add two 32-bits values at a time, and
>store the result 64-bits at a time, this goes twice as fast as on a 32-bits
>CPU, with a 32-bits program.

You've got me lost

Do you really think the CPU scouts through code looking for 32 bit
integers to add, when it finds things to add it then does batch
processing ?

What makes you think that code looks like :

ADD EAX, [ESI]
ADD EDX, [EDI]

>What's so hard to understand about this? Try it an measure it! If you are
>unable to, read a benchmark!

One heck of a lot is hard to understand.
You are rattling my eighteen years knowledge of Assembler

>> Anyway, most CPUs are choked by the speed of the bus

>Bull-***. Never heard of the concept of "cache"?

Yes, and do you know what 'branching is' ?

Do you know what the 80486 did with its cache when it encountered a
JMP instruction ?
Guess what 'branching' attempts to avoid ?

Guess why, in 95% of the cases it is a lost cause ?

Do you know what happens to the cache when it encounters a CALL ?

>Almost no application on
>earth is limited by the bus.

Next you'll tell me that disk drive speed is not the thing that chokes
the CPU after it has been choked by the bus

>If your application thrashes the L1 cache that
>much, then you should become a dog walker or a paper boy, you have no
>business being a programmer.

Yes, well, you probably know that Delphi does not allow us to use
inline Macros

You probably have not got the faintest idea of what goes on when you
write:
Self.Caption := 'Hullo World';

Before you start bragging about your knowledge,
1) spend a few years learning efficient high level coding
2) then a few more learning ASM
3) after that find out a bit about hardware

You seem to think that the CPU contains some sort of omniscient tooth
fairy that knows all about the future.

Just to convince me you know anything at all about CPUs, here is a
snippet from the Move procedure in the D4 Pro System.pas

Look at it carefully and tell me why it is extremely inefficient
(although elegant) code

If you can't then go find a dog, or some newspapers

(tip: rewrite the routine in pure Delphi and look at what the
optimizing compiler produces)

CMP EDI,ESI
JA @@down
JE @@exit

SAR ECX,2 { copy count DIV 4 dwords }
JS @@exit

REP MOVSD


.

Quantcast