zxo102 ouyang | 5 Mar 07:02
Picon

How to upgrade addBinFinite.py from simpy1.8 to simpy2.0?

Hi all,
    I have downloaded the program at
  http://simpy.sourceforge.net/boundedbuffer.htm
    It works in the environment of simpy1.8. But when I try to run it under simpy2.0, I got an error message:

addBinFinite.py, line 59, in simulate
    if Sim._e == None:
AttributeError: 'module' object has no attribute '_e'

   Anybody knows how to solve this problem?

Thanks for your help in advance.

ouyang

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Simpy-users mailing list
Simpy-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simpy-users
Klaus Müller | 7 Mar 07:26
Picon
Picon
Favicon

Re: How to upgrade addBinFinite.py from simpy1.8 tosimpy2.0?

Hi Ouyang,
you are right, that script is out of date and no longer works with SimPy 2.0. I will repair it and come back to you.
 
Klaus Muller
(SimPy Lead Developer)
 
PS :The 'Bin' construct is implemented as the 'Level' in SimPy 2.0, of course.

From: zxo102 ouyang [mailto:zxo102 <at> gmail.com]
Sent: Donnerstag, 5. März 2009 07:03
To: simpy-users <at> lists.sourceforge.net
Subject: [Simpy-users] How to upgrade addBinFinite.py from simpy1.8 tosimpy2.0?

Hi all,
    I have downloaded the program at
  http://simpy.sourceforge.net/boundedbuffer.htm
    It works in the environment of simpy1.8. But when I try to run it under simpy2.0, I got an error message:

addBinFinite.py, line 59, in simulate
    if Sim._e == None:
AttributeError: 'module' object has no attribute '_e'

   Anybody knows how to solve this problem?

Thanks for your help in advance.

ouyang

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Simpy-users mailing list
Simpy-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simpy-users
Gautam Thaker | 12 Mar 18:50
Favicon

should I use Python 2.6.x or Python 3.0.x?

Hi:

I have extensive experience w/ simulation technologies but am new to python 
and SimPy. Should I start w/ python v2 or v3? I would like to start w/ the 
latest version so i don't have to learn 2 variants (i understand python 
changed a good bit going from v2 to v3.)

Are there any speed comparison studies for SimPy? If I can I will try to 
compare a simple simulation (as much apples to apples as I can) w/ 
www.mesquite.com 's CSIM engine that I am familiar with. CSIM uses some 
special hacks to manipulate C/C++ stack and its process support is very fast 
and cheap.

Thanks - looks like good work, I can't wait to get started.

Gautam

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Harriv | 12 Mar 19:30
Picon

Re: should I use Python 2.6.x or Python 3.0.x?

On Thu, Mar 12, 2009 at 7:50 PM, Gautam Thaker <gautam.h.thaker <at> lmco.com> wrote:
> Hi:
>
> I have extensive experience w/ simulation technologies but am new to python
> and SimPy. Should I start w/ python v2 or v3? I would like to start w/ the
> latest version so i don't have to learn 2 variants (i understand python
> changed a good bit going from v2 to v3.)

 From release announcement of SimPy 2.0:

SimPy 2.0 requires Python 2.3 or later. It does not yet run under Python
3.0.
The release of a SimPy version for Python 3.0 is planned for later in 2009.

 So I suggest you go with Python 2.5 or 2.6. Python 2.5 seems to still
have be wider support by 3rd party libraries.

> Are there any speed comparison studies for SimPy? If I can I will try to
> compare a simple simulation (as much apples to apples as I can) w/
> www.mesquite.com 's CSIM engine that I am familiar with. CSIM uses some
> special hacks to manipulate C/C++ stack and its process support is very fast
> and cheap.

>
> Thanks - looks like good work, I can't wait to get started.
>
> Gautam
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Simpy-users mailing list
> Simpy-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simpy-users
>

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Gautam Thaker | 13 Mar 03:45
Picon

relative slow speed of SimPy execution..

I write a lot of simulations, and I need to run many of them for hours and 
hours. Thus, the base efficiency of the simulation engine matters a great deal 
to me. I just learned about SimPy today, and decided to give it a go. I am 
able to run the "bank" examples and I modified the bank08.py to run for 
100,000 customer arrivals. I eliminated all printfs; the program took

23 seconds to run using SimPy

