Ian Kelly wrote:
> Also numba, which is reminiscent of psyco, but with more features and
> Python 3 support.
For numerical computing with NumPy, Numba tends to give performance
comparable to -O2 in C. This is because it is very easy to do type
inference in most scientific array computing. Numba
Marko Rauhamaa writes:
> Alain Ketterlin :
>
>> The real nice thing that makes Julia a different language is the
>> optional static typing, which the JIT can use to produce efficient code.
>> It's the only meaningful difference with the current state of python.
>
> I'm guessing the two main perfo
Steven D'Aprano :
> On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote:
>> I'm having a hard time finding information on how well it performs wrt
>> Java, for example. Did PyPy truly find the Philosophers' Stone?
>
> [...] do you mean, how does PyPy compare with compiler here? I don't know.
On Wed, 14 May 2014 07:35:35 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
>>
>>> Producing an effective JIT for Python seems like a formidable
>>> challenge but not impossible in principle.
>>
>> Or in practice.
>>
>> http://pypy.
Steven D'Aprano :
> On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
>
>> Producing an effective JIT for Python seems like a formidable challenge
>> but not impossible in principle.
>
> Or in practice.
>
> http://pypy.org/
I'm having a hard time finding information on how well it perform
On Tue, May 13, 2014 at 6:10 PM, Steven D'Aprano
wrote:
> On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
>
>> Producing an effective JIT for Python seems like a formidable challenge
>> but not impossible in principle.
>
> Or in practice.
>
> http://pypy.org/
>
> And it's predecessor: ht
On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
> Producing an effective JIT for Python seems like a formidable challenge
> but not impossible in principle.
Or in practice.
http://pypy.org/
And it's predecessor: http://psyco.sourceforge.net/
--
Steven D'Aprano
http://import-that
Alain Ketterlin :
> The real nice thing that makes Julia a different language is the
> optional static typing, which the JIT can use to produce efficient code.
> It's the only meaningful difference with the current state of python.
I'm guessing the two main performance roadblocks for Python are:
)
> but what makes it fast is the JIT. It is almost accomplishing C/C++
> and FORTRAN speeds (even though dynamic) because it is compiling
> on-the-fly.
JITing by itself has little impact on performance (as unladden-swallow
has shown for python). For the JIT to produce code as fast as a
F
On 13/05/2014 12:21, Chris Angelico wrote:
On Tue, May 13, 2014 at 9:16 PM, Roy Smith wrote:
Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better. Sometimes it's
because nobody knows how it works anymore and everybody is af
On Tuesday 13 May 2014 03:22:28 Steven D'Aprano did opine
And Gene did reply:
> On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote:
> > People who write buggy self-modifying code aren't paying attention.
>
> [...]
>
> > IMO, people who bad-mouth self-modifying code are folks who don't
> > hav
On Tue, May 13, 2014 at 9:16 PM, Roy Smith wrote:
> Sometimes code is still running for 15 years because it's so wonderful
> nobody has been able to come up with anything better. Sometimes it's
> because nobody knows how it works anymore and everybody is afraid to
> touch it :-)
And sometimes, b
In article <5371c834$0$11109$c3e8...@news.astraweb.com>,
Steven D'Aprano wrote:
> And after 15 years, I daresay that includes you.
Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better. Sometimes it's
because nobody knows
On Tue, May 13, 2014 at 8:44 PM, Rustom Mody wrote:
> On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
>> Actually, even the file system can do some of this to you. I was
>> checking lsof on one of my Linux systems a little while ago, and found
>> that I had half a dozen old ver
On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
> Actually, even the file system can do some of this to you. I was
> checking lsof on one of my Linux systems a little while ago, and found
> that I had half a dozen old versions of a program, all with the same
> file name, all del
On Tue, May 13, 2014 at 7:34 PM, Steven D'Aprano wrote:
> On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
>
>> On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano
>> wrote:
>>> Self-modifying code is a nightmare inside the head of a Lovecraftian
>>> horror. There's a reason why almost the
On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
> On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano
> wrote:
>> Self-modifying code is a nightmare inside the head of a Lovecraftian
>> horror. There's a reason why almost the only people still using self-
>> modifying code are virus writer
On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote:
> People who write buggy self-modifying code aren't paying attention.
[...]
> IMO, people who bad-mouth self-modifying code are folks who don't have
> the patience to do it right, because stable self-modifying code CAN most
> certainly be don
On Tuesday 13 May 2014 01:48:43 Steven D'Aprano did opine
And Gene did reply:
> On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
> > there has to be a value add for scientists to move away from R or
> > Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works we
On 5/13/14 12:48 AM, Steven D'Aprano wrote:
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
there has to be a value add for scientists to move away from R or
Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its
fast too), and there are zillions of lines of
On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano wrote:
> Self-modifying code is a nightmare inside the head of a Lovecraftian
> horror. There's a reason why almost the only people still using self-
> modifying code are virus writers, and the viruses they create are
> notorious for being buggy.
H
On Tue, 13 May 2014 00:33:47 -0500, Mark H Harris wrote:
> there has to be a value add for scientists to move away from R or
> Matlab, or from FORTRAN. Why go to the trouble? FORTRAN works well (its
> fast too), and there are zillions of lines of code cranking away on huge
> l
dynamic typing part obviously disappears, and
the overhead is removed.
Julia is dynamic (depending on how far you want to go with that)
but what makes it fast is the JIT. It is almost accomplishing C/C++ and
FORTRAN speeds (even though dynamic) because it is compiling on-the-fly.
But t
On Sun, 11 May 2014 20:14:14 -0400, Roy Smith wrote:
> In article ,
> MRAB wrote:
>
>> On 2014-05-12 00:15, Steven D'Aprano wrote:
>> > On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
>> >
>> >> In article ,
>> >> Chris Angelico wrote:
>> >>
>> >>> Some things are more standardized than
On 2014-05-12, Steven D'Aprano wrote:
> On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
>> On 2014-05-12 00:15, Steven D'Aprano wrote:
>>> The F and J keys have "F" and "J" printed on them instead of "G" and
>>> "K". They're also in slightly different positions, offset one position
>>> to the lef
On 12/05/2014 03:28, Steven D'Aprano wrote:
On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote:
On 12/05/2014 00:51, Steven D'Aprano wrote:
Cars are standardized -- there are basically two types, manuals and
automatics.
Sadly they can still go wrong due to modern engineering practices
perform.
Julia provides a way to make things fast: typing. If you provide
explicit types, the dynamic typing part obviously disappears, and
the overhead is removed.
But then, you're not too far from Fortran, or C/C++.
> The following code will produce over 100,000 digits of π (pi) in l
On Mon, May 12, 2014 at 2:26 PM, Mark H Harris wrote:
> Having said that, the accuracy was not my point; in the first place. My
> point is that the sin() function is built-in...
So what? Built-in just means that there's no namespacing of
mathematical functions.
ChrisA
--
https://mail.python.or
On 5/11/14 11:10 PM, Mark H Harris wrote:
On 5/11/14 10:10 PM, Dave Angel wrote:
On 05/11/2014 02:54 PM, Mark H Harris wrote:
>julia> sin(BigFloat(π/4))
> 7.0710678118654750275194295621751674626154323953749278952436611913748
> 20215180412e-01 with 256 bits of precision
That answer doesn
On 5/11/14 10:10 PM, Dave Angel wrote:
On 05/11/2014 02:54 PM, Mark H Harris wrote:
>julia> sin(BigFloat(π/4))
> 7.0710678118654750275194295621751674626154323953749278952436611913748
> 20215180412e-01 with 256 bits of precision
That answer doesn't seem to come anywhere near 256 bits of p
On 05/11/2014 02:54 PM, Mark H Harris wrote:
>julia> sin(BigFloat(π/4))
> 7.0710678118654750275194295621751674626154323953749278952436611913748
> 20215180412e-01 with 256 bits of precision
That answer doesn't seem to come anywhere near 256 bits of precision.
Using Python 3.2,
>>> x=7071
On 05/11/2014 09:11 PM, Steven D'Aprano wrote:
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
Certainly not. However they may be different where *you* are :-P
I'm using an IBM keyboard, model SK-8820.
Mine have an little ridge on the keytop of those keys.
I've seen keyboards with thos
On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote:
> On 12/05/2014 00:51, Steven D'Aprano wrote:
>>
>> Cars are standardized -- there are basically two types, manuals and
>> automatics.
>>
>>
> Sadly they can still go wrong due to modern engineering practices. In
> my neck of the woods some
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote:
> On 2014-05-12 00:15, Steven D'Aprano wrote:
>> On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
>>> Speaking of which, here's a trivia question. Without looking at your
>>> keyboard, describe how the "F" and "J" keys (assuming a US-English key
On 12/05/2014 00:51, Steven D'Aprano wrote:
Cars are standardized -- there are basically two types, manuals and
automatics.
Sadly they can still go wrong due to modern engineering practices. In
my neck of the woods some years ago people were killed when standing at
a bus stop, because the
In article ,
MRAB wrote:
> On 2014-05-12 00:15, Steven D'Aprano wrote:
> > On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
> >
> >> In article ,
> >> Chris Angelico wrote:
> >>
> >>> Some things are more standardized than others. A piano keyboard is
> >>> incredibly standard, to make it p
specialise
on different tasks. I'm a critic of C the language, but only for
application development -- it makes a grand high-level assembly language
for low-level programming by experts where fine control and efficiency is
more important than simplicity and programmer efficiency. Fortran
On 2014-05-12 00:15, Steven D'Aprano wrote:
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
In article ,
Chris Angelico wrote:
Some things are more standardized than others. A piano keyboard is
incredibly standard, to make it possible to play without having to look
at your fingers (eve
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>
>> Some things are more standardized than others. A piano keyboard is
>> incredibly standard, to make it possible to play without having to look
>> at your fingers (even when jumping your hands around,
On 5/11/14 1:59 PM, Chris Angelico wrote:
julia> prec=524288
524288
julia> with_bigfloat_precision(prec) do
println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4)
end
Would it be quicker (and no less accurate) to represent pi as
atan(BigFloat(1))*4 instead? That's how I or
On Mon, May 12, 2014 at 4:54 AM, Mark H Harris wrote:
> The following code will produce over 100,000 digits of π (pi) in less than 2
> seconds on a low-end processor, like my mac mini dual core 2Ghz:
>
>>julia> prec=524288
>>524288
>
>>julia> with_bigfloat_precision(prec) do
>> println(ata
On 5/11/14 12:05 PM, Alain Ketterlin wrote:
Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on
steroids. Its amazing as a dynamic language, and its fast, like
lightning fast as well as multiprocessing (parallel processing) at its
core. Its astounding, really.
Hmmm...
Its num
In article ,
Chris Angelico wrote:
> Some things are more standardized than others. A piano keyboard is
> incredibly standard, to make it possible to play without having to
> look at your fingers (even when jumping your hands around, which
> doesn't happen as much on a computer keyboard)
Speaki
On Mon, May 12, 2014 at 4:05 AM, Ethan Furman wrote:
> For the most part cars are very similar, yet in some circumstances (such as
> a vehicle in front of you suddenly stopping) the exact details (such as the
> precise location and size and shape of the brake pedal) become
> excruciatingly importa
On 05/11/2014 10:51 AM, Roy Smith wrote:
In article <871tw0s2kl@elektro.pacujo.net>,
Marko Rauhamaa wrote:
Tomasz Rola :
Given that Fortran is here for almost 60 years and lot of effort has
been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
breath.
I
On Mon, May 12, 2014 at 3:51 AM, Roy Smith wrote:
> It is fine. Computers are tools. The sign of a good tool is that you
> can pick it up and use it without having to read the instruction manual.
> I can jump into pretty much any car, start the engine, and drive it,
> without any learning curve.
On Mon, May 12, 2014 at 4:04 AM, Tomasz Rola wrote:
> And the "pipe
> extention" is one of the things I'd consider - as well as other
> similar means, like SOAP or REST.
Yep. My point was, keep the processes separate and it's easy. There
are myriad ways of doing the glue.
ChrisA
--
https://mail
On Mon, May 12, 2014 at 02:42:13AM +1000, Chris Angelico wrote:
> On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola wrote:
> > Given that Fortran is here for almost 60 years and lot of effort has
> > been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
> >
In article <871tw0s2kl@elektro.pacujo.net>,
Marko Rauhamaa wrote:
> Tomasz Rola :
>
> > Given that Fortran is here for almost 60 years and lot of effort has
> > been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
> > breath.
>
&g
Mark H Harris writes:
> On 5/10/14 8:42 AM, Roy Smith wrote:
>> http://tinyurl.com/mr54p96
> 'Julia' is going to give everyone a not so small run for competition;
> justifiably so, not just against FORTRAN.
>
> Julia is Matlab and R, Python, Lisp, Scheme; al
On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola wrote:
> Given that Fortran is here for almost 60 years and lot of effort has
> been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
> breath. Something may look like cool and great, but wait ten years and
> s
Tomasz Rola :
> Given that Fortran is here for almost 60 years and lot of effort has
> been spent to keep it backwards compatible (AFAIK), I wouldn't hold my
> breath.
I have seen a glimpse of the so-called scientific computing and Fortran
programming. I can't help but th
On Sun, May 11, 2014 at 07:09:27AM +, Steven D'Aprano wrote:
> On Sun, 11 May 2014 01:17:55 -0500, Mark H Harris wrote:
>
> > On 5/10/14 8:42 AM, Roy Smith wrote:
> >> Ars Technica article a couple of days ago, about Fortran, and what is
> >> likely to repla
On Sun, 11 May 2014 01:17:55 -0500, Mark H Harris wrote:
> On 5/10/14 8:42 AM, Roy Smith wrote:
>> Ars Technica article a couple of days ago, about Fortran, and what is
>> likely to replace it:
>>
>> http://tinyurl.com/mr54p96
>>
>>
> uhm, yeeah!
>
On Sunday, May 11, 2014 11:47:55 AM UTC+5:30, Mark H. Harris wrote:
> 'Julia' is going to give everyone a not so small run for competition;
> justifiably so, not just against FORTRAN.
>
>
> Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on
>
On 5/10/14 8:42 AM, Roy Smith wrote:
Ars Technica article a couple of days ago, about Fortran, and what is
likely to replace it:
http://tinyurl.com/mr54p96
uhm, yeeah!
'Julia' is going to give everyone a not so small run for competition;
justifiably so, not just against FORTRA
On 5/10/2014 9:42 AM, Roy Smith wrote:
In article ,
Dennis Lee Bieber wrote:
Obsolete and Legacy? Fortran still receives regular standards updates
(currently 2008, with the next revision due in 2015).
Ars Technica article a couple of days ago, about Fortran, and what is
likely to
In article ,
Dennis Lee Bieber wrote:
> On 08 May 2014 16:04:51 GMT, Steven D'Aprano
> declaimed the following:
>
> >Personally, I think that trying to be general and talk about "many other
> >languages" is a failing strategy. Better to be concrete: C, Pas
Op 14-11-13 01:53, Sudheer Joseph schreef:
> Hi,
> I need to write a binary file exactly as written by fortran code
> below to be read by another code which is part of a model which is not
> advisable to edit.I would like to use python for this purpose as python has
> m
Thank you,
But it wont allow to write it in unformatted way so
that the fortran code can read
with
open(11,file="input.bin")
read(11) IWI,JWI,XFIN,YFIN,DXIN,DYIN,NREC,WDAY
with best regards,
sudheer
On Thu, Nov 14, 2013 at 7:48 PM, Oscar Benjamin
wrote:
> O
.write(TITLE)
> f.write(IWI,JWI,XFIN,YFIN,DXIN,DYIN,NREC,WDAY)
> for i in np.arange(0,NREC):
> f.write(U[i,:,:],V[i,:,:])
> f.close()
>
> But the issue is that f.write do not allow multiple values( it allows one by
> one so throws an error with above code ) on same write st
Hi Sudheer,
Fortan binary format is not portable, and it's hard to work with it
with different langages, compilers, architectures...
In you're Python code, you also use NetCDF, which solve all these problems.
I would suggest to use only NetCDF files in both Python and Fortran code.
Hi,
I need to write a binary file exactly as written by fortran code below
to be read by another code which is part of a model which is not advisable to
edit.I would like to use python for this purpose as python has mode flexibility
and easy coding methods.
character(40) :: TITLE
On Jul 4, 6:09 pm, Stephen Hansen wrote:
> On 7/4/10 9:21 AM, sturlamolden wrote:
>
> > On 4 Jul, 14:29, David Cournapeau wrote:
>
> >> Actually, I think the main reason why Lua is much faster than other
> >> dynamic languages is its size. The language is small. You don't list,
> >> dict, tuples,
sturlamolden, 04.07.2010 05:30:
I was just looking at Debian's benchmarks. It seems LuaJIT is now (on
median) beating Intel Fortran!
C (gcc) is running the benchmarks faster by less than a factor of two.
Consider that Lua is a dynamically typed scripting language very
similar to Python.
L
On the positive side, Lua supports tail call optimization and coroutines
are built in by default.
--
дамјан ((( http://damjan.softver.org.mk/ )))
Education is one of the "prices" of freedom that some are unwilling to
pay.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Jul 9, 2010 at 5:10 PM, Terry Reedy wrote:
> On 7/9/2010 1:25 AM, sturlamolden wrote:
>
>> With OpenCL, Python is better than C for heavy computing. The Python
>> or C/C++ program has to supply OpenCL code (structured text) to the
>> OpenCL driver, which does the real work on GPU or CPU. P
On 7/9/2010 1:25 AM, sturlamolden wrote:
With OpenCL, Python is better than C for heavy computing. The Python
or C/C++ program has to supply OpenCL code (structured text) to the
OpenCL driver, which does the real work on GPU or CPU. Python is much
better than C or C++ at processing text. There w
On 9 Jul, 15:25, Felix wrote:
> PS: No need to convince me that MATLAB is not the solution.
What I mean is that Matlab and Mathematica are inherently "single
threaded" interpreters. Yet they are still used for serious parallel
computing. While Python has multiple threads but a GIL, only allowing
On Jul 9, 12:44 am, Stefan Behnel wrote:
> Felix, 09.07.2010 05:39:
> Well, at least its "parallel processing abilities" are quite good
actually.
> If you have really large computations, they usually run on more than one
> computer (not just more than one processor). So you can't really get aroun
working around these
> > problems or helping with parts). Am I wrong?
>
> Yes you are.
>
> We don't do CPU intensive work in "pure Python". We use Python to
> control C and Fortran libraries. That gives us the opportunity to
> multi-thread in C, release the GIL and mu
On 9 Jul, 06:44, Stefan Behnel wrote:
> WRT a single machine, you should note that GPGPUs are a lot faster these
> days than even multi-core CPUs. And Python has pretty good support for
> GPUs, too.
With OpenCL, Python is better than C for heavy computing. The Python
or C/C++ program has to supp
almost always
use Python to orchestrate C and Fortran. We can use OpenMP in C or
Fortran, or we can just release the GIL and use Python threads.
Second, the GIL it does not matter for MPI, as it works with
processes. Nor does it matter for os.fork or multiprocessing. On
clusters, which are as common i
Felix, 09.07.2010 05:39:
On Jul 4, 11:25 am, David Cournapeau wrote:
Well, I wish I did not have to use C, then :) For example, as a
contributor to numpy, it bothers me at a fundamental level that so
much of numpy is in C.
This is something that I have been thinking about recently. Python has
On Jul 4, 11:25 am, David Cournapeau wrote:
> On Mon, Jul 5, 2010 at 12:00 AM, D'Arcy J.M. Cain wrote:
> > I wish it was orders of magnitude faster for web development. I'm just
> > saying that places where we need compiled language speed that Python
> > already has that in C.
>
> Well, I wish I
On 4 Jul, 21:59, Stefan Behnel wrote:
> > I have already said I don't care about unladen swallow.
>
> What I meant, was: which of these benchmarks would have to be better to
> make you care? Because your decision not to care seems to be based on
> exactly these benchmarks.
Those are the only one
On Jul 4, 5:58 pm, John Nagle wrote:
> TheUnladenSwallowpeople should in theory be able to reach
> that level of performance. (Both groups are employed at Google.
> So their effectiveness will be compared.)
>
> John Nagle
No. Collin Winter said that they will
On 7/4/10 9:21 AM, sturlamolden wrote:
> On 4 Jul, 14:29, David Cournapeau wrote:
>
>> Actually, I think the main reason why Lua is much faster than other
>> dynamic languages is its size. The language is small. You don't list,
>> dict, tuples, etc...
>
> They have managed to combine list and di
On 7/4/2010 12:51 PM, Luis M. González wrote:
Looking at median runtimes, here is what I got:
gcc 1.10
LuaJIT1.96
Java 6 -server2.13
Intel Fortran 2.18
OCaml 3.41
SBCL 3.66
JavaScript V8 7.57
PyPy
On Jul 4, 4:51 pm, Luis M. González wrote:
> On Jul 4, 12:30 am, sturlamolden wrote:
>
>
>
>
>
> > I was just looking at Debian's benchmarks. It seems LuaJIT is now (on
> > median) beating Intel Fortran!
>
> > C (gcc) is running the benchmarks faste
sturlamolden, 04.07.2010 21:44:
On 4 Jul, 19:51, Stefan Behnel wrote:
Ok, so, which of those do you care about?
I have already said I don't care about unladen swallow.
What I meant, was: which of these benchmarks would have to be better to
make you care? Because your decision not to care se
On Jul 4, 12:30 am, sturlamolden wrote:
> I was just looking at Debian's benchmarks. It seems LuaJIT is now (on
> median) beating Intel Fortran!
>
> C (gcc) is running the benchmarks faster by less than a factor of two.
> Consider that Lua is a dynamically typed scripting lan
On 4 Jul, 19:51, Stefan Behnel wrote:
> Ok, so, which of those do you care about?
I have already said I don't care about unladen swallow.
--
http://mail.python.org/mailman/listinfo/python-list
"D'Arcy J.M. Cain" writes:
>> I find LUA quite interesting: instead of providing a language simple
>> to develop in, it focuses heavily on implementation simplicity. Maybe
>> that's the reason why it could be done at all by a single person.
>
> Is that really true about LUA? I haven't looked that
sturlamolden, 04.07.2010 19:10:
On 4 Jul, 19:02, Stefan Behnel wrote:
A number like "1.5 times faster" is meaningless without a specific
application and/or code section in mind. I'm pretty sure there are cases
where they are much faster than that, and there are cases where the net
gain is zero
On 4 Jul, 19:02, Stefan Behnel wrote:
> A number like "1.5 times faster" is meaningless without a specific
> application and/or code section in mind. I'm pretty sure there are cases
> where they are much faster than that, and there are cases where the net
> gain is zero (or -0.x or whatever).
He
sturlamolden, 04.07.2010 18:37:
On 4 Jul, 09:12, Rami Chowdhury wrote:
Out of curiosity, does anyone know how the Unladen Swallow version of Python
does by comparison?
Judging from their PyCon slides, it's roughly 1.5 times faster than
CPython.
A number like "1.5 times faster" is meaningles
On 4 Jul, 18:34, David Cournapeau wrote:
> I sincerly doubt it - where do take the information that matlab use
> float to represent int ?
I've used Matlab since 1994, so I know it rather well...
Only the recent versions can do arithmetics with number types
different from double (or complex doub
On 4 Jul, 09:12, Rami Chowdhury wrote:
> Out of curiosity, does anyone know how the Unladen Swallow version of Python
> does by comparison?
Judging from their PyCon slides, it's roughly 1.5 times faster than
CPython.
That might be important to Google, but not to me.
--
http://mail.python.org
On Mon, Jul 5, 2010 at 1:12 AM, sturlamolden wrote:
> On 4 Jul, 10:03, Stefan Behnel wrote:
>
>> Sort of. One of the major differences is the "number" type, which is (by
>> default) a floating point type - there is no other type for numbers. The
>> main reason why Python is slow for arithmetic co
On 4 Jul, 14:29, David Cournapeau wrote:
> Actually, I think the main reason why Lua is much faster than other
> dynamic languages is its size. The language is small. You don't list,
> dict, tuples, etc...
They have managed to combine list and dict into one type (table) that
does the job of both
On 4 Jul, 10:03, Stefan Behnel wrote:
> Sort of. One of the major differences is the "number" type, which is (by
> default) a floating point type - there is no other type for numbers. The
> main reason why Python is slow for arithmetic computations is its integer
> type (int in Py3, int/long in P
On 4 Jul, 16:47, "bart.c" wrote:
> I suspect also the Lua JIT compiler optimises some of the dynamicism out of
> the language (where it can see, for example, that something is always going
> to be a number, and Lua only has one numeric type with a fixed range), so
> that must be a big help.
Pyth
On Mon, Jul 5, 2010 at 12:00 AM, D'Arcy J.M. Cain wrote:
> On Sun, 4 Jul 2010 23:46:10 +0900
> David Cournapeau wrote:
>> On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain wrote:
>> > Which is 99% of the real-world applications if you factor out the code
>> > already written in C or other compil
On Sat, 3 Jul 2010 20:30:30 -0700 (PDT)
sturlamolden wrote:
>CPython 64.6
By the way, I assume that that's Python 2.x. I wonder how Python 3.1
would fare.
--
D'Arcy J.M. Cain | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
On Sun, 4 Jul 2010 23:46:10 +0900
David Cournapeau wrote:
> On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain wrote:
> > Which is 99% of the real-world applications if you factor out the code
> > already written in C or other compiled languages.
>
> This may be true, but there are areas where th
"sturlamolden" wrote in message
news:daa07acb-d525-4e32-91f0-16490027c...@w12g2000yqj.googlegroups.com...
I was just looking at Debian's benchmarks. It seems LuaJIT is now (on
median) beating Intel Fortran!
C (gcc) is running the benchmarks faster by less than a factor of two
On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain wrote:
> On 04 Jul 2010 04:15:57 GMT
> Steven D'Aprano wrote:
>> "Need" is a bit strong. There are plenty of applications where if your
>> code takes 0.1 millisecond to run instead of 0.001, you won't even
>> notice. Or applications that are limit
On 04 Jul 2010 04:15:57 GMT
Steven D'Aprano wrote:
> "Need" is a bit strong. There are plenty of applications where if your
> code takes 0.1 millisecond to run instead of 0.001, you won't even
> notice. Or applications that are limited by the speed of I/O rather than
> the CPU.
Which is 99% of
On Sun, Jul 4, 2010 at 5:03 PM, Stefan Behnel wrote:
> sturlamolden, 04.07.2010 05:30:
>>
>> I was just looking at Debian's benchmarks. It seems LuaJIT is now (on
>> median) beating Intel Fortran!
>>
>> C (gcc) is running the benchmarks faster by less than a
101 - 200 of 384 matches
Mail list logo
