Open galenseilis opened 10 months ago
Oh interesting, looks like it doesn't like my c extensions (but did at some time in the past?). I have some ideas on how to fix it. When I get some time, I'll take a look. Hopefully I'll be able to report back by Tuesday morning.
As an aside, did you change your gcc compiler between when you tried this before and now? Did your PyPy version change?
Oh interesting, looks like it doesn't like my c extensions (but did at some time in the past?). I have some ideas on how to fix it. When I get some time, I'll take a look. Hopefully I'll be able to report back by Tuesday morning.
As an aside, did you change your gcc compiler between when you tried this before and now? Did your PyPy version change?
I would appreciate you looking further into supporting PyPy if you have time. :)
Unfortunately I did not keep notes or a versioned project. It was just a miscellaneous script. But here is the current state in my venv.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
$ pypy3 --version
Python 3.8.13 (7.3.9+dfsg-1ubuntu0.1, Nov 15 2022, 06:22:50)
[PyPy 7.3.9 with GCC 11.3.0]
$ pip3 freeze
Ciw==3.1.0
Cython==3.0.6
networkx==3.2.1
numpy==1.26.2
pandas==2.1.4
python-dateutil==2.8.2
pytz==2023.3.post1
queueing-tool==1.2.5
simpy==4.1.1
six==1.16.0
tqdm==4.66.1
tzdata==2023.3
Hey, I clearly missed my deadline, but I haven't forgotten. I'll get to this soon.
Hey, I clearly missed my deadline, but I haven't forgotten. I'll get to this soon.
Sounds good. I appreciate you looking into this! :)
BTW I ran a few different tools/implementations to simulate a single MM1 queue for 200 time steps (FIFO service discipline). Some of these implementations I found, some I wrote, and others I modified from previously-existing projects.
The following is a histogram (100 bins) of the results of running each implementation and timing the run time. The vertical axis is frequency across repeated runs and the logarithmic horizontal axis shows the amount of time it took the program to run.
Unsurprisingly the C++ (./cpp_MM1
) and Rust (./rust_mm1
) implementations are faster than the Python implementations. Each of the Simpy (simpy_MM1.py
) and Ciw (ciw_MM1.py
) implementations were run with the CPython interpreter and the PyPy interpreter. Within each choice of interpreter it was usually the case the Simpy implementation was faster than Ciw.
Queueing_tool (qt_MM1.py
) is faster without PyPy enhancement than either SimPy or Ciw are with it. It will be interesting to see how far queueing_tool takes the lead over other Python packages in run time performance if pypy3
is supported.
I recall from this issue that at one point I had successfully installed
queueing_tool
forpypy3
. But now I seem to be getting the following error:I realize there is nothing about queueing_tool's features that promises that it should work with PyPy. But it did give some speed improvement so I would like to better understand how to reproduce that state if possible.