Slide 25:
Implicit invariants often hard to track down
Then maybe it's a good idea to add such invariants to the dmd
front-end
code, even before its port to D.
Bye,
bearophile
My guess is Parallel Fast Fourier Transform.
It's Pretty Fast Fourier Transform. The code is at
https://g
I've not run across anyone who says "my program got
faster! It went from 0.05 Hz to 0.08 Hz!".
People do say "my program does 10 X per second", though.
On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
A little write-up I just did on something I thought was pretty
cool:
Combine Coroutines and Input Ranges for Dead-Simple D Iteration
https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple
On Tuesday, 1 May 2012 at 20:49:48 UTC, Nick Sabalausky wrote:
"jerro" wrote in message
news:sxfngaqnhwxqookrv...@forum.dlang.org...
On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
A little write-up I just did on something I thought was
pretty cool:
Combine Coro
Compared to normal iteration schemes, yes. It may be
comparable to opApply in terms of performance though. If
you're curious, look at the Fiber context switching code
(starting at switchIn and switchOut).
It's much slower than opApply. This loop takes 70s on my machine:
foreach(el; visitor
What compiler options is that with?
I used DMD and compiler flags -O -inline -release on x86_64 linux.
It may be slow relative to incrementing a integer:
The opApply isn't just incrementing an integer - it's
calling a function through a pointer. A loop that just
increments an integer is an order of magnitude faster.
This code (I used assembly because a compiler would
optimize away such a simple l
I'm announcing the release of pfft, a fast FFT written in D.
Code: https://github.com/jerro/pfft/
Downloads: https://github.com/jerro/pfft/downloads
Documentation: http://jerro.github.com/pfft/doc/pfft.pfft.html
Benchmarks: http://jerro.github.com/pfft/benchmarks/
On Friday, 20 July 2012 at 23:36:37 UTC, bearophile wrote:
jerro:
I'm announcing the release of pfft, a fast FFT written in D.
Everything looks nice. Are you using "in",
pure/nothrow/immutable/const enough?
Not yet, but I plan to add those.
Is it worth changing th
Are all your benchmarks done on a 64 bit system?
They are. Here's one comparison with 32 bit (for complex single
precision transform using sse)if you are interested in that:
http://imgur.com/CTuCD . The 32 bit executable is slower, probably
because there are less general purpose and SSE register
I think that poor precision is a problem. I have checked now and
std.numeric.Fft does indeed use floats for the lookup table.
The precision problem could be solved by either changing that to
real or by changing Fft to a template and using whatever the
type
parameter is. Just changing float to rea
This all is very interesting. Even considering all potential
issues and incompatibilities, it might be great to look into
integrating Fft into Phobos. Do you think it would work to add
it as a "high-speed alternative with different format and
alignment requirements"? Offhand I'd think someone u
Nice work.
Just did the usual advertising in HN and Reddit,
http://news.ycombinator.com/item?id=4286257
http://www.reddit.com/r/programming/comments/x2tt8/pfft_a_fast_fourier_transform_written_in_d/
--
Paulo
Thanks.
Other than that, you can bet that the usual + - / * operators
work and
produce the correct code on GDC, not sure on the state of DMD...
In my experience at least + - * work correctly with SIMD using
DMD.
So I think the next *big* step from here, in D3 or some other
D-derived
language, would be easing the creation of ranges. For example, a
special low-boilerplate syntax for creating bidirectional and
random-access ranges. Or for input (or maybe even forward)
ranges, a
C#-style compile-time transf
On Wednesday, 3 October 2012 at 06:15:32 UTC, jerro wrote:
So I think the next *big* step from here, in D3 or some other
D-derived
language, would be easing the creation of ranges. For example,
a
special low-boilerplate syntax for creating bidirectional and
random-access ranges. Or for input
Perhaps FSF would help or some other open-source funding
organisation?
Wouldn't FSF have issues with the reference implementation's back
end not being free software?
On Tuesday, 29 January 2013 at 16:34:15 UTC, Namespace wrote:
On Tuesday, 29 January 2013 at 15:19:37 UTC, David wrote:
Am 29.01.2013 16:10, schrieb Namespace:
Ahh. That could be a problem: I hate makefiles and never
wrote one.
Hehe,
to quote "ibuclaw":
`make no-sense`
It doesn't need to be
On Monday, 11 February 2013 at 21:06:41 UTC, FG wrote:
On 2013-02-11 21:37, Jacob Carlborg wrote:
On 2013-02-11 20:08, FG wrote:
I'm struggling with the temptation to move a Python website
to vibe.d.
What keeps me from doing that are Django templates. Not even
because
vibe's templates have to
19 matches
Mail list logo
