Future ArchiCAD NEEDS multiprocessor code :(

[rm]

This may or may not be relevant to you now, but within a year it most likely will, and if your office use Apple computers, it definitely will.

Let me start with the specs on our machines: Up to just a couple months ago we had Apples top flight towers: G5 dual processor 2.7ghz with 2.5 gigs of RAM operating OSX 10.4.2.

This week I personally learned something that stunned me ( guess I was in the dark ) about how a dual processor works relative to how it uses its RAM, at least on a Mac. Forgive me if I oversimplify this, on a Mac, each processor uses half of the installed RAM at any given time. That said I have essentially 1.25 gigs of RAM to operate AC 9.0 on a machine with TWO processors and TWICE the ram. Is it the fault of GS that Apple designed their technology this way........NO!!

Let me explain further, this week we were developing a PUD ( planned unit development ) that has approximately 12 single family homes modeled with furniture, interior lighting, and site with streets and a few cars. The AC model is less than 50mgs in size.

As I added more buildings, I would often check the entire 3D model using OpenGL shaded mode. Model 1 added, no problem; Model 2 added, no problem; Model 3 added, no problem >>>>model 7 added, slowing processing down; model 12 added - brings AC to its knees.......This is BULL$*&#$$. I use Apples fastest machines with ample RAM and I can't process this relatively small development model.

Then I realized that by checking Apples' Activity Monitor application, I could see how much real and virtual memory was being used during the processing of the AC model, or any other task for that matter. I saw the model in its current state max out the real available RAM. I decide to add 2 more gigs of RAM to the machine with this particular model knowing I will only get the benefit of 1 gig ( you must add RAM in pairs on a G5 - again Apples issue here ) and guess what, AC STILL coughs up a lung and dies trying to process the model. NOW I AM REALLY AGGRAVATED, and I decided to put a SOS call into GS tech support. Two days later I recieved an email from GS Tech instructing me to check my video card on my WINDOWS machine even-though my message was explicit about using MACS.....Thank GS for that helpful hint!!!

I decided to add 2 more gigs of RAM bringing the machine up to 6.5gigs!!! Process, process, process.........crap out again!!!!!! Switch the rendering engine to the AC engine, go to wire frame where I cannot check the model properly, and export to Artlantis R.

WHAT a JOKE!!!!!!

Long story short, all our projects we produce are heavily modeled and complex but usually one building at a time. GS has been silent about switching their code to multiprocessor capable......and Apple this week delivered its first two machines with the new Duo Core Intel processors.....of which all Apple products are changing to. I suspect we will see the PC vendors follow ( they usually do - sorry could not resist - oh yeah, I forgot Apple switched to Intel 😉 ) and switch to Duo Processor chips too. Bottom line, GS MUST change their code to take advantage of this computing power.

Many of you may or may not know this, but GS is currently making a big push to General Contractors to buy into BIM with their Constructor Software which is essentially AC with an integrated estimating program. As models and BIM are becoming less of a catch phrase to sell software and more of a reality, GS needs to offer software that can keep pace with the hardware.......they are way behind that curve currently.

Bottom line, for all you "power modelers" be you Mac or Window fans, you better start letting GS know that they need to get off the stick and start truly optimizing their software. If a 50 meg model on a fast machine with 6.5gigs of RAM can take down the machine, this will limit future acceptance of their BIM software.

BTW, Artlantis R takes advantage of both of the processors and up to eight processors in one machine. Rumors are that Apple will be delivering their next iteration of towers as a dual - Duo Core configuration which of course is 4 processors......how would you like to have that power in a box, and not be able to access it?!?!

In case you were wondering, we have hundreds of gigs of space on the hardrives too!

thanks for reading this!

[stefan]

AFAIK, the only multi-processor-capable part of ArchiCAD is the LightWorks rendering Add-on. This is surely a part of processing where this is required, but it would be welcomed in other parts as well (e.g. calculating sections or the plotmaker drawings in a seperate process).

Beware though that multi-threading and multiple processors are not the same thing! Multi-threading happens on single-processors too: different processes are processed on whatever amount of processors (pun intended)you have available: single, single hyper-threaded, dual, dual hyper-threaded etc...

To put things correct: we need more multithreading in ArchiCAD. The operating system will take care of spreading the work of the different threads over the available processors.

[Thomas Holm]

stefan wrote:
AFAIK, the only multi-processor-capable part of ArchiCAD is the LightWorks rendering Add-on. ...

Then this http://www.tgdaily.com/2006/01/20/the_coming_change_to_mac_software/ should be interesting to Graphisoft.

[Rob]

aaaahhh. support for multiprocessors is far beyond GS capabilities at the moment. they would have to rip the all guts out of the AC core and quite frankly with the speed they usually deliver their products...

anyway, it's an interesting debate so don't let it spoil with GS half-cooked solutions and let us dream for while...

[Anonymous]

Rob wrote:
aaaahhh. support for multiprocessors is far beyond GS capabilities at the moment. they would have to rip the all guts out of the AC core and quite frankly with the speed they usually deliver their products...

anyway, it's an interesting debate so don't let it spoil with GS half-cooked solutions and let us dream for while...

Although I would LOVE for GS to have support for all the latest CPU developments right now... (64 Bit, Hyperthreading, Dual Processors, and hell...even Dual Monitors would be great) Unfortunately, having worked for several software developers in the past I can tell you its not as simple as just ticking a box that says "compile for 64 bit", not to mention that they have to leave support for 32 bit there, and single processors, and then add on to that the fact that they have to support two seperate platforms.. .... it is a hell of a lot of work... and it will take time.... That said, I would hope they are along the road somewhat...

[Anonymous]

Further on the theme of this discussion, I propose that ArchiCAD would gain from not just MP implementation, but HPC implementation, and UNIX support. Admittedly, this is a supercomputing wishlist, but where bottlenecks appear, solutions exist. As much as this is a "What If...", it is a request for comment, and the chance to discuss, and refine, and decide on one (or maybe two or three) directions for making the best use of what computing has to offer.

Most of what I've said here applies to PC hardware, and I mention exceptions where relevent.


The State of MP computing

There is a limit to how much memory a single computer system workstation can use, dictated simply by motherboard architecture. MP motherboards usually have RAM banks for each processor, which is essential for good scaling of application performance. At the extreme, the Tyan S4880 Thunder, which supports up to four opteron 800 series processors, supports up to 20GB of RAM: 10 DDR [200-400] sockets- four for CPU 0, and two each for the other three. Performance is estimated, for opterons in a quad MP system to be in the 20-25 MTOPS.
For some perspective, an Opstone benchmark places by comparison, an Athlon 64 3000+ at a bit over 5 GFLOPS. A single opteron 800 series CPU delivers a PSSC labs benchmark of something like 3.5 GFLOPS.

This mainboard is not so expensive so as to prohibit serious consideration- if ArchiCAD could be guaranteed to fully employ the resources a system so equipped. Besides 4 CPUs, and an estimated 20K+ MTOPS in computational power,with memory sockets fully populated, the system's memory would actually support holding very large projects in RAM.

Further extending this approach of building a single system with as much processing power as reasonably possible, by incorporating specialised hardware using PCI-Express cards such as the Clearspeed Accelerator, which employs a purpose-built processor, 50GFLOPS of floating point power can be added to any PC. This is a serious option.

Compare this with the supercomputing cluster at Berkeley Structural Genomics Center- Physical Biosciences Division which employs 14 AMD Athlon MP 2200+ processors, has 14 GB aggregate memory, 876 GB shared disk storage, Gigabit Ethernet interconnect and will deliver an estimated 50 GFLOPS (theoretical peak performance).

The state of the Art High performance Computing

While MP systems deliver a lot in a single system, they are outpaced by parallel supercomputing clusters by several orders of magnitude., These distribute workloads from a central "workstation" node to the "slave" processing nodes, and reassemble the results at the workstation. Again, to fully appreciate the benefits, application code needs to support the message-passing protocols that these systems use to divide, synchronise and reassemble distributed tasks. Thankfully, programming toolkits are available to simplify this code conversion.

Well known examples of this type of system include the SETI@home project, which analyses data from the enormous Arecibo radio telescope, which is estimated to deliver around 100 TFLOPS. With around half a million nodes around the world, SETI@home has to date performed 10E+21 floating point operations, acknowledged by the Guinness Book of World Records as the largest computation in history.

Again, to give some perspective, the the Earth Simulator in Japan, the world's most powerful supercomputer, with 640 processors and 10TB of memory, delivers 40TFLOPS, but resides in it's entireity in the same building.


Now, (and here's where I draw GraphiSoft's attention) no-one yet using ArchiCAD has the number of nodes at their disposal that SETI@home includes to render architectural wireframes or scenes.

What is likely, however, is that users of ArchiCAD do have a few other systems in their workplace which spend a lot of time doing NOOPs. A Beowulf-style parallel computer would permit roughly proportional comping power scaling with each addition of a computing node. What distinguishes a Beowulf cluster is the use of devoted switchgear- ie., a network devoted to supporting the cluster. An example of a Beowulf-class supercomputer is the
Center for Atomic-Scale Materials Physics' VALHAL, with a peak speed of 168 GigaFLOPS with 144 DEC Alpha nodes running True64 UNIX.


A UNIX port

Adding UNIX-based support, to me, means supplying either: (1) source code so the user can compile the application specifically to make use of the hardware they have. If you're using a PIII then compile PIII optimised code- make sure it's using SSE and PAE and PIII MTRRs and don't try to use AMD-specific instructions. If it's an Athlon64, build 64 bit code, and use 3DNow and 3DNow!, and SSE2 and SSE3, etc. Alternatively, supply (2) all of these architecture-specific builds and let the user (or the installation program) pick the appropriate code. This dosen't specifically apply to UNIX-based systems; it applies to Microsoft, Sun, Linux-based or any operating system, but is more obvious to UNIX-based users (like me). Some people like to push their compilers to beyond the "officially supported" level ; ), so source code is unbeatable in these cases. Once a given set of compiler tuneables is found to succeed, these can be shared amoung other users. This is distributed computing at it's best.


Summary
If you had 4 PCs in your workplace with relatively new hardware- say around the 1 GFLOP mark- and a 100Mbit LAN, you could expect to add that computational power to your real processing task, without purchasing anything new, if ArchiCAD had UNIX support, and was coded to support message-passing protocols such as MPI.
Add to each system a Clearspeed Accelerator and you have a high-end supercomputer at your command. 4 such nodes each with 1GB of RAM would in theory deliver roughly 200+ GFLOPS, and because parallel computing architectures scale RAM as well as processor speed, this is probably what such a system would deliver. This is way more than most ArchiCAD users could ever saturate.

I would be eager to hear the interest there is in developing this type of support for adapting ArchiCAD. I would also be interested in assisting with adding message-passing protocol support to ArchiCAD. If anyone knows any more about Clearspeed's cards I'd be interested to hear what they thought as well.

[Rob]

Unifex, you're scaring me mate with all those flip-flops and giga-tera juggling.
I do not mind have a support for Unix or whatever but practicality of our (architectural) profession is that no one (at arch. office) really wants to get involved with new operating system and especially the maintenance of it.

[stefan]

Unifex,

I see that you are quite informed about these technical matters, but as I see from a practical (and commercial) point-of-view: Graphisoft has limited resources to keep a 20 year old program running on two platforms (well, three now if you consider Mactels a different platform from the regular Apples), using a whole set of custom tools for cross-platform develoment.

Opening sources and/or porting to UNIX/Linux are very unlikely, since they require quite a serious programming investment and little chance of selling more licenses.

If you need all this power for better rendering, then it's useless: it's far easier to add a cheap or less cheap dedicated rendering application.

If you need it for managing larger ArchiCAD models, which is usefull, then the whole program needs to be rewritten to take multi-threading into account. I don't see that happening.

[Thomas Holm]

Don't forget, Archicad already supports Unix. MacOSX is Unix. With a GUI.

[stefan]

Thomas wrote:
Don't forget, Archicad already supports Unix. MacOSX is Unix. With a GUI.

But Carbon and the OXS Platform SDK is definitively not standard UNIX, so it is not portable at all...

Yes, Mac OSX has a UNIX core, but with a large Platform-specific library AND a GUI (aqua).