On Sunday, 17 March 2013 at 21:13:48 UTC, Paulo Pinto wrote:
If I am not mistaken, Rust makes use of them as well.
Rust doesn't anymore:
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html
The announcement also mentions performance problems related to Go
segmented stacks:
The trick is to make something which is powerful and flexible
for the
experienced user and yet not too daunting for the newbie. I
don't know how
well we've succeeded on that front, but I'm sure that more
tutorials and
better documentation and whatnot would help.
- Jonathan M Davis
On Monday, 18 March 2013 at 19:05:09 UTC, Walter Bright wrote:
On 3/18/2013 3:25 AM, bearophile wrote:
Walter Bright:
That's just not an issue when you have 64 bits of address
space. You can still
have 4 billion stacks of 4 billion bytes each.
At this point I suggest you to study exactly
On Tue, Mar 26, 2013 at 4:43 AM, Walter Bright
newshou...@digitalmars.comwrote:
How to do profiling with the dmd D compiler:
1. Add the -profile switch to the command line.
2. Read the report generated.
To do coverage analysis:
1. Add the -cov switch to the command line.
2. Read the
26-Mar-2013 13:38, Rory McGuire пишет:
On Tue, Mar 26, 2013 at 4:43 AM, Walter Bright
newshou...@digitalmars.com mailto:newshou...@digitalmars.com wrote:
How to do profiling with the dmd D compiler:
1. Add the -profile switch to the command line.
2. Read the report generated.
On 3/26/2013 2:38 AM, Rory McGuire wrote:
Thanks I remember about the -profile switch but I don't see memory usage there.
-profile and -cov do not track memory usage.
If you see your program using more and more memory even though it should not be
how do you check where the problem is?
I've
On 3/26/2013 3:04 AM, Walter Bright wrote:
On 3/26/2013 2:38 AM, Rory McGuire wrote:
Thanks I remember about the -profile switch but I don't see memory usage there.
-profile and -cov do not track memory usage.
If you see your program using more and more memory even though it should not be
On 2013-03-26 10:49, Dmitry Olshansky wrote:
What everybody in all other native languages use, for instance:
valgrind --tool=massif, valgrind --tool=callgrind
Any general purpose profiler works. I can confirm that e.g. AMD
CodeAnalyst works just fine if application is compiled with symbols.
On Tuesday, 26 March 2013 at 10:08:30 UTC, Walter Bright wrote:
On 3/26/2013 3:04 AM, Walter Bright wrote:
On 3/26/2013 2:38 AM, Rory McGuire wrote:
Thanks I remember about the -profile switch but I don't see
memory usage there.
-profile and -cov do not track memory usage.
If you see your
On Mon, Mar 18, 2013 at 2:21 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Could you please go into details on the debugging and benchmarking tools?
Thanks.
Hi Andrei,
Apologies for not replying sooner.
Perhaps it is actually just the feel of the debugging and benchmarking,
On 3/25/13 8:02 AM, Rory McGuire wrote:
Perhaps it is actually just the feel of the debugging and
benchmarking, and the general completeness of the *documentation*.
This set of slides: http://talks.golang.org/2012/simple.slide introduces
pretty much everything you need to know about Go. Graphs
On 3/25/2013 5:02 AM, Rory McGuire wrote:
The profiling doc is here:
http://blog.golang.org/2011/06/profiling-go-programs.html
It is all super easy, and documented so that you can do it now.
What it says about profiling:
To start tuning the Go program, we have to enable profiling. If the
On 3/25/13 10:43 PM, Walter Bright wrote:
On 3/25/2013 5:02 AM, Rory McGuire wrote:
The profiling doc is here:
http://blog.golang.org/2011/06/profiling-go-programs.html
It is all super easy, and documented so that you can do it now.
What it says about profiling:
To start tuning the Go
Whether it is Go or D, I wish one of you guys would fill the gap
between the numeric work I need to do in fortran and the
ui/string parsing/web work/plotting/animating I do in python.
While working in two languages is realistically not a huge deal,
it would be nice if there was something that
edit: ditch both python and fortran.
That's julia's(http://julialang.org/) goal, but of course it's
not nearly polished.
I'm interested in this as well, since I'm not totally comfortable
about using a pirated MATLAB version and I hear that numpy can't
match its performance on macro code.
On Tuesday, 26 March 2013 at 04:11:05 UTC, Geancarlo Rocha wrote:
That's julia's(http://julialang.org/) goal, but of course it's
not nearly polished.
I'm interested in this as well, since I'm not totally
comfortable about using a pirated MATLAB version and I hear
that numpy can't match its
On Sun, 2013-03-17 at 22:13 +0100, Paulo Pinto wrote:
Am 17.03.2013 20:28, schrieb 1100110:
[…]
The day I can compile pypy without needing 8Gb of memory is the day I'll
consider it.
Uau, that much?!
I tend to use Python only for shell scripting type of tasks, so I wasn't
aware that
On Sun, 2013-03-17 at 13:56 -0700, Walter Bright wrote:
On 3/17/2013 3:01 AM, Russel Winder wrote:
I guess this is because of the segmented stacks architecture behind the
realization of Go.
Segmented stacks have a significant performance cost to them, as well as
making
it hard to
On 3/18/2013 2:22 AM, Russel Winder wrote:
On Sun, 2013-03-17 at 13:56 -0700, Walter Bright wrote:
On 3/17/2013 3:01 AM, Russel Winder wrote:
I guess this is because of the segmented stacks architecture behind the
realization of Go.
Segmented stacks have a significant performance cost to
On Monday, 18 March 2013 at 09:18:38 UTC, Russel Winder wrote:
On Sun, 2013-03-17 at 22:13 +0100, Paulo Pinto wrote:
Am 17.03.2013 20:28, schrieb 1100110:
[…]
The day I can compile pypy without needing 8Gb of memory is
the day I'll
consider it.
Uau, that much?!
I tend to use Python only
Walter Bright:
That's just not an issue when you have 64 bits of address
space. You can still have 4 billion stacks of 4 billion bytes
each.
At this point I suggest you to study exactly why Rust developers
have decided to use a segmented stack. It seems to work well for
them.
Bye,
On 3/18/13 1:46 AM, Rory McGuire wrote:
The reason I use golang and not dlang for development at work is because
debugging is straightforward no weird segfaults after you program has
been running for a couple of days.
Their debugging and benchmark tools are really good and the
documentation is
On 3/18/2013 3:25 AM, bearophile wrote:
Walter Bright:
That's just not an issue when you have 64 bits of address space. You can still
have 4 billion stacks of 4 billion bytes each.
At this point I suggest you to study exactly why Rust developers have decided to
use a segmented stack. It
Am 18.03.2013 13:21, schrieb Andrei Alexandrescu:
On 3/18/13 1:46 AM, Rory McGuire wrote:
The reason I use golang and not dlang for development at work is because
debugging is straightforward no weird segfaults after you program has
been running for a couple of days.
Their debugging and
18-Mar-2013 14:25, bearophile пишет:
Walter Bright:
That's just not an issue when you have 64 bits of address space. You
can still have 4 billion stacks of 4 billion bytes each.
At this point I suggest you to study exactly why Rust developers have
decided to use a segmented stack. It seems
On Sun, 2013-03-17 at 08:59 +0100, Paulo Pinto wrote:
[…]
However the Go guys just don't agree with the progresses made in
language abstractions in the last decades, which in my view is a plus
point for D and Rust, and made me stop caring about Go.
[…]
So what are the features that Go is
On 17.03.2013 09:05, Russel Winder wrote:
On Sun, 2013-03-17 at 08:59 +0100, Paulo Pinto wrote:
[…]
However the Go guys just don't agree with the progresses made in
language abstractions in the last decades, which in my view is a plus
point for D and Rust, and made me stop caring about Go.
[…]
On 3/17/2013 1:17 AM, Paulo Pinto wrote:
On 17.03.2013 09:05, Russel Winder wrote:
So what are the features that Go is ignoring that D has?
- exceptions;
- enumerations;
- generic types;
- direct use of OS APIs, without the need of writing wrappers;
- currently only static compilation is
On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
[…]
The first known one is that Go is the only strong typed language to
eschew generics in the 21st century.
On the other hand, perhaps generics is not a good thing, yet has created
an unchallenged mindset? NB I am tainted by C++ templates
On Sun, 2013-03-17 at 01:57 -0700, Walter Bright wrote:
[…]
I'd like to add that D has:
- operator overloading
- user defined attributes
- dll's (coming soon)
- vector operations
- SIMD operations
- scope guard
- compile time function execution
- true immutability and purity
- inline
17-Mar-2013 14:06, Russel Winder пишет:
On Sun, 2013-03-17 at 01:57 -0700, Walter Bright wrote:
[…]
I'd like to add that D has:
- operator overloading
- user defined attributes
- dll's (coming soon)
- vector operations
- SIMD operations
- scope guard
- compile time function execution
- true
On Sunday, 17 March 2013 at 08:57:48 UTC, Walter Bright wrote:
I'd like to add that D has:
- operator overloading
- user defined attributes
- dll's (coming soon)
So it doesn't.
- vector operations
- SIMD operations
- scope guard
- compile time function execution
- true immutability and
On 03/17/2013 07:09 AM, Paulo Pinto wrote:
On 17.03.2013 11:01, Russel Winder wrote:
On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
[…]
The first known one is that Go is the only strong typed language to
eschew generics in the 21st century.
On the other hand, perhaps generics is not a
On 3/17/2013 3:06 AM, Russel Winder wrote:
On the other hand creeping featurism can be a bad thing. Isn't the
mantra small language, large (properly indexed) library?
It can be a bad thing, no doubt about it. On the other hand:
When I was in London for the 2010 ACCU (when the volcano stranded
On 3/17/2013 3:01 AM, Russel Winder wrote:
I guess this is because of the segmented stacks architecture behind the
realization of Go.
Segmented stacks have a significant performance cost to them, as well as making
it hard to interface to other languages. I also think that the shift to 64 bits
Am 17.03.2013 21:56, schrieb Walter Bright:
On 3/17/2013 3:01 AM, Russel Winder wrote:
I guess this is because of the segmented stacks architecture behind the
realization of Go.
Segmented stacks have a significant performance cost to them, as well as
making it hard to interface to other
Am 17.03.2013 20:28, schrieb 1100110:
On 03/17/2013 07:09 AM, Paulo Pinto wrote:
On 17.03.2013 11:01, Russel Winder wrote:
On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
[…]
The first known one is that Go is the only strong typed language to
eschew generics in the 21st century.
On
Walter Bright wrote:
[snip]
I prefer to view D as a fully equipped machine shop with the right tools
for the right job. Yes, it will take longer to master it than a simpler
language. But we're professionals, we program all day.
Not everyone is. With its scripting abilities (fast
On 03/17/2013 03:44 PM, Walter Bright wrote:
On 3/17/2013 3:06 AM, Russel Winder wrote:
On the other hand creeping featurism can be a bad thing. Isn't the
mantra small language, large (properly indexed) library?
It can be a bad thing, no doubt about it. On the other hand:
When I was in
On Sunday, March 17, 2013 17:14:42 1100110 wrote:
Soo... You're saying D is like Vim? =P
LOL. D's learning curve is nowhere near as steep as that. Almost nothing has a
learning curve as steep as vim...
But on some level, the concept is the same. In order for something to be
powerful enough
The reason I use golang and not dlang for development at work is because
debugging is straightforward no weird segfaults after you program has been
running for a couple of days.
Their debugging and benchmark tools are really good and the documentation
is fantastic. I haven't used dlang for a
42 matches
Mail list logo
