novice questions

#11 05-13-2008, 12:04 PM

It's also highly dependent on pipeline depth, fill, branch prediction,
compiler branch hints(few do this and many don't do it well), which
cache level it'

On May 13, 10:39 am, "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
> On May 13, 2:11 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
>
> > So in other words, either your object IS-A single precision
> > float or it IS-A double precision float?
>
> What about speed? If I use an ARRAY of objects that are derived from a
> single precision float, will it be as fast as an ARRAY of single
> precision floats (or float[] in C) ?
>
> Note: floating point arithmetic takes a few CPU ticks, dynamic
> dispatch and pointer dereferencing is 10-100 times slower.

#12 05-13-2008, 12:06 PM

It's in. I used to beat myself with chains and program in NASM/FASM
until I realized I was spending all my time optimizing and I never
finished my projects. I like the ability of Eiffel to break out in to
C is a very specific optimization is needed.

On May 13, 11:04 am, Colin LeMahieu <clemah...@gmail.com> wrote:
> It's also highly dependent on pipeline depth, fill, branch prediction,
> compiler branch hints(few do this and many don't do it well), which
> cache level it'
>
> On May 13, 10:39 am, "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
>
> > On May 13, 2:11 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> > wrote:
>
> > > So in other words, either your object IS-A single precision
> > > float or it IS-A double precision float?
>
> > What about speed? If I use an ARRAY of objects that are derived from a
> > single precision float, will it be as fast as an ARRAY of single
> > precision floats (or float[] in C) ?
>
> > Note: floating point arithmetic takes a few CPU ticks, dynamic
> > dispatch and pointer dereferencing is 10-100 times slower.

#13 05-13-2008, 12:37 PM

On May 13, 9:04 am, Colin LeMahieu <clemah...@gmail.com> wrote:
> It's also highly dependent on pipeline depth, fill, branch prediction,
> compiler branch hints(few do this and many don't do it well), which
> cache level it'

So what is the memory layout and inlining of operations of "ARRAY of
(IS-A REAL)". Is it similar to a C array of floats or an array of
pointers to floats, with extra indirection (v-table) for all methods?

#14 05-13-2008, 01:18 PM

ARRAY is backed by SPECIAL which is an unsizable memory block, a C
array. A finalized system would do direct calls on methods that
aren't redefined. I'm not sure what the exact inlining rules but the
compiler documentation say "Extensive inlining"

On May 13, 11:37 am, "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
> On May 13, 9:04 am, Colin LeMahieu <clemah...@gmail.com> wrote:
>
> > It's also highly dependent on pipeline depth, fill, branch prediction,
> > compiler branch hints(few do this and many don't do it well), which
> > cache level it'
>
> So what is the memory layout and inlining of operations of "ARRAY of
> (IS-A REAL)". Is it similar to a C array of floats or an array of
> pointers to floats, with extra indirection (v-table) for all methods?

#15 05-13-2008, 01:38 PM

An array of reals are contiguous floats. If you go through SPECIAL and
ask for the address of each item iteratively it will be the exact size
of a float.

On May 13, 11:37 am, "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
> On May 13, 9:04 am, Colin LeMahieu <clemah...@gmail.com> wrote:
>
> > It's also highly dependent on pipeline depth, fill, branch prediction,
> > compiler branch hints(few do this and many don't do it well), which
> > cache level it'
>
> So what is the memory layout and inlining of operations of "ARRAY of
> (IS-A REAL)". Is it similar to a C array of floats or an array of
> pointers to floats, with extra indirection (v-table) for all methods?

#16 05-13-2008, 08:12 PM

(top-posting fixed)

On May 13, 10:18 am, Colin LeMahieu <clemah...@gmail.com> wrote:
> On May 13, 11:37 am, "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
>
> > On May 13, 9:04 am, Colin LeMahieu <clemah...@gmail.com> wrote:
>
> > > It's also highly dependent on pipeline depth, fill, branch prediction,
> > > compiler branch hints(few do this and many don't do it well), which
> > > cache level it'
>
> > So what is the memory layout and inlining of operations of "ARRAY of
> > (IS-A REAL)". Is it similar to a C array of floats or an array of
> > pointers to floats, with extra indirection (v-table) for all methods?
> ARRAY is backed by SPECIAL which is an unsizable memory block, a C
> array. A finalized system would do direct calls on methods that
> aren't redefined. I'm not sure what the exact inlining rules but the
> compiler documentation say "Extensive inlining"

I'm sure it's a C array, but a C array of what: floats/double's or of
pointers to something?

Eiffel has DOUBLE. Suppose I *derive* from it, and call my class
MYFLOAT. Now I put MYFLOATs into a *resizable* ARRAY.

How would the bit-patterns encoding the actual values of adjacent
elements of the ARRAY lie with respect to each other:

a) 8-16 bits apart
b) other

#17 05-13-2008, 09:01 PM

jhc0033@gmail.com wrote:
> On May 13, 2:11 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
>
>> So in other words, either your object IS-A single precision
>> float or it IS-A double precision float?
>
> What about speed? If I use an ARRAY of objects that are derived from a
> single precision float, will it be as fast as an ARRAY of single
> precision floats (or float[] in C) ?

Unfortunately, REAL_32 etc. are expanded types.
In SmartEiffel there are no types derived from expanded types.
Results are good with generics, though, and can be expected
to be good as this is a purpose of generics. Pack your float
array algorithms in a class and make that class generic,
as suggested.

class MYSTUFF[F -> NUMERIC]

> Note: floating point arithmetic takes a few CPU ticks, dynamic
> dispatch and pointer dereferencing is 10-100 times slower.

Even in case of references, using the same specific derived type
may well yield static dispatch. The compiler may be able to prove
that there is no polymorphic reference.

#18 05-13-2008, 09:07 PM

jhc0033@gmail.com wrote:

> How would the bit-patterns encoding the actual values of adjacent
> elements of the ARRAY lie with respect to each other:

Eiffel not really being a (bare metal) systems programming language,
I guess you would be referred to the C interface. If that doesn't
give enough control of bit sizes or alignment, you can also break
out into Ada.

IIRC, a large Eiffel customer has joined Eiffel code and Fortran
code, so using C-style or Fortran-style arrays with Eiffel is
possible. There is a success story somewhere on ISE's marketing
shelf I think.

#19 05-22-2008, 02:16 PM

jhc0033@gmail.com ha scritto:
> Does Eiffel (SmartEiffel) have typedefs? I want to only have to change
> one line of code to go from single precision to double precision. Only
> using an alias to double/float accomplishes that. If Eiffel does not
> allow me to do something as trivial as that, doesn't it mean it fails
> one of its stated design goals (single-choice principle)?

Create a clusters containing empty features like this

In file my_project/settings_1/settings.e:
deferred class SETTINGS

feature
number: REAL_64 is do end
name: STRING is "Foo!"
end

In file my_project/settings_2/settings.e:
deferred class SETTINGS

feature
number: REAL_128 is do end
name: STRING is "Bar!"
end

then in your classes do

class MY_CLASS
insert SETTINGS
feature
command (a_number: like number) is
do
....
end
foo: like number
end

When you build your application either use cluster 1 or 2. It's that
simple AFAIK.
Paolo

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode