Kalzium@avogadro

Hi

  1. Attached is a patch I needed in order to compile. If not applied I am
    getting

Primatives.cpp: In member function ‘void Avogadro::Molecule::render()’:
Primatives.cpp:61: error: ‘vector’ was not declared in this scope
Primatives.cpp:61: error: expected primary-expression before ‘*’ token
Primatives.cpp:61: error: expected primary-expression before ‘>’ token
Primatives.cpp:61: error: ‘::iterator’ has not been declared
Primatives.cpp:61: error: expected `;’ before 'i’
Primatives.cpp:64: error: ‘i’ was not declared in this scope

is there some kind of std-include missing?

  1. As it is a Qt4-application I think you should use QList and QVector
    instead of the stl-stuff. They have many advantages, including
    API-dox :wink:

  2. I subscribed to this mailinglist :slight_smile:

  3. Please remove all Makefile.am, config* files and so on. They keep me
    reminded of the bad-old autohell days :wink:

  4. We could try to move to CMake 2.4.3. I don’t think it would be to
    hard. I am of course willing to help here. I have already written the
    CMake-code to find Openbabel 2.1 and OpenGL :slight_smile:

  5. I am not sure if Capital letters in filenames are a good idea if we
    are going to publish on windows… FAT32 is not case-senstitive and many
    many apps don’t care about capital letters while others do. This can
    create all kinds of funny errors…

  6. Please consider to take as much as possible from Benoits code. We
    enable doxygen-generation, here are the two core classes:

http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdeedu-apidocs/kalzium/html/classKalziumGLWidget.html

http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdeedu-apidocs/kalzium/html/classKalziumGLHelpers_1_1VertexArray.html

If you ask me it would be totally stupid to develop Avogadro and
KalziumGLWidget. They have 99% the same purpose and therefore we have to
join forces! I will describe in short words what I want in Kalzium:

  • A 3D-renderer for molecules (95% done)
  • A 3D renderer for crystals (OpenBabel2 code missing (CIF,
    translation…)
  • A teaching tool (I am a chemistry teacher). I want to be able to
    points at three atoms and the app displays the angle between the three
    atoms. Or the torsion of four atoms.
  • Plane-display. That mean: The plane through 3 (or more) atoms. Really
    cool for molecules like the DNA (to show that there are many symmetries)
  • Autorotation
  • Displaying the names of the atoms, or the numbers (id’s) inside the
    widget

I guess that those things are also what you want?

How can we join forces? In case much of my and Benoits code moves into
Avogadro I have no problem with developing in Avogadro and copy code
before a KDE-release into Kalzium. Technically it would of course be
better to simply use a library or something like that, I don’t really
care. Long term, a lib is of course much better.
It would be a shame if you wouldn’t take Benoits and my code because it
took a lot of time to develop. But even that would be better than
developing two codebases, IMHO.

  1. APIDOX. There is not exactly a lot of Apidocs in the code. It would
    help me a lot if you would write short comments in the .h-file about
    what classes and methods are supposed to do.

  2. Benoit is currently writing “Eigen”, a highly optimized LGPL-math lib
    used in Kalzium for matrix-stuff and other things. I am sure avogadro
    could make great use of it. The code is in the KDE-svn (in
    trunk/kdesupport/eigen)

  3. http://sourceforge.net/mailarchive/message.php?msg_id=36484023
    should go in some kind of TODO, I think.

  4. Many of my idea about the 3D-viewer are in this file, you might want
    to read it:
    http://websvn.kde.org/trunk/KDE/kdeedu/kalzium/ideas/TODO?rev=565050&view=markup

Carsten

(Mon, Aug 21, 2006 at 10:48:44PM +0200) Carsten Niehaus cniehaus@gmx.de:

Hi

  1. Attached is a patch I needed in order to compile. If not applied I am
    getting

Primatives.cpp: In member function ‘void Avogadro::Molecule::render()’:
Primatives.cpp:61: error: ‘vector’ was not declared in this scope
Primatives.cpp:61: error: expected primary-expression before ‘*’ token
Primatives.cpp:61: error: expected primary-expression before ‘>’ token
Primatives.cpp:61: error: ‘::iterator’ has not been declared
Primatives.cpp:61: error: expected `;’ before 'i’
Primatives.cpp:64: error: ‘i’ was not declared in this scope

is there some kind of std-include missing?

probably i’ll have to look. this code is getting reworked today by me
so i’ll try to figure it out.

  1. As it is a Qt4-application I think you should use QList and QVector
    instead of the stl-stuff. They have many advantages, including
    API-dox :wink:

yeah, i don’t like stl that much but of course we have to use STL for
the OB stuff as that’s what it uses.

  1. I subscribed to this mailinglist :slight_smile:

sweet

  1. Please remove all Makefile.am, config* files and so on. They keep me
    reminded of the bad-old autohell days :wink:

that’s already done. re-check it out.

  1. We could try to move to CMake 2.4.3. I don’t think it would be to
    hard. I am of course willing to help here. I have already written the
    CMake-code to find Openbabel 2.1 and OpenGL :slight_smile:

haven’t looked at cmake. i’m fairly happy with qmake at the moment but
i’ll take a look at it.

  1. I am not sure if Capital letters in filenames are a good idea if we
    are going to publish on windows… FAT32 is not case-senstitive and many
    many apps don’t care about capital letters while others do. This can
    create all kinds of funny errors…

hrm.

  1. Please consider to take as much as possible from Benoits code. We
    enable doxygen-generation, here are the two core classes:

http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdeedu-apidocs/kalzium/html/classKalziumGLWidget.html

http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdeedu-apidocs/kalzium/html/classKalziumGLHelpers_1_1VertexArray.html