I then ran the same "/M/M/1" system (again w/ 100,000 arrivals) based on 
www.mesquite.com's CSIM simulation env. CSIM is very old and seems very 
similar to SimPy, it provides the "process" abstraction.  The same basic 
amount of work took:

0.26 seconds to run using CSIM v19.

Thus, the run time ratio is about 100:1. I have attached both the programs as 
well as output from CSIM program, in case of interest.

SimPy looks very promising, but something either I am doing wrong or this much 
efficiency is too much to give up.

Comments?

Gautam
            C++/CSIM Simulation Report (Version 19.1 for Linux x86)

                                  M/M/1 Queue

                           Thu Mar 12 22:42:02 2009

                     Ending simulation time:   1192396.201
                     Elapsed simulation time:  1192396.201
                     CPU time used (seconds):        0.250

FACILITY SUMMARY 

facility     service    service          through-    queue     response   compl
name           disc      time    util.     put       length      time     count
--------------------------------------------------------------------------------
facility     fcfs       9.99739  0.838    0.08386    5.47438   65.27635   100000

TABLE 1:  resp tms

      minimum         0.000463          mean                   65.276348
      maximum       694.352128          variance             5140.753024
      range         694.351665          standard deviation     71.699045
      observations      100000          coefficient of var      1.098392

QTABLE 1:  num in sys

      initial       0      minimum       0      mean                    5.474384
      final         0      maximum      56      variance               42.258465
      entries  100000      range        56      standard deviation      6.500651
      exits    100000                           coeff of variation      1.187467

                                             cumulative
        number    total time    proportion   proportion

             0   192656.91183     0.161571     0.161571   ******************  
             1   160203.46487     0.134354     0.295925   ***************     
             2   134077.66485     0.112444     0.408369   *************       
             3   113543.70852     0.095223     0.503592   ***********         
             4   94977.81825     0.079653     0.583245   *********           
             5   78717.04430     0.066016     0.649261   *******             
             6   66516.75458     0.055784     0.705045   ******              
             7   55090.95031     0.046202     0.751247   *****               
             8   45696.63312     0.038323     0.789571   ****                
             9   38585.32541     0.032359     0.821930   ****                
 >=         10   212329.92487     0.178070     1.000000   ********************


			M/M/1 Theoretical Results

		Inter-arrival time =     12.000
		Service time       =     10.000
		Utilization        =      0.833
		Throughput rate    =      0.083
		Mn nbr at queue    =      5.000
		Mn queue length    =      4.167
		Response time      =     60.000
		Time in queue      =     50.000
CSIM MODEL STATISTICS

CPU time used (sec):         0.250 
Events processed:           383983 
Memory allocated:            34060 bytes 
Calls to malloc:               138 
Processes 
     Started:               100001 
     Saved:                 229699 
     Terminated:            100000 
     High water mark:           57 
Stacks 
     Allocated:             100001 
     High water mark:         2284 words 
     Average:                   40 words 
     Maximum:                   44 words 
     Current:                   44 words 

Attachment (ex1cpp.cpp): text/x-c++src, 1908 bytes
Attachment (bank08.py): text/x-python, 1838 bytes
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Simpy-users mailing list
Simpy-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simpy-users
Klaus Müller | 13 Mar 06:28
Picon
Picon
Favicon

Re: should I use Python 2.6.x or Python 3.0.x?

Hi Gautam,
SimPy 2.0 is not compatible with Python 3.So, just use Python 2.5 or 2.6. 
The syntactic differences between Python 2.x and Python 3 are not very big, 
so there should be no big problem moving to Python 3 later.

Python 3 is just not ready for production use. It misses too many libraries. 
Although I have translated the core code of SimPy to Python 3, I cannot 
release a Python 3 version. The Python developers dropped the Canvas library 
in 3.0, and that means I can't offer the plotting library SimPlot which 
comes with SimPy.

The alternative of using Matplotlib for plotting does not exist, either. 
Matplotlib depends on numpy, and that won't be ready for Python 3 for a long 
time.

No, there are no speed comparison studies for SimPy. Don't expect SimPy to 
be a speed monster. SimPy, like Python, is great for fast dvevelopment, but 
does not offer the speed of a pure C/C++ system.

Regards,

Klaus Muller
(Lead Developer of SimPy)

