C++ --
#include
#include
#include
#include
#include
#include
using namespace std;
int main()
{
DWORD ticks = ::GetTickCount();
const string s1("What do you know");
const string s2("So long...");
const stri
Ruby is also not far away :-)
Here's my code:
require 'time'
def f
a = []
100.times do
a.push "What do you know"
a.push "so long ..."
a.push "chicken crosses road"
a.push "fool"
end
b = a.uniq
b.each do |x|
puts x
end
e
Pebblestone:
> Sorry, I did some miscalculation what a shame.
Don't worry.
For me using Py 2.4.3 those memory values are 4536 before and 20184 kb
after, it means a difference of 15648 kb, that equals to about 16023552
bytes, that equals to about 100 * 4 * 4. That means 4 bytes for
each
Sorry, I did some miscalculation what a shame.
[EMAIL PROTECTED] wrote:
> Pebblestone:
>
> >I heard that python's list is implemented as adjustable array.
>
> Correct, an array geometrically adjustable on the right.
>
>
> >Here's my lisp implementation:<
>
> What's the memory size of a
> What's the memory size of a before computing b? You can compare it with
> Python, that may need less memory (because the array contains
> pointers).
Here's the memory usage:
1) before the loop ( fully garbage collected)
29,052,560 bytes, 757,774 objects.
2) after the loop
103,631,952 bytes,
Pebblestone:
>I heard that python's list is implemented as adjustable array.
Correct, an array geometrically adjustable on the right.
>Here's my lisp implementation:<
What's the memory size of a before computing b? You can compare it with
Python, that may need less memory (because the array co
Here's the result:
What do you know
fool
chicken crosses road
f elapsed: 1.26 seconds
f2 elapsed 2.11 seconds
[EMAIL PROTECTED] wrote:
> Pebblestone:
> > (defun test4 ()
> > (let ((a (make-array 400 :element-type 'string
> >:adjustable nil))
Oh, I forgot.
Your python's example (use direct index array index) of my
corresponding lisp code works slower than the version which use
'append'.
This let me think how python's list is implemented.
Anyway, python's list is surprisingly efficient.
[EMAIL PROTECTED] wrote:
> Pebblestone:
> > (
> But note this a list (that is an array, a list is a different data
> structure) of python becomes filled with pointers. I don't know what
> your CL does exactly.
I heard that python's list is implemented as adjustable array.
Here's my lisp implementation:
++
(defun test-list ()
Pebblestone:
> (defun test4 ()
> (let ((a (make-array 400 :element-type 'string
> :adjustable nil))
> (b nil))
> (dotimes (i 100)
> (progn
> (let ((j (1- (* 4 i
> (setf (aref a (incf j))
I tested in Common Lisp and compared the result with python.
My PC is: 3.6GH Pentium4
My OS is: Ubuntu 6.06 i386
My lisp implementation is SBCL 0.9.8 for i386
My python's version is: V2.4.3
Both implementations were installed via apt-get install.
Here's my Lisp program:
+
On 2006-08-25, Ben Sizer <[EMAIL PROTECTED]> wrote:
> Neil Cerutti wrote:
>> On 2006-08-24, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> > It will run a lot faster if it doesn't have to keep resizing
>> > the array.
>>
>> I don't see why it should run a lot faster that way.
>>
>> Appending eleme
Neil Cerutti wrote:
> I don't see why it should run a lot faster that way.
>
> Appending elements to a vector with push_back takes amortized
> constant time. In the example above, preallocating 4 strings
> saves (probably) math.log(4, 2) reallocations of the vector's
> storage along with t
Neil Cerutti wrote:
> On 2006-08-24, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > It will run a lot faster if it doesn't have to keep resizing
> > the array.
>
> I don't see why it should run a lot faster that way.
>
> Appending elements to a vector with push_back takes amortized
> constant t
On 2006-08-24, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Licheng Fang wrote:
>> Hi, I'm learning STL and I wrote some simple code to compare the
>> efficiency of python and STL.
>>
>> //C++
>> #include
>> #include
>> #include
>> #include
>> #include
>> using namespace std;
>>
>> int mai
Licheng Fang wrote:
> Hi, I'm learning STL and I wrote some simple code to compare the
> efficiency of python and STL.
>
> //C++
> #include
> #include
> #include
> #include
> #include
> using namespace std;
>
> int main(){
> vector a;
> for (long int i=0; i<1 ; ++i){
>
Neil Cerutti <[EMAIL PROTECTED]> wrote:
> Those of you experiencing a temporary obsession with this topic
> are encouraged to study The Great Language Shootout, until the
> obsession goes away. ;)
I think that everybody knows GLS. However, when I have results different
from what I expected, I try
Neil Cerutti <[EMAIL PROTECTED]> wrote:
> Those of you experiencing a temporary obsession with this topic
> are encouraged to study The Great Language Shootout, until the
> obsession goes away. ;)
I think that everybody knows GLS. However, when I have results different
from what I expected, I try
Amanjit> So on linux its a lot better than that, because - I think -
Amanjit> ptmalloc is used which is based on dmalloc which is efficient
Amanjit> for those small size allocs (which malloc() and free() were
Amanjit> never designed for).
And which for Python has been further opti
On 2006-08-23, Mc Osten <[EMAIL PROTECTED]> wrote:
> Ray <[EMAIL PROTECTED]> wrote:
>> Great to know that my model of how the world works is still
>> correct! (at least in relation to Python and C++!) :)
>
> So please explain my results. I loop the same number of times.
Those of you experiencing a
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> g] On Behalf Of Ray
> Sent: Wednesday, August 23, 2006 4:28 PM
> Subject: Re: Python and STL efficiency
>
>
> Tim N. van der Leeuw wrote:
> > With the nr of loops corrected
On 2006-08-23, Amanjit Gill <[EMAIL PROTECTED]> wrote:
> you should also include for ostream_operator.
, actually.
--
Neil Cerutti
--
http://mail.python.org/mailman/listinfo/python-list
Ray <[EMAIL PROTECTED]> wrote:
> Great to know that my model of how the world works is still correct!
> (at least in relation to Python and C++!) :)
So please explain my results. I loop the same number of times.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://
Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
> I have to admit to a stupid mistake, for which I feel quite ashamed - I
> got the loop-size wrong in the Python code. So all Python results
> posted by me were off by a factor of 10 :-(
> I feel quite bad about that!
Well, this makes *my* results
> Hi, I'm learning STL and I wrote some simple code to compare the
> efficiency of python and STL.
Hi, you are benching heap allocations and of course heap fragmentation.
this is what devpartner c++ profiler had to say:
Method %in % with Called Average Real Name Method Children
> I was using VC++.net and IDLE, respectively. I had expected C++ to be
> way faster. However, while the python code gave the result almost
- This code runs amortized 100ms on my machien (vc.net 2003 pro,
dinkumware stl, p4m 2.2GHz thinkpad, windows 2003 server), (10 loops in
1000ms)
- with STLPo
[EMAIL PROTECTED] wrote:
> >> Yes it is. But of course you can't sat that "Python is faster than
> >> C++".
>
> Harald> Of course not. Python is faster then assembler. Proofed @
> Harald> EuroPython 2006 in CERN, near the LHC Beta, in the same room
> Harald> many Nobel laurates gave the
>> Yes it is. But of course you can't sat that "Python is faster than
>> C++".
Harald> Of course not. Python is faster then assembler. Proofed @
Harald> EuroPython 2006 in CERN, near the LHC Beta, in the same room
Harald> many Nobel laurates gave their presentations before.
H
Ray> Same here, although that said Python's implementation of those data
Ray> structure must already be as optimal as mortals can do it.
Perhaps more optimal. We've had (tim)bots working on the problem for years.
Skip
--
http://mail.python.org/mailman/listinfo/python-list
Tim N. van der Leeuw wrote:
> With the nr of loops corrected, Python on my laptop performs worse than
> C++ under all circumstances, by a factor of about 2:
*Phew*
Great to know that my model of how the world works is still correct!
(at least in relation to Python and C++!) :)
Thanks,
Ray
>
>
Mc Osten wrote:
> Ray <[EMAIL PROTECTED]> wrote:
>
> > Yeah, my guess would be either he used the Debug configuration or he
> > actually created a Managed executable instead of a pure Win32
> > application. Sigh, now I can't wait to get home and try it out :)
>
> Can be. But I suppose a Managed sh
Ray <[EMAIL PROTECTED]> wrote:
> Yeah, my guess would be either he used the Debug configuration or he
> actually created a Managed executable instead of a pure Win32
> application. Sigh, now I can't wait to get home and try it out :)
Can be. But I suppose a Managed should not get *that* slow.
Ir
This thread can be useful for ShedSkin (the Python => C++ translator),
because often it manages strings slower than CPython still, some
suggestions from a C++ expert can surely improve things a lot. C++ is
fast, but you have to use and know it well, otherwise you don't obtain
much speed.
Maybe thi
Tim, sorry for I send it to you personally, I was abused by thunderbird.
Tim N. van der Leeuw a écrit :
>
> Your C++ version got me the following timings (using gcc 3.4.5 as the
> compiler, MinGW version, with -O6):
>
> ...
>
>
> Hmmm... Can we conclude now that carefully crafted C++ code is
Le mardi 22 août 2006 23:15, Fredrik Lundh a écrit :
> Maric Michaud wrote:
> > The problem here, is that the strings in the set are compared by value,
> > which is not optimal, and I guess python compare them by adress ("s*n is
> > s*n" has the same complexity than "s*n == s*n" in CPython, right ?
Mc Osten wrote:
> Of course. I suppose there's something broken in OP's C++ setup (in fact
> the version I compiled with VCPP 2005 also takes a lot of seconds...
> something like 20-30 seconds, but of course this makes me think I
> haven't understood how it is supposed to work, since my gcc gives
GHUM <[EMAIL PROTECTED]> wrote:
> Proofed @ EuroPython
> 2006 in CERN, near the LHC Beta, in the same room many Nobel laurates
> gave their presentations before.
Have you some link? I suppose it's kind of a joke they did or something
like that...
--
blog: http://www.akropolix.net/rik0/blogs |
Ray <[EMAIL PROTECTED]> wrote:
> Certainly--I was not comparing 100 against 1. Referring to the
> OP's statement: "However, while the python code gave the result almost
> instantly, the C++ code took several seconds to run!" 30ms sounds like
> a definite improvement over several seconds!
Mc Osten schrieb:
> Yes it is. But of course you can't sat that "Python is faster than C++".
Of course not. Python is faster then assembler. Proofed @ EuroPython
2006 in CERN, near the LHC Beta, in the same room many Nobel laurates
gave their presentations before.
Harald
--
http://mail.python.
Mc Osten wrote:
> In your test, you are looping 1 times, we looped 100.
> In Python tests with 1 elements, it was about 10 ms.
>
> Moreover, we tried various Python and C++ configurations. Most of the
> tests are done with Python 2.4, not 2.5.
> And I used gcc4, that is to say the late
Mc Osten wrote:
> Ray <[EMAIL PROTECTED]> wrote:
>
> > I'm using VC++ Express, I didn't care to tweak the optimizations, I
> > merely chose the "Release" configuration for the executable. It's
> > blazing fast, taking only 30+ ms each run.
>
> Of course it is faster. We are looping 100 times,
<[EMAIL PROTECTED]> wrote:
> That's to say,
> python is still much faster?
Yes it is. But of course you can't sat that "Python is faster than C++".
We found that the code to do this, written in the most natural way, is a
lot faster in Python. However, if you optimze the code, C++ gets almost
as f
Ray <[EMAIL PROTECTED]> wrote:
> Not really, see my test, in my other post in the same thread. I'm using
> VC++ Express 2005. If we're comparing with Python 2.5 I think it's just
> fair that for C++ we're using the latest as well.
In your test, you are looping 1 times, we looped 100.
In P
Ray <[EMAIL PROTECTED]> wrote:
> I'm using VC++ Express, I didn't care to tweak the optimizations, I
> merely chose the "Release" configuration for the executable. It's
> blazing fast, taking only 30+ ms each run.
Of course it is faster. We are looping 100 times, you just 1.
--
blog: h
[EMAIL PROTECTED] wrote:
> That's to say,
> python is still much faster?
Not really, see my test, in my other post in the same thread. I'm using
VC++ Express 2005. If we're comparing with Python 2.5 I think it's just
fair that for C++ we're using the latest as well.
> I am a c++ newbie but I thin
That's to say,
python is still much faster?
I am a c++ newbie but I think c++ should be faster here.
Maybe someone can post this to the c++ maillist and they will tell how
to accelerate it.
Tim N. van der Leeuw wrote:
> Mc Osten wrote:
> > Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> >
> > > Python'
Tim N. van der Leeuw wrote:
> Incidentally, I also have a version compiled with VC++ 6 now... (not
> yet w/VC++ 7) .. Compiled with release-flags and maximum optimization
> for speed, here's the result of VC++ 6:
OK, now I'm getting obsessed with this too ;-)
I'm using VC++ Express, I didn't ca
Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
> And the results of IronPython (1.0rc2) are just in as well:
I can't test this one.
>
> And for Python 2.5:
> [EMAIL PROTECTED] ~/My Documents/Python
> $ /cygdrive/c/Python25/python.exe SpeedTest.py
> Begin Test
> Number of unique string objects:
Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
> My conclusion from that is, that the vector<> or set<> implementations
> of GCC are far superior to those of VC++ 6, but that memory allocation
> for GCC 3.4.5 (MinGW version) is far worse than that of MSCRT / VC++ 6.
> (And Python still smokes the
Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
> NB: Your code now tests for address-equality. Does it also still test
> for string-equality? It looks to me that it does, but it's not quite
> clear to me.
It does it.
set b(a.begin(), a.end());
set c; // well ordered set (b is ordered by
Maric Michaud wrote:
> Le mardi 22 août 2006 12:55, Mc Osten a écrit :
> > In fact Python here is faster. Suppose it has a really optimized set
> > class...
>
> Maybe I'm missing something but the posted c++codes are not equivalent IMO to
> what python is doing. I discarded the "slow" version, and
Maric Michaud wrote:
> The problem here, is that the strings in the set are compared by value, which
> is not optimal, and I guess python compare them by adress ("s*n is s*n" has
> the same complexity than "s*n == s*n" in CPython, right ?).
wrong.
> timeit -s"s='x'; n=1000" "s*n is n*s"
1
[EMAIL PROTECTED] wrote:
> Tim> But beware! For Python2.5 I had to change the code slightly,
> Tim> because it already realized that the expression
>
> Tim> '%s' % 'something'
>
> Tim> will be a constant expression, and evaluates it once only... so I
> Tim> had to replace '%s' with
Le mardi 22 août 2006 12:55, Mc Osten a écrit :
> In fact Python here is faster. Suppose it has a really optimized set
> class...
Maybe I'm missing something but the posted c++codes are not equivalent IMO to
what python is doing. I discarded the "slow" version, and tried to get the
equivalent in
Tim> But beware! For Python2.5 I had to change the code slightly,
Tim> because it already realized that the expression
Tim> '%s' % 'something'
Tim> will be a constant expression, and evaluates it once only... so I
Tim> had to replace '%s' with a variable, and I got the timing
Tim N. van der Leeuw wrote:
> Mc Osten wrote:
> > Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
> >
> > > Oh boy; yes indeed the slow python is faster than the fast C++
> > > version... Must be something really awful happening in the STL
> > > implementation that comes with GCC 3.4!
> >
> > And
Mc Osten wrote:
> Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
>
> > Oh boy; yes indeed the slow python is faster than the fast C++
> > version... Must be something really awful happening in the STL
> > implementation that comes with GCC 3.4!
>
> And the Python version does the very same number
Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
> Oh boy; yes indeed the slow python is faster than the fast C++
> version... Must be something really awful happening in the STL
> implementation that comes with GCC 3.4!
And the Python version does the very same number of iterations than the
C++ o
Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
> But your C++ program outputs times in seconds, right? So all
> compilations except for the first two give results in less than a
> second, right? (meaning the optimizations of your standard-compilation
> give worst results than -O3?)
Yes. It's in
Mc Osten wrote:
> Here some results (I know that the fpoint optimizations are useless...
> it's is my "prebuilt" full optimization macro :) ):
Interesting. The opimisation makes no difference to the speed of the C++ one
for me. I just get
xpc17:~> g++4 -O2 test2.cpp
xpc17:~> ./a.out
What do you
Mc Osten wrote:
> Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> > Python's memory allocator is also quite fast, compared to most generic
> > allocators...
>
> In fact also in the two "slow" versions Python outperforms C++.
> I didn't notice it in the first place.
>
> --
> blog: http://www.akropoli
Mc Osten wrote:
> Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> > Python's memory allocator is also quite fast, compared to most generic
> > allocators...
>
> In fact also in the two "slow" versions Python outperforms C++.
> I didn't notice it in the first place.
>
But your C++ program outputs tim
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Python's memory allocator is also quite fast, compared to most generic
> allocators...
In fact also in the two "slow" versions Python outperforms C++.
I didn't notice it in the first place.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i fil
"Mc Osten" wrote:
> In fact Python here is faster. Suppose it has a really optimized set
> class...
Python's memory allocator is also quite fast, compared to most generic
allocators...
--
http://mail.python.org/mailman/listinfo/python-list
Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:
> I'm curious though, if on the OP's machine the slowed-down Python
> version is still faster than the C++ version.
I tested both on my machine (my other post in the thread)
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site
Jeremy Sanders <[EMAIL PROTECTED]> wrote:
> It must be the debugging, the compiler or a poor STL implementation. With
> gcc 4 it runs instantly on my computer (using -O2), even with 10x the
> number of values.
$ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
53
Ray wrote:
> Tim N. van der Leeuw wrote:
> > > In which case, Licheng, you should try using the /GF switch. This will
> > > tell Microsoft C++ compiler to pool identical string literals together.
> > >
> > >
> > > :)
> >
> > The code still creates a new string - instance each time it tries to
> >
Tim N. van der Leeuw wrote:
> > In which case, Licheng, you should try using the /GF switch. This will
> > tell Microsoft C++ compiler to pool identical string literals together.
> >
> >
> > :)
>
> The code still creates a new string - instance each time it tries to
> append a const char* to the v
Fredrik Lundh wrote:
> Ray wrote:
>
> >> in the C++ example, you're creating 4 string objects.
> >
> > In which case, Licheng, you should try using the /GF switch. This will
> > tell Microsoft C++ compiler to pool identical string literals together.
>
> in what way does that change the impleme
Tim N. van der Leeuw wrote:
> Ray wrote:
> > Fredrik Lundh wrote:
> > > in the Python example, the four strings in your example are shared, so
> > > you're basically copying 4 pointers to the list.
> > >
> > > in the C++ example, you're creating 4 string objects.
> > >
> > >
> >
> > In wh
Jeremy Sanders a écrit :
> Licheng Fang wrote:
>
>> I was using VC++.net and IDLE, respectively. I had expected C++ to be
>> way faster. However, while the python code gave the result almost
>> instantly, the C++ code took several seconds to run! Can somebody
>> explain this to me? Or is there som
Licheng Fang wrote:
> I was using VC++.net and IDLE, respectively. I had expected C++ to be
> way faster. However, while the python code gave the result almost
> instantly, the C++ code took several seconds to run! Can somebody
> explain this to me? Or is there something wrong with my code?
It mu
Ray wrote:
> Fredrik Lundh wrote:
> > in the Python example, the four strings in your example are shared, so
> > you're basically copying 4 pointers to the list.
> >
> > in the C++ example, you're creating 4 string objects.
> >
> >
>
> In which case, Licheng, you should try using the /GF
Ray wrote:
>> in the C++ example, you're creating 4 string objects.
>
> In which case, Licheng, you should try using the /GF switch. This will
> tell Microsoft C++ compiler to pool identical string literals together.
in what way does that change the implementation of C++'s string type ?
-
Fredrik Lundh wrote:
> in the Python example, the four strings in your example are shared, so
> you're basically copying 4 pointers to the list.
>
> in the C++ example, you're creating 4 string objects.
>
>
In which case, Licheng, you should try using the /GF switch. This will
tell Micros
Licheng Fang wrote:
> Hi, I'm learning STL and I wrote some simple code to compare the
> efficiency of python and STL.
> I was using VC++.net and IDLE, respectively. I had expected C++ to be
> way faster. However, while the python code gave the result almost
> instantly, the C++ code took several
How did you compile the C++ executable? I assume that it is Release
mode? Then are the optimization switches enabled? Is it compiled as
Native Win32 or Managed application?
I suspect that other than what other posters have suggested about your
code, the difference in speed is due to the way you bu
Licheng Fang wrote:
> I was using VC++.net and IDLE, respectively. I had expected C++ to be
> way faster. However, while the python code gave the result almost
> instantly, the C++ code took several seconds to run! Can somebody
> explain this to me? Or is there something wrong with my code?
in th
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Tim N. van der
> Leeuw wrote:
>
> > (your C++ code contains some C#-isms, such as omitting the '.h' in the
> > include <> statements).
>
> That's no C#-ism, that's C++. The standard C++ header names don't have a
> trailing '.h'. ``gcc`` p
In <[EMAIL PROTECTED]>, Tim N. van der
Leeuw wrote:
> (your C++ code contains some C#-isms, such as omitting the '.h' in the
> include <> statements).
That's no C#-ism, that's C++. The standard C++ header names don't have a
trailing '.h'. ``gcc`` prints deprecation warnings if you write the
nam
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Licheng Fang
> wrote:
>
> > Hi, I'm learning STL and I wrote some simple code to compare the
> > efficiency of python and STL.
> >
[...]
>
> There's a difference in data structures at least. The Python `set` type
> is implemented with a ha
Licheng Fang wrote:
> Hi, I'm learning STL and I wrote some simple code to compare the
> efficiency of python and STL.
>
>
> I was using VC++.net and IDLE, respectively. I had expected C++ to be
> way faster. However, while the python code gave the result almost
> instantly, the C++ code took seve
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Licheng Fang
> wrote:
>
> > Hi, I'm learning STL and I wrote some simple code to compare the
> > efficiency of python and STL.
> >
> > //C++
> > #include
> > #include
> > #include
> > #include
> > #include
> > using namespace std;
> >
In <[EMAIL PROTECTED]>, Licheng Fang
wrote:
> Hi, I'm learning STL and I wrote some simple code to compare the
> efficiency of python and STL.
>
> //C++
> #include
> #include
> #include
> #include
> #include
> using namespace std;
>
> int main(){
> vector a;
> for (long int i=0;
Hi, I'm learning STL and I wrote some simple code to compare the
efficiency of python and STL.
//C++
#include
#include
#include
#include
#include
using namespace std;
int main(){
vector a;
for (long int i=0; i<1 ; ++i){
a.push_back("What do you know?");
85 matches
Mail list logo
