Will ArchiCAD have a future?

[Anonymous]

the topic is a partly answer to Mac Pro or Vista for AC and driven by a pain i feel for years and yes, the topic is discussed over and over in this forum.

i don't understand what's the buzz here: "which from the top workstations would be better?"

NONE

i'm not with archicad from the very beginning, it think it was 6 or 6.5.
sure, every next version up to that point has been an improvement. like 7 to 8.1 or 8.1 to 10. anyway- every version was developed in name of TOOLS we use in managing the project- and here we see a small change in actual way how the architects think and create architecture (except for using software for creatting bubble-architecture, and even here the solution within ac is external- maxonform:). things have become better, but..
but i just don't see (am i blind?) that the ac has been developed in the means of hardware specs, thus giving room for these software tools to work smoothly and delivering top experience. macs & pcs has grown, emmm... SIGNIFICANTLY over last 8 years.
the marginal upgrade in tools isn't reflected in upgrade how ac works with your hardware. archaic code.
i just can't stand the attitude from GS here. i mean the lines "we have to revrite code. it's huge task". no doubt it is.
archicadwiki techsupport

• no multithreading
ok, they say it's "partly". why?

(..) ArchiCAD will not be a fully multi-threaded application at any time soon. This is partly because re-writing the ArchiCAD code to support multi-threading is a huge task, and there are areas where it would not cause a dramatic performance increase. Graphisoft will focus on the areas where multi-threading brings the most benefit.

thus you don't need octocore (or even quadro) mac pro "at any time soon", because it's a big job for them. (if i think that ac on 8 cores would use 1/8 of the resources available- ).
• max 4bg ram
well, and if more is in your system, it craches. you have to use the terminal to switch off the "unneeded" ram. ^£%^$£%$
• 32 bit
nuts

Transferring a 32-bit application to 64-bit requires reprogramming even the most basic functions in the software, therefore the change to 64-bit in business softwares will happen at a much slower pace than the rapid change from 32-bit processors to 64-bit processors in the Personal Computer (PC) industry.

so mainly they are basing the answer once again on excuse, that it requres recoding ac + on a bad market practise "aww, the other business software developers are also slow on this". sorry, but that doesn't apply to other apps i use, ie, c4d, maxwell. yes, they are a different profile, but- whatever harware resources i give them- it's been effectivelly used. and that's the reason they REALLY are top software solutions. and the argument that archicad has 100x more lines of code can't be an argument.

and with the upcoming ac11... they've spent another year on writing code which sooner or later must been rewritten. with the intoduction of windoze vista more and more consumers will upgrade to 64bit systems. mac users are there already (+leopard will also be a push to abandon old g4 boxes (multicore g5 pros are still more than great)).
graphisofts advertising and managment has been pretty good, but they now have to consider answers to "i got top vista pc/i got the new mac pro octocore, but my ac isn't getting faster".
they can choose to lie about ac beeing top level software.
they can choose to get more unsatisfied customers by telling true "yes, we have worked only on tools, forgetting about cpus, bits and rams".
they can choose to sit down and rewrite ac12 as multithreaded, 64 bit application, which would give them further enormous room for implementing top cpu&ram intensive tools. those who would still use 32bit computers will have their maximum ac11 version. if he GS says "we don't have that much programmers", then it's simple as it gets- AC DOESN'T HAVE FUTURE. it's a fact. like the latvian saying "ko nevar celt, to nevar nest"- you can't carry what you can't lift.

i hope someday new ac version wouldn't be a hotfix for the previous one.

i'm sorry if i touched some of GS staff personally. i understand that you work hard, but, in my opinion, only such critism would maybe produce not only thoughts about brighter future for all of us, but you will finaly sit down, say "ok, this is the point we stop. and open new page for starting to code the real future AC version. yes, we trash the 20 year old and so beloved code, but that's the only way we can do it". ACT, please, ACT NOW! and take your time, i can live with 32bit AC11 if you state that there will be ac12 after 1.5years costing more, because you had to pay more programmers. i will buy it and bring flowers.

[Andy Thomson]

Rob wrote:
finish half done features and then you can tune and rev up the engine to the latest and trendy binary digit

Ha do feat, what ar y talki abo? Whe?

[Rob]

do not get me wrong fellos, I would really like to enjoy all the benefits of multithreading and multicore kernel built on 64bit technology. I am just plainly frustrated to the boiling point with GS approach of guessing how it actually works in offices as oppose to doing hands-down research and analysis what is the essence, if you will, of a particular feature/tool.
If you are not sure about a feature/tool - ASK
If you are not sure what you are going to ask for -ASK what is the proper question to be asked

at the moment we've got a real problem with priorities:
1. BOSS prioritises efficiency, consistent and clear product (hardcopy), delivery and administration of the documentation. They make an ultimate decision about purchasing of newer AC versions.
2. PROJECT ARCHITECT is ultimately affected by the boss - deliver the product and you will be laughing. However, there is an element of putting up with odds and sods, workarounds and cranky staff refusing to understand the computer science logic, I do not blame them and it shits me a lot. AC automation is not actually automating the production process, what it automates is my rather colourful language when dealing with such issues.
3. JUNIOR ARCHITECTS & DRAFTING STAFF whinging about a non-standard approach that compromises their quality of work, frustrating error checking supposedly handled by automated process and more complicated structure of AC to achieve a really minor tasks.
4. NEW TRAINEES a disastrous perspective of the beast on a screen which is so complicated with so many exceptions to rules that makes them think why the hell I've got involved with those bloody architects after all.
5. and finally CAD MANAGERS/GDL GURUS who are in despair and horror in sort of out-of-box or new (supposedly advanced) release situations where almost everything has to be changed, upgraded, tweaked and fudged again (now in convenient 1-year cycle, how encouraging). And that is just because of lacking a clean and transparent concept behind almost any tool and/or feature.