----- Original Message ----- 
From: "Gautam Thaker" <gautam.h.thaker <at> lmco.com>
To: <simpy-users <at> lists.sourceforge.net>
Sent: Thursday, March 12, 2009 6:50 PM
Subject: [Simpy-users] should I use Python 2.6.x or Python 3.0.x?

> Hi:
>
> I have extensive experience w/ simulation technologies but am new to 
> python
> and SimPy. Should I start w/ python v2 or v3? I would like to start w/ the
> latest version so i don't have to learn 2 variants (i understand python
> changed a good bit going from v2 to v3.)
>
> Are there any speed comparison studies for SimPy? If I can I will try to
> compare a simple simulation (as much apples to apples as I can) w/
> www.mesquite.com 's CSIM engine that I am familiar with. CSIM uses some
> special hacks to manipulate C/C++ stack and its process support is very 
> fast
> and cheap.
>
> Thanks - looks like good work, I can't wait to get started.
>
> Gautam
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Simpy-users mailing list
> Simpy-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simpy-users
> 

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Harriv | 13 Mar 09:51
Picon

Re: relative slow speed of SimPy execution..

 I think your results are on expected. Standard Python is implemented
as bytecode interpreter, so anything written in Python and executed
under standard implementation is inheritably slower than compiled
code. Python code instead should be more cleaner and compact than
C/C++.

 1/100 speed seems possible result based on language shootout results:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=icc&lang2=python&box=1

 If speed is need under Python, the default solution is to implement
the critical part of system in native code and create interface for it
in Python.

On Fri, Mar 13, 2009 at 4:45 AM, Gautam Thaker <gthaker <at> comcast.net> wrote:
> I write a lot of simulations, and I need to run many of them for hours and
> hours. Thus, the base efficiency of the simulation engine matters a great
> deal to me. I just learned about SimPy today, and decided to give it a go. I
> am able to run the "bank" examples and I modified the bank08.py to run for
> 100,000 customer arrivals. I eliminated all printfs; the program took
>
> 23 seconds to run using SimPy
>
> I then ran the same "/M/M/1" system (again w/ 100,000 arrivals) based on
> www.mesquite.com's CSIM simulation env. CSIM is very old and seems very
> similar to SimPy, it provides the "process" abstraction.  The same basic
> amount of work took:
>
> 0.26 seconds to run using CSIM v19.
>
> Thus, the run time ratio is about 100:1. I have attached both the programs
> as well as output from CSIM program, in case of interest.
>
> SimPy looks very promising, but something either I am doing wrong or this
> much efficiency is too much to give up.
>
> Comments?
>
> Gautam
>
>            C++/CSIM Simulation Report (Version 19.1 for Linux x86)
>
>                                  M/M/1 Queue
>
>                           Thu Mar 12 22:42:02 2009
>
>
>                     Ending simulation time:   1192396.201
>                     Elapsed simulation time:  1192396.201
>                     CPU time used (seconds):        0.250
>
>
> FACILITY SUMMARY
>
> facility     service    service          through-    queue     response
> compl
> name           disc      time    util.     put       length      time
> count
> --------------------------------------------------------------------------------
> facility     fcfs       9.99739  0.838    0.08386    5.47438   65.27635
> 100000
>
>
>
> TABLE 1:  resp tms
>
>      minimum         0.000463          mean                   65.276348
>      maximum       694.352128          variance             5140.753024
>      range         694.351665          standard deviation     71.699045
>      observations      100000          coefficient of var      1.098392
>
> QTABLE 1:  num in sys
>
>      initial       0      minimum       0      mean
>  5.474384
>      final         0      maximum      56      variance
> 42.258465
>      entries  100000      range        56      standard deviation
>  6.500651
>      exits    100000                           coeff of variation
>  1.187467
>
>                                             cumulative
>        number    total time    proportion   proportion
>
>             0   192656.91183     0.161571     0.161571   ******************
>             1   160203.46487     0.134354     0.295925   ***************
>             2   134077.66485     0.112444     0.408369   *************
>             3   113543.70852     0.095223     0.503592   ***********
>             4   94977.81825     0.079653     0.583245   *********
>             5   78717.04430     0.066016     0.649261   *******
>             6   66516.75458     0.055784     0.705045   ******
>             7   55090.95031     0.046202     0.751247   *****
>             8   45696.63312     0.038323     0.789571   ****
>             9   38585.32541     0.032359     0.821930   ****
>  >=         10   212329.92487     0.178070     1.000000
> ********************
>
>
>
>
>                        M/M/1 Theoretical Results
>
>
>                Inter-arrival time =     12.000
>                Service time       =     10.000
>                Utilization        =      0.833
>                Throughput rate    =      0.083
>                Mn nbr at queue    =      5.000
>                Mn queue length    =      4.167
>                Response time      =     60.000
>                Time in queue      =     50.000
> CSIM MODEL STATISTICS
>
> CPU time used (sec):         0.250
> Events processed:           383983
> Memory allocated:            34060 bytes
> Calls to malloc:               138
> Processes
>     Started:               100001
>     Saved:                 229699
>     Terminated:            100000
>     High water mark:           57
> Stacks
>     Allocated:             100001
>     High water mark:         2284 words
>     Average:                   40 words
>     Maximum:                   44 words
>     Current:                   44 words
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Simpy-users mailing list
> Simpy-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simpy-users
>
>

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Stefan Scherfke | 13 Mar 10:20
Picon

