dual xeon?

Discussion in 'Pro/Engineer & Creo Elements/Pro' started by pikki73, Mar 26, 2005.

  1. pikki73

    pikki73 Guest

    Hello, I would like to change my actual hardware configuration, PIII, with a
    dual xeon system (Nocona, socket 604).
    Can Pro/E (and Wildfire in particular) use these two CPU togheter?
    Will Pro/E be faster than a single cpu conf.?
    thanks

    pikki
     
    pikki73, Mar 26, 2005
    #1
  2. pikki73

    hamei Guest

    Earlier Pro/e's cannot but it looks as though Wildfire can.
    There's a setting in config.pro for 'number of processors'
    at any rate.


    Go to Olaf Corten's site and grab the test files. Run the
    computer both ways (exact same computer, just remove one
    cpu) and see what happens. I'd kinda like to know myself ...
    maybe here's an excuse to get that underpriced Origin 3400
    I keep seeing on eBay :)

    (My guess it that Wildfire only uses more cpu's for the
    rendering - since rendering is commonly done on many boxes
    behind the scenes, while it seems pretty unlikely that they
    rewrote the entire app to be thread-safe. Might be kewl if
    you like to leave that Live Rendering thingy turned on tho.)
     
    hamei, Mar 26, 2005
    #2
  3. Hello



    I'm using a double Xeon computer configuration myself for running Pro/E
    Wildfire 1. Wildfire is not capable to use dual processors, only rendering
    and regeneration of independent parts in an assembly (but I'm not sure about
    that) can gain some profit from dual CPUs. But there is one main advantage
    when dual CPUs are used. Even in case that Pro/E ceased to work (is not
    responding - hung up) or is fully occupying one CPU, the system is still
    fully responsible due to "free" second CPU.



    Jus my two cents



    Greetings



    Joze
     
    Joze BARBARIC, Mar 26, 2005
    #3
  4. pikki73

    Dan Richards Guest

    There are advantages to 2 CPUs, even though Pro-E doesn't of it's self
    utililize dual processors except for some functions such as video. For one
    thing you can assign one of the processors to run Pro-E and have a processor
    to run other things. Or one example I've run into recently, you can run an
    analysis program and still have a processor available to work on other
    things such as Pro-E while it is running.
     
    Dan Richards, Mar 27, 2005
    #4
  5. pikki73

    David Janes Guest

    Yes, it'll be faster than it would on a single cpu system. But nothing like
    double, maybe 25-30% faster. While I've heard that Pro/e isn't optimized for dual
    processor use, the system takes any multi-threaded application and parcels it's
    thread out in a way to keep both processor busy. What I've seen on a dual Xeon
    system is that both processors, when running Pro/e, stay about equally busy.
    Optimizing Pro/e for dual processors would probably achieve results that are more
    like parallel processing, but it might also not be the best thing for the system.
    It could, in fact, cause lockups that wouldn't happen otherwise when the system is
    deciding, chiefly, on the allocation of resources, allowing it, instead, to act as
    if it were the only program/processes/threads in the universe. This was always the
    biggest weakness of Windows systems, one that's somewhat gotten away from with NT.
    Brings to mind the expression: "Be careful what you wish for."
     
    David Janes, Mar 27, 2005
    #5
  6. pikki73

    hamei Guest

    What you're seeing then is that the system requirements are
    being run on one cpu while Pro/E uses the other. Actually,
    it's not that straightforward. A multi-tasking operating
    system does many tasks besides just running a single
    application. (DOS does not, which is what makes it actually
    superior to Win NT for machine control.) The kernel scheduler
    decides what to run and when. Under normal circumstances an
    application does not get to "just run." It's being interrupted
    all the time so that other computer services can also run. In
    Oonix the services are usually called daemons, but they exist
    in WinNT as well. With a single cpu Pro/E is being interrupted
    all the time so that whatever else you have going (do ctrl-alt-
    del in Win NT and then look at the running services) can ALSO
    get some cpu time.

    With two cpus those services don't need to interrupt pro/e's
    time. HOW the time is apportioned is up to the operating
    system's scheduler. OS/2 uses a round-robin approach - as
    tasks come up to be operated upon they are stacked in a
    queue. As soon as one task has finished on any cpu, the next
    is sent to that cpu in a round-robin fashion. This ensures
    that the cpu's are kept full. How NT does scheduling I don't
    know, but it's not as efficient as OS/2 :) Tests years ago
    showed two-cpu OS/2 servers whupping 4-cpu NT boxes by a
    large margin. That was my experience with NT as well - it's
    actually pretty shitty at smp. Irix is probably the best of
    anybody - they have the unique ability to scale a single
    image of the operating system (not clusters, which is a bunch
    of separate boxes co-operating rather than a single large box)
    over something like a thousand cpus. If they couldn't do this
    they would be dead meat because today they have nothing else
    to offer. In fact, with their stock price dropping to where
    they are in danger of being delisted again, it surprises me
    that Sun hasn't just gobbled them up for that one capability.

    Effing imbecile management :-(


    No, not at all. It isn't a matter of "optimizing" at all.
    You have to go back into history a little bit here ...
    obviously the first computers only had a single cpu. Hey,
    gotta walk before you can run, right ? When people tried
    to make a computer more powerful, what can you do ? Either
    take the cpu you have and redesign it to run faster or how
    about add another ? IF the application you are trying to
    accomplish is amenable to multiple small chunks ( think
    this way - serving ten thousand hits to a web page can
    be broken into small pieces where twenty cpu's can each
    handle x number, while streaming one continuous video can't
    really be apportioned to a bunch of separate cpus ) THEN
    smp makes good sense. For DOS smp would be stupid. A real
    multi-tasking os doesn't necessarily mean that the user
    is simultaneously running PhotoShop and Pro/E. It means
    that you can be doing one thing while the os is also
    running an ftp server in the background, burning a CD,
    etc etc. You can see where smp would be great for this.
    Now instead of one DOS box (Windows 98) you have several
    under one controller.

    This is the level where you're seeing 20-30% improvements
    in Pro/E performance - because it's not being interrupted
    by other tasks.

    NEXT step is for the application itself to be written to
    utilize more than one cpu. Many tasks that you wouldn't
    think would profit from smp really *can* - for instance,
    opening the app requires drawing the splash screen, drawing
    a window, then filling the window, reading your config.pro
    file, setting up resources, blablabla. Each task *could*
    go to a separate thread rather than running them sequentially.
    Each thread then gets assigned to a cpu by the operating
    system, as they come up for processing. Boom ! NOW you got
    an smp-friendly app. The kewl thing about threads is that
    the same program can run on a single-cpu box or one with
    sixteen. On multi-cpu hardware as a thread comes up for
    processing it goes to the necxt processor. If you only
    have one, it waits. If you have 32, it goes to the first
    vacant spot. There is an obvious limit to this tho - when
    the overhead of scheduling tasks takes more time than
    *doing* the tasks, you've now gone backwards. That's why
    sometimes you cna see an aplication run *slower* in smp
    than on a single-cpu machine. Btw, here is where Unix
    initially fell down - tasks can be split into processes or
    threads. Processes take longer to create. Threads are faster
    but not as safe. You can see where if one thread is reading
    a file then modifying it while another thread comes along
    to ALSO read that file and use it, if thread A has modified
    it but thread B doesn't know about that and writes its OWN
    modifications to the file you could end up with Big Trouble.
    So apps which actually USE smp features have to be coded
    to be thread-safe. And tested, as well :) Unix initially
    didn't like threads but now they have "pthreads" which is
    the same as threads on NT or OS/2 ... anyway ...

    Pretty gross generalizations here but you get the idea.
    There are many ways to deal with smp but overall, ANY
    single-threaded app (such as Pro/E) will see *some*
    benefit from running on a dual cpu machine. (In case
    you get excited by the concept, more than two for a
    desktop seems to make no difference whatsoever. I ran
    a Netfinity with four cpu's for a while to play and
    saw no improvement at all for desktop apps beyond two
    cpu's.) An app which is written specifically to *use*
    smp can see improvements more on the order of 80% or
    so. I've done benchmark tests that showed an almost
    linear improvement with math functions, but you couldn't
    even *touch* the machine while they were running or you
    lost your big-number benchmark :)

    It would be kewl if Pro/E were multi-threaded. Then
    you'd see more significant performance improvements
    running on your smp box ... but the code is old and
    rewriting it to please the small percentage of people
    who have an smp machine can't sound too exciting to
    PTC. Before you blast PTC for that, I don't think any
    of the other cadcam apps are multi-threaded either.
    Mastercam, Smurfcam, SaladWurx certainly are not.
    VX, probably not. Instead of doing something trick like
    that, they spent their money changing to Windows and
    drawing new icons. Probably gives them a better r.o.i.,
    but sheesh :( Maya is somewhat smp-friendly. I-DEAS,
    don't know but it's about the only manufacturing app
    that is as nice as Pro/E ... in fact, maybe nicer. It
    *may* be smp-friendly but it's pretty unlikely. The only
    commercial people I've seen who are *very* careful about
    threads are in the OS/2 world and that's kind of a
    byproduct of a failing in OS/2. Due to a problem with
    OS/2's input queue, anything non-tricial that is *not*
    multi-threaded and thread-safe can lock up the desktop.
    Then the users will come to your house and kill you so
    OS/2 developers end up with some of the best-performing,
    most co-operative apps on the planet, more out of necessity
    than anything else. Every cloud has a silver lining :)
     
    hamei, Mar 28, 2005
    #6
  7. pikki73

    clintonyee Guest

    According to this, one might interpet VX as being multi-threaded.
    "There were many goals in developing what has become UPG2," says Mike
    Crown, the director of Product Development at Varimetrix, "First and
    foremost was to develop a kernel that had seamless integration between
    solids and surfaces, where users could work between the two types of
    entities and perform various functions-all the time without having to
    first think about if an element is a surface or a solid or convert from
    one to the other."

    UPG2 uses what is known as a Proximity Compliant Tolerance Scheme to
    selectively heal geometry on the fly, allowing for what Crown calls
    "the fastest, most reliable geometry engine in the industry."
    Essentially UPG2 is healing the model incrementally whenever necessary,
    such as when two surfaces are intersected. This allows UPG2 to deal
    with non-native data, regardless of its origin.

    Another issue was performance, part of which was achieved by building a
    multithreaded kernel. Even without multiprocessors, Varimetrix wanted
    the kernel to have excellent speed when dealing with freeform surfaces.
     
    clintonyee, Mar 28, 2005
    #7
  8. pikki73

    hamei Guest

    Ah. That would indicate smp-friendly. Only way to know for
    sure would to run a process-watching progam while VX was
    running. There are several for OS/2, I'm sure Windows has
    some as well.

    I always thought Varimetrix was kewl and Mike Crown was no
    slouch. Too bad they went over to the Dark Side :-(

    Good to know, thanks.
     
    hamei, Mar 28, 2005
    #8
  9. pikki73

    clintonyee Guest

    By the darkside do you mean over to the Windows platform?

    I believe VX was originally designed for UNIX workstations. Perhaps
    that is why the kernel was designed to be multithreaded from the
    beginning.
     
    clintonyee, Mar 28, 2005
    #9
  10. pikki73

    hamei Guest


    Yes, if you see version 4 or so around, it's a really nice-looking
    Irix app. Ran on other Unices as well, of course.

    Nowadays it looks like a child's toybox :-( Stinking icon-mania.
    We spent years learning to read in school, now we're supposed to
    point and say "ga ! ga ! want !" or decipher what the sketch of
    the nun with the arrow thru her head stands for ?
    Okay, I much prefer Unix to that crap from Redmond but in this
    case, OS/2 and Windows were way ahead of Unix. OS/2 in particular -
    Windows stayed stuck in DOS mode until very recently, when they
    finally discovered that Windows 98 et al were poop. Strange how
    M$ can sell people on the most wonderfullest thing since sliced
    bread this week, only to turn around next week and say that was
    crap, now y'all have to buy *this* most wonderfullest thing !
    and y'all go for it ... sad. But I digress .... OS/2 and Winick
    were threading proponents while Unix was in love with processes.
    Forking a process takes a lot of overhead. It's slow. Spinning
    off another thread is fast and much finer-grained. Unix has come
    around to that with pthreads now but in the beginning the Intel
    users were ahead on this one. Wonder what Acorn and Amiga and
    those did ?
     
    hamei, Mar 29, 2005
    #10
  11. pikki73

    jon banquer Guest

    Mike Crown thought very little of Pro/E and how restrictive it was.

    He did like UG, though.

    Are you using VX ?

    jon
     
    jon banquer, Mar 29, 2005
    #11
  12. pikki73

    jon banquer Guest

    This article, IMO, was one of the top three that Joe Greco ever wrote.
    One of the most interesting things about this article to me was what Mike
    Crown had to say about what the next big thing would be in CAD.

    http://cadence.advanstar.com/1999/1199/issuefocus1199.html

    "Crown was excited about what he sees in the future-a whole new type
    of modeling called Partition. While he was sketchy with the details, the
    basic concept is that it will take hybrid modeling to an even higher level
    and make it easy to model even extremely complex shapes, by interactively
    providing the user with many more shape definition and modification
    options."

    Think3 calls it Global Shape Modeling. They also have something called
    Zone Modeling which I need a better understanding of. VX calls it
    "Morphing".

    IMO, thinkID has better tools in this area than what I have seen in any
    other modeler and a better UI to go with it.

    You can decide for yourself as I have upload a Camtasia video
    that shows a very complex model being build start to finish.

    IP address - 63.173.39.175
    Login - cnczone
    Password - cadcam (note: password is case sensitive)
    Port - 21
    Max users - 3

    The file is in a folder named:

    Jon Banquer

    The file is called:

    snowshoe english.avi

    This .avi file was done in a screen capture product called Camtasia.
    IMO, Camtasia videos look horrible played in Windows Media Player.
    The Camtasia Player is free and one can read about it compared to
    Windows Media Player here:

    http://www.techsmith.com/products/studio/player.asp


    The following are tips on how to work with Camtasia Player that
    should make viewing this video more enjoyable:


    Play / Pause: spacebar

    Rewind: PageUp

    Forward: PageDown

    Full Screen: alt+enter

    Years from now we will know that Mike Crown was dead nuts on.... just like
    he was about why someone needs hybrid modeling and why a CAD modeler is
    much better off being built hybrid from the start. He though SolidWorks
    would have a tough time adding surfacing functionality on top of the
    Parasolid kernel.. man was he ever right about that !!!

    I believe VX has actually built 3 kernels over the years.

    jon
     
    jon banquer, Mar 30, 2005
    #12
  13. pikki73

    clintonyee Guest

    jon,
    If you were doing design to prototype (stl) output (no cnc).

    What would you get:
    VX or ThinkiD

    Thanks!
     
    clintonyee, Mar 30, 2005
    #13
  14. pikki73

    jon banquer Guest

    ?

    VX has had their own integrated CAM since the very beginning
    ..... thru 5 axis simultanious mill.

    In any case, I hope more Pro/E users will consider VX CAD/CAM
    as it's fast, a joy to use and very robust.

    VX is also a very nice company to do business with.... something
    you don't hear about PTC. :>)

    jon
     
    jon banquer, Mar 31, 2005
    #14
  15. pikki73

    clintonyee Guest

    I will not be doing any cnc at all.

    But I assume you you pick VX over ThinkiD. Correct?
     
    clintonyee, Mar 31, 2005
    #15
  16. pikki73

    jon banquer Guest

    I like thinkID's technology for GSM and for it's UI....
    the rest I prefer VX.

    thinkID's solid operations are not as good as VX.

    VX's kernel is very robust.... very.

    jon
     
    jon banquer, Mar 31, 2005
    #16
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.