View mode: basic / threaded / horizontal-split · Log in · Help
January 24, 2013
Re: Trust about D programming.
On Thursday, 24 January 2013 at 03:59:17 UTC, Oleg Kuporosov 
wrote:
> On Wednesday, 23 January 2013 at 21:14:26 UTC, Paulo Pinto 
> wrote:
>
>> Many developers have no idea that modern CPUs do lots of 
>> things that invalidate the concept of C as a "high level 
>> assembler".
>>
>
> Paolo, the most important features of C makes it "high-level 
> assembler"
> it are pointer and its arithmetics. What hell "modern CPUs" 
> doing wrong with it?
>
> Thanks,
> Oleg.

Almost every language that compiles to native code as its default 
implementation, has some way of doing pointer manipulation, that 
is not what makes C a "high level assembler".

What used to give C such status as the almost one-to-one 
correspondence between what developers write and the 
corresponding Assembly instructions.

As many already answered before me, this one-to-one 
correspondence does not exist any longer.

--
Paulo
January 24, 2013
Re: Trust about D programming.
Am 24.01.2013 11:20, schrieb Walter Bright:
> On 1/23/2013 9:10 PM, Era Scarecrow wrote:
>>   I remember doing things like that. If I was dividing something by 8
>> I would
>> shift right instead by 3;
>
> Compilers were doing that optimization 35 years ago, and probably
> decades longer than that.
>
> Generally, if you're thinking about doing an optimization, it pays to
> check the output of the compiler, as it has probably beaten you to it :-)


It helps to have a broader experience in many languages.

I think C only developers tend to suffer from premature optimization 
disease. :)

--
Paulo
January 24, 2013
Re: Trust about D programming.
On Thu, Jan 24, 2013 at 05:34:52PM +0100, Paulo Pinto wrote:
> Am 24.01.2013 11:20, schrieb Walter Bright:
> >On 1/23/2013 9:10 PM, Era Scarecrow wrote:
> >>  I remember doing things like that. If I was dividing something by
> >>  8 I would shift right instead by 3;
> >
> >Compilers were doing that optimization 35 years ago, and probably
> >decades longer than that.
> >
> >Generally, if you're thinking about doing an optimization, it pays to
> >check the output of the compiler, as it has probably beaten you to it
> >:-)
> 
> 
> It helps to have a broader experience in many languages.
> 
> I think C only developers tend to suffer from premature optimization
> disease. :)
[...]

I remember being actually offended when I read about premature
optimization. I felt insulted at the idea that my hand-written code
could actually underperform what the compiler mechanically produces. Too
bad it's actually true. :-P

I later learned that my obsession with premature optimization distracted
me from actually thinking about the algorithms, so that I was spending
90% of my time optimizing the last CPU cycles out of an O(N^2) algorithm
when even a poorly-written O(log N) algorithm would have easily
outperformed my "optimized" code.

Not to mention the humiliation of discovering, when I actually profiled
my code, that the hotspots were nowhere near where I thought they were.
I had spent 90% of my time "optimizing" for a <1% gain, when a simple
algorithm fix at the real hotspot gained 20% instantly.


T

-- 
MSDOS = MicroSoft's Denial Of Service
January 25, 2013
Re: Trust about D programming.
On 1/24/2013 8:43 AM, H. S. Teoh wrote:
> I remember being actually offended when I read about premature
> optimization. I felt insulted at the idea that my hand-written code
> could actually underperform what the compiler mechanically produces. Too
> bad it's actually true. :-P
>
> I later learned that my obsession with premature optimization distracted
> me from actually thinking about the algorithms, so that I was spending
> 90% of my time optimizing the last CPU cycles out of an O(N^2) algorithm
> when even a poorly-written O(log N) algorithm would have easily
> outperformed my "optimized" code.
>
> Not to mention the humiliation of discovering, when I actually profiled
> my code, that the hotspots were nowhere near where I thought they were.
> I had spent 90% of my time "optimizing" for a <1% gain, when a simple
> algorithm fix at the real hotspot gained 20% instantly.

Don't feel bad. Everyone goes through that.

Keep in mind that people who are attracted to the dirty job of writing compiler 
back ends tend to be people who are old time assembler hackers, and they know 
the tricks of the trade. Naturally, they wire that knowledge into the compiler.

And they do learn new tricks all the time, and put those in, too.