Re: relative slow speed of SimPy execution..

You can get much more performance if you use ParallelPython (pp)  
combined
with SimPy. It allows you to distribute your Simulation over all cores  
of
your CPU and over as many other computers in your LAN as you wish. I  
think
the documentation for SimPy 2.0 contains a few examples for that. PP/ 
SimPy
scales nearly linear with the number of cores/computers.

regards,
Stefan

Am 2009-03-13 um 09:51 schrieb Harriv:

> I think your results are on expected. Standard Python is implemented
> as bytecode interpreter, so anything written in Python and executed
> under standard implementation is inheritably slower than compiled
> code. Python code instead should be more cleaner and compact than
> C/C++.
>
> 1/100 speed seems possible result based on language shootout results:
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=icc&lang2=python&box=1
>
> If speed is need under Python, the default solution is to implement
> the critical part of system in native code and create interface for it
> in Python.
>
> On Fri, Mar 13, 2009 at 4:45 AM, Gautam Thaker <gthaker <at> comcast.net>  
> wrote:
>> I write a lot of simulations, and I need to run many of them for  
>> hours and
>> hours. Thus, the base efficiency of the simulation engine matters a  
>> great
>> deal to me. I just learned about SimPy today, and decided to give  
>> it a go. I
>> am able to run the "bank" examples and I modified the bank08.py to  
>> run for
>> 100,000 customer arrivals. I eliminated all printfs; the program took
>>
>> 23 seconds to run using SimPy
>>
>> I then ran the same "/M/M/1" system (again w/ 100,000 arrivals)  
>> based on
>> www.mesquite.com's CSIM simulation env. CSIM is very old and seems  
>> very
>> similar to SimPy, it provides the "process" abstraction.  The same  
>> basic
>> amount of work took:
>>
>> 0.26 seconds to run using CSIM v19.
>>
>> Thus, the run time ratio is about 100:1. I have attached both the  
>> programs
>> as well as output from CSIM program, in case of interest.
>>
>> SimPy looks very promising, but something either I am doing wrong  
>> or this
>> much efficiency is too much to give up.
>>
>> Comments?
>>
>> Gautam
>>
>>            C++/CSIM Simulation Report (Version 19.1 for Linux x86)
>>
>>                                  M/M/1 Queue
>>
>>                           Thu Mar 12 22:42:02 2009
>>
>>
>>                     Ending simulation time:   1192396.201
>>                     Elapsed simulation time:  1192396.201
>>                     CPU time used (seconds):        0.250
>>
>>
>> FACILITY SUMMARY
>>
>> facility     service    service          through-    queue      
>> response
>> compl
>> name           disc      time    util.     put       length      time
>> count
>> --------------------------------------------------------------------------------
>> facility     fcfs       9.99739  0.838    0.08386    5.47438    
>> 65.27635
>> 100000
>>
>>
>>
>> TABLE 1:  resp tms
>>
>>      minimum         0.000463          mean                    
>> 65.276348
>>      maximum       694.352128          variance              
>> 5140.753024
>>      range         694.351665          standard deviation      
>> 71.699045
>>      observations      100000          coefficient of var       
>> 1.098392
>>
>> QTABLE 1:  num in sys
>>
>>      initial       0      minimum       0      mean
>>  5.474384
>>      final         0      maximum      56      variance
>> 42.258465
>>      entries  100000      range        56      standard deviation
>>  6.500651
>>      exits    100000                           coeff of variation
>>  1.187467
>>
>>                                             cumulative
>>        number    total time    proportion   proportion
>>
>>             0   192656.91183     0.161571     0.161571    
>> ******************
>>             1   160203.46487     0.134354     0.295925    
>> ***************
>>             2   134077.66485     0.112444     0.408369    
>> *************
>>             3   113543.70852     0.095223     0.503592   ***********
>>             4   94977.81825     0.079653     0.583245   *********
>>             5   78717.04430     0.066016     0.649261   *******
>>             6   66516.75458     0.055784     0.705045   ******
>>             7   55090.95031     0.046202     0.751247   *****
>>             8   45696.63312     0.038323     0.789571   ****
>>             9   38585.32541     0.032359     0.821930   ****
>>  >=         10   212329.92487     0.178070     1.000000
>> ********************
>>
>>
>>
>>
>>                        M/M/1 Theoretical Results
>>
>>
>>                Inter-arrival time =     12.000
>>                Service time       =     10.000
>>                Utilization        =      0.833
>>                Throughput rate    =      0.083
>>                Mn nbr at queue    =      5.000
>>                Mn queue length    =      4.167
>>                Response time      =     60.000
>>                Time in queue      =     50.000
>> CSIM MODEL STATISTICS
>>
>> CPU time used (sec):         0.250
>> Events processed:           383983
>> Memory allocated:            34060 bytes
>> Calls to malloc:               138
>> Processes
>>     Started:               100001
>>     Saved:                 229699
>>     Terminated:            100000
>>     High water mark:           57
>> Stacks
>>     Allocated:             100001
>>     High water mark:         2284 words
>>     Average:                   40 words
>>     Maximum:                   44 words
>>     Current:                   44 words
>>
>>
>> ------------------------------------------------------------------------------
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
>> are
>> powering Web 2.0 with engaging, cross-platform capabilities.  
>> Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
>> development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> _______________________________________________
>> Simpy-users mailing list
>> Simpy-users <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/simpy-users
>>
>>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
> are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly  
> and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
> development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Simpy-users mailing list
> Simpy-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simpy-users
>

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Gautam Thaker | 13 Mar 14:15
Picon

