topic Re: Future ArchiCAD NEEDS multiprocessor code :( in Modeling

Future ArchiCAD NEEDS multiprocessor code :(

rm — Tue, 17 Jan 2006 20:34:53 GMT

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!

Re: Future ArchiCAD NEEDS multiprocessor code :(

TomWaltz — Tue, 17 Jan 2006 22:06:20 GMT

Amen, brother.

Re: Future ArchiCAD NEEDS multiprocessor code :(

Anonymous — Tue, 17 Jan 2006 22:34:41 GMT

i also encountered similar issues while developing a design for a 20 unit condo resort. i have what i would consider a robust machine, but not a workstation, in the classical definition. from what i understand, a lot of preview work in 3D is dependent on your GPU, or video card. i now have a 7800 GTX card for my PC. While it is robust, it is not a workstation card, and while i have never used or demo-ed a workstation card, everything i read tells me that these cards (ie. NVIDIA quadro FX) will make up the performance difference.

I do agree, that GS should be more transparent, and in fact actively promote serious solutions to users who want the BEST possible 3D performance hardware. Why won't GS list the NVIDIA and ATI card's performance on AC? Solidworks, 3DS Max, and the others have their standards. Why not AC?

Re: Future ArchiCAD NEEDS multiprocessor code :(

rm — Tue, 17 Jan 2006 23:11:55 GMT

LINZ,

In fairness to GS, listing performance of video cards with AC is almost irrelevant to most users.

What would be relevant would be optimized code, for multi-processing machines. The problem I described herein is a processing problem, not a video display problem. It has been explained to me that the actual calculation for the model occurs on the processor. The video card processes the image.

In my case, on less complex models, AC can process the model in shaded mode. We use substantial machines by anyones standard, and they far exceed the min. requirements on GS website.

Re: Future ArchiCAD NEEDS multiprocessor code :(

Anonymous — Wed, 18 Jan 2006 01:57:35 GMT

rm

i re-read your earlier submission. that explains why Artlantis R handles my larger models better than AC.

thanks for the revelation.

Re: Future ArchiCAD NEEDS multiprocessor code :(

ci-JoshOs — Wed, 18 Jan 2006 21:51:11 GMT

I think the reason that GS doesn't bother with any video card benchmarking is beacuse you can tell how fast a graphics card will be with archicad by its price. The more expensive, the better it will be(usually).

The OpenGL engine that ArchCAD uses is very basic compared to modern games that use all the GPU's functionality. For example, Nvidia's Geforce7800 uses version 3 pixel and vertex shaders, ultrashadow 2, HD mpg and wmv acceleration, and supports HDR lighting.
ArchiCAD uses none of these headline features. The ArchiCAD opengl view is about as complicated as Quake2. It doesn't even have antialiasing!

The only reason that your Graphics card gets pushed at all by AC, is because the models can get so massive. The GeForce 2 MX supports everything that ArchiCAD can throuw at it, its just too slow(old=slow). As a general rule, the speed of Graphics cards goes up as the price goes up. HalfLife 2 runs faster on ATI video cards than it does on Nvidia ones, but this is only beacuse of better optimised shaders etc.. which ArchiCAD doesn't care about.

If you want a nice fast video card for AC, opt for whatever the currently mid-range card is(a 6600 or an x700), and this will give you all the performance you need. If you don't use the 3D window much, or only ever draw smallish resdiential-type buildings, then the budget-line card will do quite nicely(6200 or x300). That said, i still use a trusty Geforce2 MX with 32Mb and i don't get too annoyed at it.

Re: Future ArchiCAD NEEDS multiprocessor code :(

stefan — Fri, 20 Jan 2006 08:22:45 GMT

You should not compare Games to CAD models:

Games are optimized a lot: pre-processed, low-polygon counts, massive object culling: what you don't see doesn't get processed; usually in small corridors, limiting the total amount of geometry to display.
The advanced shaders will eventually show up in CAD, one day or another, but not today. They are barely being integrated in 3D applications such as 3ds max and Maya, since these are the applications that are used to generate geometry for these games.

CAD-programs care less about visual appearance (e.g. anti-aliasing, advanced shaders) and more about displaying large amounts of geometry.

Professional workstation cards (the expensive Quadro and FireGL and similar) have certified drivers, more thorough stability testing and better support for Wireframes amongst others. For regular users, you can get along with any decent medium gaming card.

If you would export your complete ArchiCAD scene into a game engine, it would not be as fast as you would expect.

Sure, Half-Life 2 and Unreal and others display fairly complex scenes, but these are not CAD-levels. These are finetuned models, where every single polygon is thrown out that doesn't show up in the level.

-----------------------

I do believe Graphisoft should take advantage of all available CPU and Memory in the machine, regardless of it being a PC or a Mac or something in between...

Re: Future ArchiCAD NEEDS multiprocessor code :(

Anonymous — Fri, 20 Jan 2006 11:15:40 GMT

I want to know really. It is not joke...

Why do people buy Apple?

Re: Future ArchiCAD NEEDS multiprocessor code :(

stefan — Fri, 20 Jan 2006 11:18:50 GMT

samsung wrote:
I want to know really. It is not joke...

Why do people buy Apple?

This discussion is not about Apple vs. PC.
(And I'm afraid this kind of question doesn't lend itself to clean and civil discussions....)

ArchiCAD doesn't support multiple processors, neither on Mac OSX, neither on Windows.

Re: Future ArchiCAD NEEDS multiprocessor code :(

rm — Sat, 21 Jan 2006 20:36:14 GMT

stefan wrote:
This discussion is not about Apple vs. PC.
(And I'm afraid this kind of question doesn't lend itself to clean and civil discussions....)

ArchiCAD doesn't support multiple processors, neither on Mac OSX, neither on Windows.

Stefan,

Thank you for bringing the "discussion" back on track. Some people just can't seem to stay on topic. As you CLEARY state ARCHICAD DOESN'T support multiple processors on either platform..........THAT IS THE POINT Samsung!

Now hopefuly GS is reading this closer than some of the posters here.

Re: Future ArchiCAD NEEDS multiprocessor code :(

stefan — Sat, 21 Jan 2006 21:45:16 GMT

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.

Re: Future ArchiCAD NEEDS multiprocessor code :(

Thomas Holm — Sun, 22 Jan 2006 22:10:49 GMT

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.

Re: Future ArchiCAD NEEDS multiprocessor code :(

Rob — Mon, 23 Jan 2006 10:28:01 GMT

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...

Re: Future ArchiCAD NEEDS multiprocessor code :(

Anonymous — Wed, 01 Feb 2006 00:34:39 GMT

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...

Re: Future ArchiCAD NEEDS multiprocessor code :(

Anonymous — Tue, 14 Feb 2006 04:24:35 GMT

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.

Re: Future ArchiCAD NEEDS multiprocessor code :(

Rob — Tue, 14 Feb 2006 05:06:23 GMT

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.

Re: Future ArchiCAD NEEDS multiprocessor code :(

stefan — Tue, 14 Feb 2006 08:43:13 GMT

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.

Re: Future ArchiCAD NEEDS multiprocessor code :(

Thomas Holm — Tue, 14 Feb 2006 16:42:27 GMT

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

Re: Future ArchiCAD NEEDS multiprocessor code :(

stefan — Tue, 14 Feb 2006 18:16:35 GMT

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).