It's like thinking you can buy a $10 gimmick from the auto parts store and 
increase your gas mileage 10%. Ain't gonna happen, the car makers aren't stupid.
January 27, 2013
Re: Trust about D programming.
On Wednesday, 23 January 2013 at 08:54:46 UTC, Paulo Pinto wrote:
>> Nothing like this here - you have all types, you have complete 
>> libm, libc and stdlibc++ with everything you need. There are 
>> no compiler extensions other than a typical GCC __attribute__ 
>> used to declare interrupts, which is not really necessary on 
>> most Cortex-M3 chips. These are really powerful chips with 
>> 1.25DMIPS/MHz and clocks around 70MHz (ranging from 24MHz to 
>> 204MHz)... There's even a dual-core chip - LPC43xx which has 
>> Cortex-M4F (with single precision hardware FPU and some SIMD 
>> instructions) and a Cortex-M0, both running at 204MHz <:
>>
>> So these are not very much like 8-bit microcontrollers (AVR, 
>> PIC, ...)
>>
>> That's why I think D would fit such chips quite nice (; Sans 
>> the GC of course... Maybe without exceptions too, but I don't 
>> think that would be possible (it's pretty hard in C++)...
>>
>> 4\/3!!
>
> Thanks for the valuable explanation.

The Cortex M4F based STM32F4 is an awesome ucontroller. It has 
192kb of RAM, up to 2Mb of Flash, a FPU, I2S, I2C, USART, 
ethernet, etc. And it costs a few $ only.

http://en.wikipedia.org/wiki/STM32#STM32_F4

You can play with one for about 20$ using the ST STM32F4 
Discovery board. Python (running on bare metal, no OS) has been 
ported to it.
If you really are serious with this ucontroller, you want to 
spend a few hundreds dollars and go with the Keil or Atollic 
toolchains, which bring IDE, debugger, desassembly, network 
analyzer, etc.
January 27, 2013
Re: Trust about D programming.
On Sunday, 27 January 2013 at 07:36:50 UTC, SomeDude wrote:
> If you really are serious with this ucontroller, you want to 
> spend a few hundreds dollars and go with the Keil or Atollic 
> toolchains, which bring IDE, debugger, desassembly, network 
> analyzer, etc.

1. Atollic is just Eclipse + GCC + GDB + some proprietary plugins.
2. Keil does not cost "a few" hundred dollars, unless by "a few" 
you mean "30" or something like that.
3. All the features you list are also present in open-source and 
free solutions.

4\/3!!
January 27, 2013
Re: Trust about D programming.
On Sunday, 27 January 2013 at 08:52:08 UTC, Freddie Chopin wrote:
> On Sunday, 27 January 2013 at 07:36:50 UTC, SomeDude wrote:
>> If you really are serious with this ucontroller, you want to 
>> spend a few hundreds dollars and go with the Keil or Atollic 
>> toolchains, which bring IDE, debugger, desassembly, network 
>> analyzer, etc.
>
> 1. Atollic is just Eclipse + GCC + GDB + some proprietary 
> plugins.
> 2. Keil does not cost "a few" hundred dollars, unless by "a 
> few" you mean "30" or something like that.
> 3. All the features you list are also present in open-source 
> and free solutions.
>
> 4\/3!!

1. it's a bit more than that.
2. a friend of mine bought the Keil development board. It's 
awesome, and it includes the toolchain. That one costs around 300 
euros.
January 27, 2013
Re: Trust about D programming.
On Sunday, 27 January 2013 at 15:01:51 UTC, SomeDude wrote:
> On Sunday, 27 January 2013 at 08:52:08 UTC, Freddie Chopin 
> wrote:
>> On Sunday, 27 January 2013 at 07:36:50 UTC, SomeDude wrote:
>>> If you really are serious with this ucontroller, you want to 
>>> spend a few hundreds dollars and go with the Keil or Atollic 
>>> toolchains, which bring IDE, debugger, desassembly, network 
>>> analyzer, etc.
>>
>> 1. Atollic is just Eclipse + GCC + GDB + some proprietary 
>> plugins.
>> 2. Keil does not cost "a few" hundred dollars, unless by "a 
>> few" you mean "30" or something like that.
>> 3. All the features you list are also present in open-source 
>> and free solutions.
>>
>> 4\/3!!
>
> 1. it's a bit more than that.

Whatever suits your needs - for me it's not much more than what I 
listed (; Most of that I can get for free.

> 2. a friend of mine bought the Keil development board. It's 
> awesome, and it includes the toolchain. That one costs around 
> 300 euros.

Ask him what the restrictions are, as I just don't see a 3000€ 
toolchain being included with a 300€ board... And - believe me - 
Keil DOES cost 3000€ (~4000$) - per year... In case it's just the 
regular demo version, you can download it from network.

http://pl.mouser.com/Search/Refine.aspx?Keyword=keil&Ns=Pricing%7c1&FS=True

standard one year license - 
http://pl.mouser.com/ProductDetail/Keil-Tools/MDK-PRO-T/?qs=sGAEpiMZZMvjj1qeIvr2hhBSab3Xr1Fj

4\/3!!
January 27, 2013
Re: Trust about D programming.
On Sunday, 27 January 2013 at 20:49:47 UTC, Freddie Chopin wrote:
> Ask him what the restrictions are, as I just don't see a 3000€ 
> toolchain being included with a 300€ board... And - believe me 
> - Keil DOES cost 3000€ (~4000$) - per year... In case it's just 
> the regular demo version, you can download it from network.
>
> 4\/3!!

It's a "MDK-Lite" version, whatever that means.

http://www.keil.com/mcbstm32F400/
January 27, 2013
Re: Trust about D programming.
On Sunday, 27 January 2013 at 22:35:21 UTC, SomeDude wrote:
> On Sunday, 27 January 2013 at 20:49:47 UTC, Freddie Chopin 
> wrote:
>> Ask him what the restrictions are, as I just don't see a 3000€ 
>> toolchain being included with a 300€ board... And - believe me 
>> - Keil DOES cost 3000€ (~4000$) - per year... In case it's 
>> just the regular demo version, you can download it from 
>> network.
>>
>> 4\/3!!
>
> It's a "MDK-Lite" version, whatever that means.
>
> http://www.keil.com/mcbstm32F400/

It does have some serious limitations: 
http://www.keil.com/support/man/docs/mcbstm32f200/mcbstm32f200_pr_mdk.htm
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home