Re: relative slow speed of SimPy execution..

Stefan Scherfke wrote:
> You can get much more performance if you use ParallelPython (pp)  
> combined
> with SimPy. It allows you to distribute your Simulation over all cores  
> of
> your CPU and over as many other computers in your LAN as you wish. I  
> think
> the documentation for SimPy 2.0 contains a few examples for that. PP/ 
> SimPy
> scales nearly linear with the number of cores/computers.
> 
> regards,
> Stefan

I have to try this (ParallePython) out, but w/ discrete event simulation isn't 
there is a single  event queue that can't really be parallelized? Much work 
was done in 80s and 90s on "optimistic" executation and roll back etc but the 
actual speed ups, as I recall, were much less than linear except in rare cases 
where there is truly lots of parallel work between simulation events....

Are there any published results on how well SimPy does w/ PP?

Gautam

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Gautam Thaker | 13 Mar 14:40
Picon

Re: relative slow speed of SimPy execution..

Harriv wrote:
>  I think your results are on expected. Standard Python is implemented
> as bytecode interpreter, so anything written in Python and executed
> under standard implementation is inheritably slower than compiled
> code. Python code instead should be more cleaner and compact than
> C/C++.
> 
>  1/100 speed seems possible result based on language shootout results:
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=icc&lang2=python&box=1
> 
>  If speed is need under Python, the default solution is to implement
> the critical part of system in native code and create interface for it
> in Python.

Well, I am not sure if it is possible to do *ANYTHING* to make bank08.py run 
much faster, but if it can be done to close the ~ 100:1 gap it would be good. 
I don't know what from that little program can be implemented in native code 
(C?) where it would make a difference (unless you are saying parts of SimPy 
itself, possibly its co-routine support) can be drastically improved.

In industry we find that we must *RUN* our simulations, in many cases, for so 
so many combinations of parameters etc. At least I find it hard to give up 
this much speed for  a bit of compactness in code and may be some elegance. I 
recall the hey days of Lisp Machines, code compactness and neatness was some 
of the argument there as well, but in the end runtimes speeds (and cost) did 
matter I believe.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

Gmane