now, let me think about this scary prospect…

and andyro do not take a piss... I will get your maple syrup banned from supermarkets

[Anonymous]

Hello Folks,

Yes, this is a very interesting thread. For sure multithreading is difficult to implement in a 3d / Drafting / or BIM program. As a separate issue, 64 bit nativity is less problematic.

At work my computer is 64bit / my OS is 64bit (XP64) / and my software is a mix of 32 & 64 bit. I run Revit, GSConstructor, ACAD as 32 bit software on a 64bit system. I also run LightWave 64 bit on this computer. My work computer has $1000 processor (Intel X6800), a half tank of RAM (4gig), and an NVIDIA 7950 GPU card. It cost $2600 US without the two monitors.

I had this ability at work for about 4 months and at home for more that 1 1/2 years. There is a huge difference in large model handling with 64bit software when compared to 32bit software. And I repeat: HUGE.

Crybabies on the NewTek forums complain that their computers slow down when displaying over 90 million polygons and GS writes a white paper saying that AC maxes out at 2.5 million polygons. I believe LightWave is only multithreaded when rendering. Maybe thats why it only costs $800 U.S.

In working for a general contractor, I obtain much use from a plain 'ole 3d model that has been extracted from the likes of GS or Autodesk software. Its not an goal of mine to do so. It comes from necessity.

Tnx for listening, many do not. 3d model manipulation is a necessity in my work. With very large construction models I will 'blow away' those that constrict themselves entirely to yesterday's software.

Riff Masteroff

[Anonymous]

I also have to admit that our models became more and more complex. Previously no one cared for moldings now it is a standard, full furnished home - as well. In construction - MEP models with nuts and washers, Steel structure with shanks, washers etc. Now I have like Core 2 Duo with 4 GB Ram Quadro 2500 card and I have to think about optimizing what I want to display. NavisWorks do its job much better in that area. Althoug I must admit that ADT or Revit suck in that area even more, but what kind of satisfaction it is to me? I have to work on those from time to time as well.

[Anonymous]

If most of these CAD apps never can take advantage of multiple cores, is it safe to say (since AMD/Intel are going multi-core rather than speeding up each core):

1. they will continually slow down as the programs grow OR

2. the vendors will have to stop adding features to avoid this slow down..

Is this too simplistic?... I currently use Chief Architect... from a thread over there on the topic........

64 bit is starting to float up on our priorities list. Version 11 will not ship with 64 bit support at it's release. A later release of 11 with 64 bit support may occur depending on need.

The real benefit of 64 bit comes when models start to exceed 2GB of memory usage. We have seen a couple of models that have that problem to date. The biggest issue is that most of those models are very slow because of the size.

For those that remember the performance jumps moving from 16 to 32 bit, that isn't happening this time around. In fact many 64 bit native applications are running slightly slower in 64 bit.

Dual Core is another area that is waiting for the hardware to catch up. We did some experimentation with supporting this and have found that the vast majority of Chief will not benefit from this until multiple core hardware is improved to have parallel paths to memory.

Dual cores today are being marketed as being potentially twice as fast, but the reality is that they provide very little performance improvement for the majority of applications and will continue to do so as long as memory access is shared between the cores.

We will migrate to 64 bit, and we will migrate to support multi-threading, however, this will likely not provide any great benefits in the near term.
__________________
Doug Park
Chief Architect, Inc.



So..... maybe supporting multiple thread of greater benefit than 64 bit? There are 64 bit apps out there that are just as slow as 32 bit.. Also seems those that write Chief don't see going 64 bit difficult at all....

[Rob]

thanks Rashid for posting this. it actually confirms my concerns about the maturity of 64bit systems in terms of OS vs hardware and whole conventional computer architecture.
I would not like to see GS jumping into quick conclusions in terms of major technological overhaul before sorting and/or consolidating the essential tools and workflow.

[Anonymous]

Like bad seasoning on meat... faster grill means faster bad meal...

It does question GS's adamant resistance to 64 bit/multi-threading/cores though.. a very simple explanation of the why's goes a long way to calming fears running rampant... I think the source of threads like this is you have to wonder what's so spooky those at GS don't even discuss it... therefore the worst is imagined..

For sure though some outfit out there WILL put the peices together someday and change the landscape..

[Anonymous]

I have to dissagree for multicores.
The preformance benifit would be huge in parts of the program that really need it. Especially section and elevation generation.

Shared memory modules have a slight penalty in preformance but the gains are more.

Writing code for multicores is not limited by number of cores. Today its two in a few months 4 in 2 years more than 16.

Does anyone feels that archicad would be multicore in 2 years?

[Anonymous]

Open GL implementation within a program is not simply on or off. It range from minimal to optimal.

In other words if a program's Open GL is not to good, then the user might blame the redraw slowness on lack of support for multi-core or not being 64bit enabled.

Riff Masteroff

[Anonymous]

I remember that in the early 90's I would pester the Graphisoft people at every annual ACS-fair in Frankfurt, Germany why AC would not have any filter tools. Their response was "Who needs that anyway?" And then in version 6.5 (I believe) they came out with a wonderful set of filters that permits the user to find just about every object by about any attribute imaginable.

I write that because I believe that inside GS there are some people keenly aware of what is going on in the industry and where their app might be lacking. However, a full 64-bit and multi-threading rewrite is not done in one afternoon. Do not expect them to admit any lacking in public until the day they have the solution market-ready.

Did you ever experience an airline to admit that the departure delay is due to a defective engine that needs replacement??? Yikes!!!