Author Topic: The C barrier  (Read 4460 times)

0 Members and 1 Guest are viewing this topic.

Offline azyTopic starter

  • Full Member
  • ***
  • Posts: 107
  • Helpful? 0
Re: The C barrier
« Reply #30 on: November 20, 2010, 06:15:27 PM »
you misread what i wrote there"As far as basic one day being as fast as C"

I use freebasic which is compiled not interpreted.(faster than interpreted basics) in a couple of years time (due to moors law) it will be as fast as your C program is today....food for thought.

C on an old machine is slower than Freebasic on a modern machine...C's speed advantage is measured in years...which is a good way to look at it



Computer speeds have increased many 100s of times over the decades, from a measly  2mhz BBC 8 bit to 6ghz multicore multie threading 32 bit

http://en.wikipedia.org/wiki/BBC_Micro

pythone (which is dogslow) runs way faster  than assmbly on a BBC, an extreme example

 I doubt if C is 4 times faster than Freebasic , its certainly not 40 times faster

« Last Edit: November 20, 2010, 06:28:25 PM by azy »

Offline rbtying

  • Supreme Robot
  • *****
  • Posts: 452
  • Helpful? 31
Re: The C barrier
« Reply #31 on: November 20, 2010, 06:24:37 PM »
I migrated from BASIC to C in a week, and from C to C++ in six hours.  The only real difference for the programmer is the syntax, and if you've got documentation, syntax is just memorisation.  The real win for C/++, in my opinion, isn't the programming itself, but the ability to interface with hardware on a lower level of abstraction. 

Due to moors law[/b] and the current level of cpu power on desktops, for most apps the use of C is not critical. For smaller computing devices tight fast code makes all the difference. A program written in QBASIC running on fast desktop  runs faster than any code on a super computer built 25 years ago.  So in terms of speed C has an edge measured in years. I use freebasic which is compiled not interpreted. in a couple of years time it will be as fast as your C program is today....food for thought.

Under your hypothesis (which I'm not endorsing), the power of C(now) is equal to the power of QBASIC(now+25).  Since Moore's law is exponential, you can use a simple exponent rule to find out that the power of C is 225 * the power of QBASIC.  Kinda proves our point, doesn't it?

Also, compiled languages are NOT ALL ON THE SAME LEVEL OF ABSTRACTION!  The Freebasic compiler is implemented in C which is implemented in assembly which is implemented in machine code.  We KNOW that your freebasic is compiled, but EVEN SO, C is always faster. 

C on an old machine is slower than Freebasic on a modern machine...C's speed advantage is measured in years...which is a good way to look at it
See above for my mathematical version of your statement.  Also, your comparison lags behind by 25 years... A little long? 

Offline Razor Concepts

  • Supreme Robot
  • *****
  • Posts: 1,856
  • Helpful? 53
Re: The C barrier
« Reply #32 on: November 20, 2010, 06:59:46 PM »
I honestly can't figure out how to install freebasic. So much for ease of use.

I got the .exe file, and went through the installer, but after its done I can't find the actual .exe file to run it. I get a fbc.exe, but it doesn't do anything.

Now I'll start a multi page rant about how basic sucks  ;D

Offline azyTopic starter

  • Full Member
  • ***
  • Posts: 107
  • Helpful? 0
Re: The C barrier
« Reply #33 on: November 20, 2010, 07:02:54 PM »
you need an IDE for freebasic, have to dload and install it separately (stupid they dont make it obvious...slaps FBASIC community)

Info on IDE's for it
http://www.freebasic.net/forum/viewtopic.php?t=10350

http://fbide.freebasic.net/

btw, a lot of C guys actually like a bit of FB :-*

http://en.wikipedia.org/wiki/FreeBASIC
« Last Edit: November 20, 2010, 07:08:38 PM by azy »

Offline Razor Concepts

  • Supreme Robot
  • *****
  • Posts: 1,856
  • Helpful? 53
Re: The C barrier
« Reply #34 on: November 20, 2010, 07:10:48 PM »
So, I have two lines of code:
Code: [Select]
Print "hello world"


It compiles fine, but when I click the run button (using fbedit) nothing happens.  :P

EDIT: I think its my lame programming skills. trying fbide now.
« Last Edit: November 20, 2010, 07:13:35 PM by Razor Concepts »

Offline azyTopic starter

  • Full Member
  • ***
  • Posts: 107
  • Helpful? 0
Re: The C barrier
« Reply #35 on: November 20, 2010, 07:13:45 PM »
I think u gotta reboot after installing it , initialise dlls or something. Ive never had any probls with it,
« Last Edit: November 20, 2010, 07:18:01 PM by azy »

Offline Razor Concepts

  • Supreme Robot
  • *****
  • Posts: 1,856
  • Helpful? 53
Re: The C barrier
« Reply #36 on: November 20, 2010, 07:21:44 PM »
Cool, got fbide working now. So I tried this piece of code:

Code: [Select]
main:
print "hello world"
print Timer
Dim counter As Integer : counter = 0
Dim a As Double: a = 0.0
Dim b As Double: b = 0.0
a = Timer
do while counter < 1000000
    counter+=1
loop
b = Timer
print b-a
do while counter > 1
 
loop
end
And got around 0.0098 seconds runtime,, which was ten times better than a python program  I tried. But then I got rid of the do-while loop, and replaced it with counter = 1000000, and I got the same times around 0.0098. So looks like the compiler optimizes it, and we can't really do a true speed test. I'll try and find a way to stop optimization?

Offline azyTopic starter

  • Full Member
  • ***
  • Posts: 107
  • Helpful? 0
Re: The C barrier
« Reply #37 on: November 20, 2010, 07:24:53 PM »
This Freebasic program (in qbasic compatibilty mode) takes 4 seconds to run....the print to the screen slows stuff down a huge amount (winxp sp2 celeron 2600 ghz 5yr old design)

'$lang:"qb"
input "press enter to start"; a$
for i =1 to 10000:print i:next i
 print "done",i
sleep


my modern netbook N450 Atom 1.6ghz is noticably faster, the architecture surounding the cpu being more efficent

---------------------------------------------------------------------------------------------------------------
I actually wrote a program consisting of ten thousand if then statements in a row as a test, took Fbasic just over a second to wade thru it. the right answer being found at the tenthousand'th if .
« Last Edit: November 20, 2010, 07:48:00 PM by azy »

Offline azyTopic starter

  • Full Member
  • ***
  • Posts: 107
  • Helpful? 0
Re: The C barrier
« Reply #38 on: November 20, 2010, 08:02:21 PM »
Freebasic Vs C  , speed shoot out result

fastest BASIC FreeBASIC program used compared to the fastest C++ GNU g++ program.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=fbasic&lang2=gpp

Offline Cannon00

  • Jr. Member
  • **
  • Posts: 7
  • Helpful? 1
Re: The C barrier
« Reply #39 on: November 20, 2010, 08:21:23 PM »
Quote
REF Vision, all the methods are out there, a computer is capable of seeing and understanding the world through sight far better than any human. Its a matter of processing power and developing the technology (best written in C due to the computation required).

I think you're overestimating what kind of systems are out there and would be easily adaptable.  The fact that the darpa grand challenge really is a *grand challenge* is a pretty good indication of where computer vision systems are right now.  Creating a robot car that can navigate a path of natural terrain is a pretty small task compared to identifying and interacting with the entire world, yet for highly trained and highly skilled individuals competing in the grand challenge this is still typically quite hard.  I stand by the idea that perceiving and understanding the world is the greatest difficulty for making a robot to interact with the real world right now.  Once you have something categorized, such as things are in a virtual world, it's easy to interact with it.  In essence, that's what the artificial intelligence in every video game is doing.  But those ais wouldn't do well in the real world because it is so diverse, and so immensely difficult to categorize and understand the array of things you encounter in everyday life.  This problem is also inherently related to how we can program it, and how we will interpret the incoming information from sensors.  Making your brain system see, understand, and interact with the world is no small problem.  It is the ultimate problem.  

Offline voyager2

  • Supreme Robot
  • *****
  • Posts: 459
  • Helpful? 6
  • Behold! The Impossible Triangle of robotics!
Re: The C barrier
« Reply #40 on: November 20, 2010, 08:36:24 PM »
I will also say it took me just 2 hour s to start with C, most of that was waiting for things to install!
And Admin said "Let there be robots!"
And it was good.

Offline Soeren

  • Supreme Robot
  • *****
  • Posts: 4,672
  • Helpful? 227
  • Mind Reading: 0.0
Re: The C barrier
« Reply #41 on: November 21, 2010, 06:17:06 AM »
we should do a speed test  AND SETTLE THE MATTER,  write a short simple bit of code and time it, something like

input "press enter to start"; a$
for i =1 to 10000:print i:next i
print "done"
That wouldn't show anything but how each program handles screen output and since this is a bottleneck to any programming language, it would falsely claim a much smaler difference.

A slightly better test would be:
T=Time
A=0
FOR i = 1 to 1000000
  A=i^(i/10000)
  IF i MOD 100 THEN INCR A
NEXT I
T=Time-T
PRINT "Done in:"; T; "seconds"

But even if some calculations is included and the screen output bottle neck is removed, it's not a very full test and would say nothing but how these exact algorithmic elements run.


Anyway, trying to make AI, you need a much wider perception of the human brain.
Human intelligence is not just number crunching (or computers would have been way ahead of us already) or imaging (where computers still have a long way to go - like decades).

As long as nobody can get a wrap on the exact nature of intelligence, AI will be a futile goal for even the best researchers.

And as long as you code as unreadable, with multi-lines coupled together, I really cannot see you code that much more than simple "count up and print to screen apps", since it will be impossible to go back and understand that code after a short while.
Sure, writing nice code takes a bit longer and so does adding legible comments, but it's the key to anything but hobby coding of 10 line programs.
Regards,
Søren

A rather fast and fairly heavy robot with quite large wheels needs what? A lot of power?
Please remember...
Engineering is based on numbers - not adjectives

Offline z.s.tar.gz

  • Supreme Robot
  • *****
  • Posts: 540
  • Helpful? 5
  • Linux Guru
Re: The C barrier
« Reply #42 on: November 21, 2010, 08:33:53 PM »
It's not the language that matters, but the program. You can have bloated assembly or super optimized C and it really doesn't matter if neither of them work.
I'm gonna have to take the "right tool for the job" approach with this.

(ps, freebasic looks like the biggest load of crap I've ever seen, so how's that for basic being better?)
Save yourself the typing. Just call me Zach.

Offline Tommy

  • Full Member
  • ***
  • Posts: 110
  • Helpful? 3
Re: The C barrier
« Reply #43 on: November 23, 2010, 05:17:48 AM »
Quote
I'm 100% sure this thread is off topic now but really who wants to get back to the topic?
I'm not real sure the point of the OP of this topic(other then C can be a pain), or that this topic is of any value.
but Soeren's last line made it all worth reading.

Quote
it's a very big misunderstanding to think that robots should be shaped like humans. It's inefficient and wanting that just reveals a sort of God complex, which might be cured with regular doses of lithium and beta blockers.

Sweet line Soeren, I hope someday to be able to use it.

Tommy
All opinions expressed are mine alone, and subject to change as information is gained.
« Last Edit: November 23, 2010, 05:20:54 AM by Tommy »

Offline macdad-

  • Robot Overlord
  • ****
  • Posts: 131
  • Helpful? 5
Re: The C barrier
« Reply #44 on: November 29, 2010, 10:29:02 PM »
Nonsense.
It takes a certain way of thinking to program!
It helps immensely to know how the hardware works, but once you know the logic behind coding, any new language is just adding meat on the skeleton.

Agreed, I'm more of a hardware guy anyways, knowing what's doing what is a process that many, if not all do when programming. If your a software guy then you think conceptually with a "virtual workbench" as long as you know the hardware confines of said workbench. Hardware guys work with a different perspective, as you know that so-and-so variable is being stored in such-and-such register, etc. (I'm not being biased to one or the other).

I'm usually accused with having a backwards programming stance: I learned asm first and now I can't for the life of me understand why anyone would use C.
Right, its just getting the "feel" for the programming environment and then sticking or changing to a different language. The first language that I "coded" in was ironically AppleScript, but that was what stuck with me, as I quickly learned BASIC(That I program my BS2 in). Even though my teacher had a copy of Borland C that I used, I couldn't get it down. I eventually started using Assembly for Programming the SNES. As I find there is a kind of gap between programming in Asm and BASIC. Its just the learning curve of bridging the two, through datasheets, instruction sets, etc. All depends upon what works for you.

Hi,

Yeah, I had the same thoughts of the claimed amount of data and I think it's sad when a grown man is so lonely, that he feels a need for exaggerating to such levels, that the "artistic freedom" is not only visible, but hitting you so hard that it takes a blind person to eat it.

Posts telling "I have no experience with hardware" is fading into "I did a linefolliower in eighty-something" etc. etc.
If a lie is to be believable, it has to be at least barely plausible - too bad it's so hard to post some of the code - oh, I forgot... No lesser part of the code will reveal the ingenious brain  :)
So, this brain, who's single parts hasn't got anything worth coming after, magically wakes and works in ways that the software wouldn't reveal, when all the text files flies around.

I don't find it hard to swallow, not at all... I simply don't believe a single bit of it unless some proof is posted (i.e. not what some scientist has posted about some theories, but real code that can be verified.


That's why Pseudo-Code/Fuzzy logic is always helpful. If you don't know what your goals are then what the heck are you doing!?  ;)


 


Get Your Ad Here