If you ask me it would be totally stupid to develop Avogadro and
KalziumGLWidget. They have 99% the same purpose and therefore we have to
join forces! I will describe in short words what I want in Kalzium:

  • A 3D-renderer for molecules (95% done)
  • A 3D renderer for crystals (OpenBabel2 code missing (CIF,
    translation…)
  • A teaching tool (I am a chemistry teacher). I want to be able to
    points at three atoms and the app displays the angle between the three
    atoms. Or the torsion of four atoms.
  • Plane-display. That mean: The plane through 3 (or more) atoms. Really
    cool for molecules like the DNA (to show that there are many symmetries)
  • Autorotation
  • Displaying the names of the atoms, or the numbers (id’s) inside the
    widget

I guess that those things are also what you want?

How can we join forces? In case much of my and Benoits code moves into
Avogadro I have no problem with developing in Avogadro and copy code
before a KDE-release into Kalzium. Technically it would of course be
better to simply use a library or something like that, I don’t really
care. Long term, a lib is of course much better.
It would be a shame if you wouldn’t take Benoits and my code because it
took a lot of time to develop. But even that would be better than
developing two codebases, IMHO.

i know that Geoff and I both agree that this is key; however the design
you guys have now is much different than we are using (at least at this
point) and in fact it’s so early we are still learning how we’re going
to develop the GL widget. While we want all of the features you list we
ALSO want a bunch more including the loadable modules etc etc. (which
seems to be at least partially implemented). But like i said; at least
for me developing right now is learning and figuring out what works,
while also developing for the future. I believe the end goal is to
eventually get our GLWidget as a library type thing that could then be
used in Kalzium.

I think what will eventually happen is that we’ll use bits of Benoits
code rather than just pulling what you have. I know for what i’ve done
so far i’ve pulled some bits from the code.

We avoided some of the work by using the gluSphere and gluCylinder
calls where Benoit actually subdivides the polygons.

  1. APIDOX. There is not exactly a lot of Apidocs in the code. It would
    help me a lot if you would write short comments in the .h-file about
    what classes and methods are supposed to do.

Yeah; lately it’s been more code less comment. :slight_smile:

  1. Benoit is currently writing “Eigen”, a highly optimized LGPL-math lib
    used in Kalzium for matrix-stuff and other things. I am sure avogadro
    could make great use of it. The code is in the KDE-svn (in
    trunk/kdesupport/eigen)

absolutely.

  1. http://sourceforge.net/mailarchive/message.php?msg_id=36484023
    should go in some kind of TODO, I think.

  2. Many of my idea about the 3D-viewer are in this file, you might want
    to read it:
    http://websvn.kde.org/trunk/KDE/kdeedu/kalzium/ideas/TODO?rev=565050&view=markup

will do

On Aug 21, 2006, at 4:48 PM, Carsten Niehaus wrote:

  1. As it is a Qt4-application I think you should use QList and QVector
    instead of the stl-stuff. They have many advantages, including
    API-dox :wink:

I won’t argue that some use of QList and QVector would be a good
idea, particularly since Qt4 includes implicit data sharing across
threads. But STL certainly has a lot of documentation too, e.g:

http://www.cppreference.com/index.html

  1. Please consider to take as much as possible from Benoits code. We
    enable doxygen-generation, here are the two core classes:

    If you ask me it would be totally stupid to develop Avogadro and
    KalziumGLWidget. They have 99% the same purpose and therefore we
    have to
    join forces! I will describe in short words what I want in Kalzium:
  • A 3D-renderer for molecules (95% done)
  • A 3D renderer for crystals (OpenBabel2 code missing (CIF,
    translation…)
  • A teaching tool (I am a chemistry teacher). I want to be able to
    points at three atoms and the app displays the angle between the three
    atoms. Or the torsion of four atoms.
  • Plane-display. That mean: The plane through 3 (or more) atoms.
    Really
    cool for molecules like the DNA (to show that there are many
    symmetries)
  • Autorotation
  • Displaying the names of the atoms, or the numbers (id’s) inside the
    widget

I guess that those things are also what you want?

Of course. As I’ve said a number of times, the base functionality
(i.e., viewing) is identical. Certainly it makes sense to merge efforts.

BTW, what’s missing for the 3D crystal rendering? CIF, certainly,
although there are other file formats. I want to make sure the Open
Babel TODO list is complete. :slight_smile:

Avogadro I have no problem with developing in Avogadro and copy code
before a KDE-release into Kalzium.

Actually, you shouldn’t need to do that. Subversion has the idea of
an external repository. So it could even be in the same repository –
and a KDE release just freezes a particular revision for Kalzium.

  1. APIDOX. There is not exactly a lot of Apidocs in the code. It would
    help me a lot if you would write short comments in the .h-file about
    what classes and methods are supposed to do.

Hopefully, Donald and I have expressed that we’re in the very early
stages of what we want to do. So we’ve been bad and have done some
hacking and prototyping and discussions. We haven’t documented much.
IMHO that’s partly because everything is in flux right now.

Quoting Donald:

I think what will eventually happen is that we’ll use bits of Benoit’s
code rather than just pulling what you have. I know for what i’ve
done
so far i’ve pulled some bits from the code.

The problem is mapping what Donald and I have in our head for the
architecture (i.e., plugin render code, plugin mouse tools) on top of
the existing Kalzium code. For example, the current code has switch/
case statements for particular rendering styles. Instead, we’ve
migrated that into separate classes.

Similarly, the intent is to send mouse events to external "tool"
classes (e.g., select, rotate, zoom, translate, draw, erase).

On the other hand, grabbing some of the “helper” classes would be great:

We avoided some of the work by using the gluSphere and gluCylinder
calls where Benoit actually subdivides the polygons.

If Benoit’s polygon code is faster and more memory efficient than
gluSphere or gluCylinder, then we should adopt that ASAP.

If any of this is unclear, I’ll try to get a design document online
tomorrow. Maybe I’ll throw that up as an Avogadro wiki so we can post
the TODO list too.

Cheers,
-Geoff

Am Montag, den 21.08.2006, 17:05 -0500 schrieb Donald Ephraim Curtis:

  1. Please remove all Makefile.am, config* files and so on. They keep
    me
    reminded of the bad-old autohell days :wink:

that’s already done. re-check it out.

You forgot src/Makefile.am

Carsten

Am Montag, den 21.08.2006, 17:05 -0500 schrieb Donald Ephraim Curtis:

  1. We could try to move to CMake 2.4.3. I don’t think it would be to
    hard. I am of course willing to help here. I have already written
    the
    CMake-code to find Openbabel 2.1 and OpenGL :slight_smile:

haven’t looked at cmake. i’m fairly happy with qmake at the moment but
i’ll take a look at it.

I thought about it… CMake is great, Scribus and KDE are now using it
and both are happy with it. But for a simple app like Avogadro qmake is
enough. With simple I mean: Only a few dependencies, easy dir-structure
and so on.
So don’t waste your time with CMake.

Carsten

Am Montag, den 21.08.2006, 18:39 -0400 schrieb Geoffrey Hutchison:

  1. Please consider to take as much as possible from Benoits code. We
    enable doxygen-generation, here are the two core classes:

    If you ask me it would be totally stupid to develop Avogadro and
    KalziumGLWidget. They have 99% the same purpose and therefore we
    have to
    join forces! I will describe in short words what I want in Kalzium:

Of course. As I’ve said a number of times, the base functionality
(i.e., viewing) is identical. Certainly it makes sense to merge efforts.

Ok, perfect. All code (Kalzium+avogadro) is GPL2 anyway.

BTW, what’s missing for the 3D crystal rendering? CIF, certainly,
although there are other file formats. I want to make sure the Open
Babel TODO list is complete. :slight_smile:

Beside CIF I am missing an easy way to do this (pseudo-code)

//create a blank UnitCell of Spacegroup 197
OBUnitCell * cell = new OBUnitCell( 197 );

//The cell contains 48 Mn-atoms (the 48 atoms are defined be the
spacegroup)
cell->SetAtomType( OBAtom( “Mn” ) );

/**

  • returns a compound of 101010 unitcells. This
  • compound (“molecule”) will be displayed in Kalzium and
  • Avogadro in this style:
  • http://kleinke.uwaterloo.ca/nacl.jpg
  • (the image is of course not a-Mn)
    */
    OBMolecule * mol = cell->GetCompound( 10, 10, 10 );

/** select some atoms in the “molecule” **/

/**

//for Spacegroup 197 return I-43m
QString spacegroupName = cell->GetSpaceGroupName();

//returns 197
int SGnumber = OBUnitCell::NumberOfSpaceGroup( “I-43m” )

Ok, the API should get better names, of course. I could code the
int->string and string->int code in OpenBabel2.1 today. Whould that be
ok? I now have a good list, the code is trivial, it just has to be done.
And I really think it belongs into OB2 and not Avogadro or Kalzium.

Avogadro I have no problem with developing in Avogadro and copy code
before a KDE-release into Kalzium.

Actually, you shouldn’t need to do that. Subversion has the idea of
an external repository. So it could even be in the same repository –
and a KDE release just freezes a particular revision for Kalzium.

Yes, I keep forgetting that svn is better then cvs :slight_smile: That should work.

Quoting Donald:

I think what will eventually happen is that we’ll use bits of Benoit’s
code rather than just pulling what you have. I know for what i’ve
done so far i’ve pulled some bits from the code.

The problem is mapping what Donald and I have in our head for the
architecture (i.e., plugin render code, plugin mouse tools) on top of
the existing Kalzium code. For example, the current code has switch/
case statements for particular rendering styles. Instead, we’ve
migrated that into separate classes.

Similarly, the intent is to send mouse events to external "tool"
classes (e.g., select, rotate, zoom, translate, draw, erase).

Benoit can comment much better here because he has done 98% of the
GL-classes.

On the other hand, grabbing some of the “helper” classes would be great:

We avoided some of the work by using the gluSphere and gluCylinder
calls where Benoit actually subdivides the polygons.

If Benoit’s polygon code is faster and more memory efficient than
gluSphere or gluCylinder, then we should adopt that ASAP.

Dito.

Carsten

I’d like to ask: if you ever use Eigen, do you need it to be thread-safe? Same
question for my helper classes.

I never cared about multithreaded programming, so I don’t even know exactly
what “thread-safe” means. I’d just like to know if I need to care about that
now.

On the other hand, grabbing some of the “helper” classes would be great:

We avoided some of the work by using the gluSphere and gluCylinder
calls where Benoit actually subdivides the polygons.

This is what I also did at the beginning, that’s good for a first draft. But
as you can see, the tesselation in gluSphere is quite naive, it has good
quality near the poles but poor quality near the equator, and obtaining high
quality everywhere requires to set a high number of slices & stacks, which
means a high number of triangles, which results in poor performance and, if
you compile that into a display list, higher memory usage.

If Benoit’s polygon code is faster and more memory efficient than
gluSphere or gluCylinder, then we should adopt that ASAP.

Already at the tesselation level:
gluSphere with 20 slices and 20 stacks: 400 quads or 800 triangles
my geosphere with m_detail==4: 320 triangles, yet more uniform (and IMHO
better) visual quality.

Note that if you can focus exclusively on target machines which have
hardware-accelerated programmable pixel shaders, the best way to render a
perfect-looking sphere is as a single quad rendered with a special
pixel/fragment program. That’s according to Brian Paul (main author of Mesa,
the OpenGL implementation), and he even sent me code to do that, so let me
know if you’re interested. For Kalzium, we can’t use it because it has to run
well on non-accelerated machines.

Benoit

Am Dienstag, den 22.08.2006, 11:41 +0200 schrieb Benoît Jacob:

Note that if you can focus exclusively on target machines which have
hardware-accelerated programmable pixel shaders, the best way to
render a perfect-looking sphere is as a single quad rendered with a
special pixel/fragment program. That’s according to Brian Paul (main
author of Mesa, the OpenGL implementation), and he even sent me code
to do that, so let me know if you’re interested. For Kalzium, we can’t
use it because it has to run well on non-accelerated machines.

To explain this: Many people still don’t have computers with 3D-hardware
(or with supported 3D on Linux/FreeBSD). For example, I don’t have
it :wink:
More importantly, a lot schools don’t have such computers as their
computers are age old and/or are not well maintained. So if you want to
see Av or Kalzium used in schools or on the OneLaptopPerChild-computer
you have to support MESA.

Carsten

(Tue, Aug 22, 2006 at 11:41:26AM +0200) Benoît Jacob jacob@math.jussieu.fr:

I’d like to ask: if you ever use Eigen, do you need it to be thread-safe? Same
question for my helper classes.

I never cared about multithreaded programming, so I don’t even know exactly
what “thread-safe” means. I’d just like to know if I need to care about that
now.

It just means that you run multiple operations simultaniously. In most
cases this doesn’t matter because in chem you’d actually have to define
the calculations in a distributed manner (ie. i have to calculate
something on 1000 elemnts of my database; think of the database like a
library with books (the elements). to make this threaded i instanciate
two processes all at one time or another checking a book out, running
the calculation on it and putting it “revised” back on the shelf. Now
if both processes attempt to take the book off the shelf at the same
time it can get messy. there are ways to set a mutex which basically
acts like a guard on the data letting the first person have access and
anyone else attempting to access the same data member gets held back
until the first person is done (released the mutex).)

That was my best; 6:15am english analogy.

I could be wrong on this but from what i remember; in QT they talk about
functions being thread safe if before they change any data they do
a lock on the QObject.

for a library to be thread safe it doesn’t work quite the same. I’m not
going to pass you an OBMol in one thread and then start changing the
same OBMol in another thread; that’s my irresponsibility not yours.
crossing a layer. i have to know that when i pass data to a library
function; i have no guaruntees what you’ll do with it.

but on that note i think eventually we’ll try threading. At least each
time we make a new window it should become it’s own thread; MainWindows
don’t share anything.

On the other hand, grabbing some of the “helper” classes would be great:

We avoided some of the work by using the gluSphere and gluCylinder
calls where Benoit actually subdivides the polygons.

This is what I also did at the beginning, that’s good for a first draft. But
as you can see, the tesselation in gluSphere is quite naive, it has good
quality near the poles but poor quality near the equator, and obtaining high
quality everywhere requires to set a high number of slices & stacks, which
means a high number of triangles, which results in poor performance and, if
you compile that into a display list, higher memory usage.

If Benoit’s polygon code is faster and more memory efficient than
gluSphere or gluCylinder, then we should adopt that ASAP.

Already at the tesselation level:
gluSphere with 20 slices and 20 stacks: 400 quads or 800 triangles
my geosphere with m_detail==4: 320 triangles, yet more uniform (and IMHO
better) visual quality.

We will need you. We’ll call it the Benoit line of rendering Engines
and they will be stronger and faster than all other rendering engines
available. We’re just not there yet.

-Donald

Am Dienstag, den 22.08.2006, 06:22 -0500 schrieb Donald Ephraim Curtis:

(Tue, Aug 22, 2006 at 11:41:26AM +0200) Benoît Jacob jacob@math.jussieu.fr:

but on that note i think eventually we’ll try threading. At least each
time we make a new window it should become it’s own thread; MainWindows
don’t share anything.

Yes. Did you ever open two KWords at the same time and one crashed? The
other also crashes because the share the same thread. This will be
changed in KOffice 2 :slight_smile:
So mainwindows really need their own thread IMHO.

Carsten

That was my best; 6:15am english analogy.

http://en.wikipedia.org/wiki/Thread_(computer_science)

very helpful, thank you!

I could be wrong on this but from what i remember; in QT they talk about
functions being thread safe if before they change any data they do
a lock on the QObject.

for a library to be thread safe it doesn’t work quite the same. I’m not
going to pass you an OBMol in one thread and then start changing the
same OBMol in another thread; that’s my irresponsibility not yours.
crossing a layer. i have to know that when i pass data to a library
function; i have no guaruntees what you’ll do with it.

yes but Eigen is worse than that: if you perform two matrix multiplications
simultaneously on different matrices, the result will be wrong, because the
operator*= uses a static member m_sharedMatrix in order to avoid dynamic
memory allocations. This means that there is no way at all that Eigen, in its
current state, could perform simultaneously two matrix multiplications. At
best, one could use a locking technique to force one matrix multiplication to
wait until the other one has finished. Which would guarantee correct results,
but would also mean lower performance on multi-CPU systems. How bad is that?

We will need you. We’ll call it the Benoit line of rendering Engines
and they will be stronger and faster than all other rendering engines
available. We’re just not there yet.

I feel sarcasm here :slight_smile:

Benoit

(Tue, Aug 22, 2006 at 02:39:43PM +0200) Benoît Jacob jacob@math.jussieu.fr:

yes but Eigen is worse than that: if you perform two matrix multiplications
simultaneously on different matrices, the result will be wrong, because the
operator*= uses a static member m_sharedMatrix in order to avoid dynamic
memory allocations. This means that there is no way at all that Eigen, in its
current state, could perform simultaneously two matrix multiplications. At
best, one could use a locking technique to force one matrix multiplication to
wait until the other one has finished. Which would guarantee correct results,
but would also mean lower performance on multi-CPU systems. How bad is that?

Pretty sure there isn’t any problem here. I mean, each instanciation of
a class will get it’s own m_sharedMatrix so it’s not a huge deal. It’s
up to me (in a multi-thread app) to know that i’m sending one matrix to
two different instances simultaniously. it would be hard for your
library to involve itself with that because you would have to know more
stuff about the incoming data: ie. the incoming matrices would have to
have some sort of mutex / lock attribute and that’s just hard.

anyways, i’m not worried.

We will need you. We’ll call it the Benoit line of rendering Engines
and they will be stronger and faster than all other rendering engines
available. We’re just not there yet.

I feel sarcasm here :slight_smile:

it wasn’t really. i mean, i was being a goof more than being sarcastic.
we will need your help (at least you seem to have a better grasp on 3d
geometry and stuff than Geoff or I). and i believe it will be badass.
i’d tell you to morph your code into a render engine but we haven’t
finalized the interface at all.

Le mardi 22 août 2006 19:59, Donald Ephraim Curtis a écrit :

(Tue, Aug 22, 2006 at 02:39:43PM +0200) Benoît Jacob
jacob@math.jussieu.fr:

yes but Eigen is worse than that: if you perform two matrix
multiplications simultaneously on different matrices, the result will be
wrong, because the operator*= uses a static member m_sharedMatrix in
order to avoid dynamic memory allocations. This means that there is no
way at all that Eigen, in its current state, could perform simultaneously
two matrix multiplications. At best, one could use a locking technique to
force one matrix multiplication to wait until the other one has finished.
Which would guarantee correct results, but would also mean lower
performance on multi-CPU systems. How bad is that?

Pretty sure there isn’t any problem here. I mean, each instanciation of
a class will get it’s own m_sharedMatrix so it’s not a huge deal.

Le mardi 22 août 2006 19:59, vous avez écrit :

(Tue, Aug 22, 2006 at 02:39:43PM +0200) Benoît Jacob
jacob@math.jussieu.fr:

yes but Eigen is worse than that: if you perform two matrix
multiplications simultaneously on different matrices, the result will be
wrong, because the operator*= uses a static member m_sharedMatrix in
order to avoid dynamic memory allocations. This means that there is no
way at all that Eigen, in its current state, could perform simultaneously
two matrix multiplications. At best, one could use a locking technique to
force one matrix multiplication to wait until the other one has finished.
Which would guarantee correct results, but would also mean lower
performance on multi-CPU systems. How bad is that?

Pretty sure there isn’t any problem here. I mean, each instanciation of
a class will get it’s own m_sharedMatrix so it’s not a huge deal.

nono, precisely! m_sharedMatrix is a static member, which means it’s the same
one that’s shared across all objects of my class. If I removed the static
keyword here, then indeed each matrix would have its own m_sharedMatrix, but
that’d result in twice more memory usage and many more dynamic memory
allocations. The whole point of m_sharedMatrix is that it’s shared.

To make that concrete, here’s the relevant part of my code:

first, the relevant part of my class declaration :

template
class KMatrixN
{

KMatrixN& operator *=(const T& factor);

unsigned int m_width;
unsigned int m_height;
unsigned int m_arraySize;
T *m_array;
static KMatrixN m_sharedMatrix;

};

and now, the code of the operator *=. Note that the resize method
only reallocates when necessary, i.e. if you shrink a matrix and then
restore its former size, no “new” or “delete” is done at all. This is
achieved using the m_arraySize member above. The result is that even if you
do 10^8 matrix multiplications on matrices of various sizes, only a very small
number (like 10) of “new” and “delete” are done. This does not only improve
performance, this is a necessity for intensive computation (on my linux
system, a program trying to do 10^8 new’s and delete’s aborts after about one
minute) :

template
KMatrixN& KMatrixN::operator *=(const KMatrixN & m)
{
// assert (width == m.height);

m_sharedMatrix.resize( m.m_width, m_height );

T *destptr = m_sharedMatrix.m_array;
T *colptr = m.m_array;
for (unsigned int col = 0; col < m_sharedMatrix.m_width; col++) {
    T *rowptr = m_array;
    for (unsigned int row = 0; row < m_sharedMatrix.m_height; row++) {
        *destptr = static_cast<T>(0);
        T *entry1ptr = colptr;
        T *entry2ptr = rowptr;
        for (unsigned int entry = 0; entry < m_width; entry++) {
            *destptr += (*entry1ptr) * (*entry2ptr);
            entry1ptr++;
            entry2ptr += m_height;
        }
        destptr++;
        rowptr++;
    }
    colptr += m.m_height;
}

*this = m_sharedMatrix;
return *this;

}

Le mardi 22 août 2006 21:40, vous avez écrit :

We will need you. We’ll call it the Benoit line of rendering Engines
and they will be stronger and faster than all other rendering engines
available. We’re just not there yet.

I feel sarcasm here :slight_smile:

it wasn’t really. i mean, i was being a goof more than being sarcastic.

no problem at all :slight_smile: