OCCRA
Go to Post The teams that do the right thing for the sake of doing the right thing, and for believing in the message of FIRST deserve to be recognized. - Madison [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 08-02-2012, 01:02 PM
daniel_dsouza daniel_dsouza is offline
does what needs to be done.
FRC #2449 (Out of Orbit Robotics)
Team Role: Alumni
 
Join Date: May 2011
Rookie Year: 2011
Location: Chandler, AZ
Posts: 231
daniel_dsouza has a spectacular aura aboutdaniel_dsouza has a spectacular aura about
C++ vs. Java (speed considerations only)

Hello CD,

I'm told that code written in C++ will run faster than Java code. My question is, how much faster, and under what conditions will it be noticeable? I'm especially interested in situations where teams have used both C++ and Java environments (at different times of course).

A large speed advantage from C++would be the only reason we would switching (we use Java now), as there really aren't too many other benefits to C++.

Thanks,
Daniel
  #2   Spotlight this post!  
Unread 08-02-2012, 03:23 PM
JesseK's Avatar
JesseK JesseK is offline
Expert Flybot Crasher
FRC #1885 (ILITE)
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2005
Location: Reston, VA
Posts: 3,972
JesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

My professional answer is: it depends. For generic software that doesn't use specific hardware implementations, the results aren't quite as intuitive since post-JIT processing will be at least as fast as C++ (i.e. after the same cycle has run a few times).

For hardware-based operations (OpenGL, OpenCV, custom hardware interfaces like radios) C++ is typically faster latency-wise, yet processing wise it's the same as Java. This is only due to the JNI code layer, and is implementation dependent (i.e. most of the time it isn't a noticeable difference unless you're shoving MB's of data through the code per second).

Bad programming practices will cause more performance issues on an FRC bot than the language choice.

Some articles:
http://vanillajava.blogspot.com/2011...-for-high.html
http://vanillajava.blogspot.com/2012...revisited.html
http://vanillajava.blogspot.com/2012...s-in-java.html
http://vanillajava.blogspot.com/2011...llions-of.html

And the article to make contraversy:
http://vanillajava.blogspot.com/2011...er-than-c.html
__________________

Drive Coach, 1885 (2007-present)
Latest Project: Codex-based FRC Comms in Java

2017: Scoring Model | COPR Rank Simulator
1885: YouTube Channel | CAD Library | GitHub

Last edited by JesseK : 08-02-2012 at 03:26 PM.
  #3   Spotlight this post!  
Unread 08-02-2012, 03:43 PM
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,253
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

Have you run into a CPU ceiling? If not, what's the point of switching?

I've used both and I must say that I've found Java to be a more pleasant experience for FRC. It was easier to get students involved and learning, I could run it on my mac without a problem, and the speed of development was just WAY faster (less boilerplate, Eclipse/NetBeans are fairly good at autocomplete, etc).
  #4   Spotlight this post!  
Unread 08-02-2012, 03:53 PM
Jon Stratis's Avatar
Jon Stratis Jon Stratis is offline
Mentor, LRI, MN RPC
FRC #2177 (The Robettes)
Team Role: Mentor
 
Join Date: Feb 2007
Rookie Year: 2006
Location: Minnesota
Posts: 4,362
Jon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by Tom Bottiglieri View Post
Have you run into a CPU ceiling? If not, what's the point of switching?
+1

There are certainly reasons for a team to consider switching programming languages, and it really is great that we have the option to use Java, C++, or LabView. However, there is also the old adage, "If it ain't broke, don't fix it!"

Your best bet to examine the differences is to re-write last year's code in C++, then do some testing yourselves. Does the robot work better?

In my opinion, you'll see more benefits from knowledge and experience (development time, debugging, etc) in Java than you would ever see in performance from switching languages.
__________________
2007 - Present: Mentor, 2177 The Robettes
LRI: North Star 2012-2016; Lake Superior 2013-2014; MN State Tournament 2013-2014, 2016-2017; Galileo 2016; Iowa 2017; Tesla 2017
2015: North Star Regional Volunteer of the Year
2016: Lake Superior WFFA
  #5   Spotlight this post!  
Unread 08-02-2012, 08:36 PM
daniel_dsouza daniel_dsouza is offline
does what needs to be done.
FRC #2449 (Out of Orbit Robotics)
Team Role: Alumni
 
Join Date: May 2011
Rookie Year: 2011
Location: Chandler, AZ
Posts: 231
daniel_dsouza has a spectacular aura aboutdaniel_dsouza has a spectacular aura about
Re: C++ vs. Java (speed considerations only)

Thanks guys,

There were a few members who wanted to use C++ for our language next year, but I think we will stick with Java. But there is still the off-season to experiment.
  #6   Spotlight this post!  
Unread 08-02-2012, 09:35 PM
Hjelstrom's Avatar
Hjelstrom Hjelstrom is offline
Mentor
FRC #0987 (High Rollers)
Team Role: Mentor
 
Join Date: Mar 2008
Rookie Year: 2005
Location: Las Vegas
Posts: 173
Hjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

If you were going to try to achieve high-framerate vision processing on the cRio then C++ might be a good choice. Other than that I would recommend sticking with JAVA. Nothing else you would do on a robot should come close to taxing the cpu in JAVA.

Now that you can offload the vision processing to your driver station (e.g. see the paper released by 341 and the cookbook from WPI) you really don't need to do it on the cRio anyway. There are some of other advantages to doing the vision processing on your driverstation too such as being able to see what its doing :-)
  #7   Spotlight this post!  
Unread 08-02-2012, 11:20 PM
wilful's Avatar
wilful wilful is offline
766 Alum & 4212 Mentor
FRC #4212 (TechnoFerrets)
Team Role: Mentor
 
Join Date: Jan 2009
Rookie Year: 2009
Location: Planet Earth
Posts: 69
wilful will become famous soon enough
Re: C++ vs. Java (speed considerations only)

If you don't know already, Labview has MAJOR lag problems, especially with relays. This year, the code that came with Labview for the relays was unusable and we were forced to write our own. This prevented us from competing in most of our matches at the Sacromento regional. So if you are looking for processing speed, don't use labview.
__________________
Wilful
2009-2013 Student, FRC 766
2013-Present College Student and Mentor, FRC 4212
  #8   Spotlight this post!  
Unread 08-03-2012, 06:37 AM
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,835
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

If you believe you have found a bug with relays in LabVIEW, can you please be more specific? What workaround "fixed" the problem?

Each of the languages use the same integrated tests to verify correct operation and we each have tests for performance as well. LabVIEW is in fact a compiled language, like C++, but very different in that it is dataflow. Many teams used LabVIEW this year, and we don't have reports of lag everywhere or lag in relays. Details please. Since this isn't on topic, feel free to PM me.

Greg McKaskle
  #9   Spotlight this post!  
Unread 08-03-2012, 06:00 PM
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Clarkston, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by wilful View Post
If you don't know already, Labview has MAJOR lag problems, especially with relays. This year, the code that came with Labview for the relays was unusable and we were forced to write our own. This prevented us from competing in most of our matches at the Sacromento regional. So if you are looking for processing speed, don't use labview.

There are two things that are REALLY slow in LabVIEW:

-VI calls through the normal "execution system" when they should be Subroutines or Inlined. The majority of the WPIlib suffers from this problem, unfortunately. The normal execution system is designed for heavily multitasking systems and systems with many concurrent processes. It treats each VI as an independent node in the execution system, unless it is flagged as Subroutine (or Inlined at compile time), which isn't very efficient. When properly written, LabVIEW code is far easier to multitask without much overhead.

-Programmers writing code while thinking procedurally. Thinking functionally is much better in LabVIEW (and even better in Simulink and more hardcore dataflow and modeling languages). That said, I still firmly believe it's better for programmers to know multiple languages and paradigms, as it will help you better choose the correct language and environment for a challenge.

As for C++ vs Java, non-JIT Java code will be slower. For completely personal reasons, I am a fan of purely procedural C programming for embedded systems.

I am also quite unimpressed by the timing jitter I got in LabVIEW. The RT threads are able to hold very tight timing, but at fairly significant CPU expense.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
  #10   Spotlight this post!  
Unread 08-03-2012, 10:43 PM
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,835
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

This is what the cockpit of fighter planes look like.

This is what the cockpit of a Cessna looks like.

Is WPILib meant to be a fighter or a Cessna or somewhere in between? In all three languages, it steers away from advanced features, and the APIs do lots of parameter checking and error reporting. WPILib is not the ultimate example of performance techniques for any of the languages.

Quote:
... The majority of the WPIlib suffers from this problem, unfortunately. The normal execution system is designed for heavily multitasking systems and systems with many concurrent processes. It treats each VI as an independent node in the execution system, unless ...
I'll argue that WPILib doesn't suffer from this. The goal was to make teams successful writing code to safely control an FRC robot. Much like the HW kit of parts, it isn't a turnkey robot SW solution, but instead offers relatively safe and straightforward components that can be combined in many ways. It is shipped as source where possible and often with debugging in place in order to allow safe exploration even to the point of making optimizations and other modifications. Just because the Cessna doesn't have the same cockpit as the fighter doesn't mean it failed at its intended purpose.

As for the LabVIEW execution system, I'll be happy to answer questions on how it operates. VI calls and Subroutines are closely related and both introduce overhead. In return, you gain code reuse and abstraction. I do not agree they are REALLY slow.

Just as a multitasking OS makes sense on a single core computer, so does a multitasking language. LV doesn't just treat VIs as independent nodes, it treats loops and other code clumps containing asynchronous nodes as independent nodes -- because they are. They are asynchronous. Lumping them together amortizes scheduling overhead but risks unnecessary blocking. This is the juggling act that the OS and the LV scheduler and clumping algorithm perform. All the languages support multitasking, but do so differently.

Summary?
All three languages are fast enough if used properly, and not nearly fast enough if used improperly. All are used in industry in performance demanding and time critical applications and are used by large numbers of FRC teams. There are many ways to choose the language(s) you want to learn. Performance shouldn't be the sole reason.

Greg McKaskle
  #11   Spotlight this post!  
Unread 08-03-2012, 07:11 AM
ttldomination's Avatar
ttldomination ttldomination is offline
Sunny
no team
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2007
Location: Roanoke, TX
Posts: 2,074
ttldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond reputettldomination has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by daniel_dsouza View Post
Thanks guys,

There were a few members who wanted to use C++ for our language next year, but I think we will stick with Java. But there is still the off-season to experiment.
This is interesting, but it's important to take note of why they're suggesting it. If the members want to move over because they feel like they would be more comfortable in that environment/they have more experience in that environment, then this merits further thought.

And definitely look into off-season testing. We're going through similar changes so we're looking forward to taking full advantages of this fall to make a smart, informed decision.

- Sunny G.
__________________
1261: 2007-2012
1648: 2013-2014
5283: 2015
  #12   Spotlight this post!  
Unread 08-04-2012, 02:15 AM
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 307
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by daniel_dsouza View Post
Thanks guys,

There were a few members who wanted to use C++ for our language next year, but I think we will stick with Java. But there is still the off-season to experiment.
I'd like to share with you an email my boss sent to me some time ago... this goes beyond robotics in our professional world of application development, but I think it would be good to know why some people use c++. I started with BASIC and then learned 6502 assembly... then finally came around to c++ here goes:

Programming language wars are about the same as religious wars ... everyone believes that their chosen favorite(s) are the only ones that make sense and I am certainly going to wade into this argument because at the end of the day any language that provably obeys the basic axioms of computation can all technically perform the exact same operations.

The above said,a couple of observations.


1. The world is built on-top of C (++) and so while other languages might be good at expressing some things "better",at the end of the day C and C++ seem to fill some magic middle ground between assembly and higher level languages. Every major app you use,every OS,even the C# run-time and compilers are all written in C(++). The same is true of every video codec,every piece of firmware (your fridge,phone,car,planes,etc...),your web browser and whatever UI control you are reading this in,etc...

2. As an illustration of the importance of C(++) every major change in hardware architecture first adopts and uses C-like languages and not others. Every GPU language (that has been adopted) is based on C,as is OpenCL,most HW description languages,etc...

3. In the real world,if you are going to implement an API that anyone else can use, it needs to be C. This is still the uniformly accepted standard for libraries and for good reason. Try using a C# library in C or Fortran. Now try a C library.

4. A few years ago I decided that we needed to move our Ui development to C# in the belief that some of the higher level programming concepts would help make development more robust by not having the same issues that C(++) has with manual memory management,etc... In practice (and some of this might be down to the fact that C(++) programmers and C# programmers tend to be at different skill levels on average) we have found that our Ui code has far more bugs is less stable and harder to debug than our C(++) code.

5. I am not an expert on the tools,but while there are good C# tools,it suffers at a disadvantage of only having been around for a fraction of the time of C(++). Whenever I am working on C# code I simply cannot believe that there is no compile and continue support,etc... Likewise you are not going to find the long history of proven tools for any language other than C in terms of profiling (yes some C# ones exist but they are quite frankly not at the same level),code verification,code documentation,distributed compilation,etc... etc...
  #13   Spotlight this post!  
Unread 08-04-2012, 08:52 AM
Todd's Avatar
Todd Todd is offline
Software Engineer
FRC #1071 (Team Max)
Team Role: Mentor
 
Join Date: Feb 2005
Rookie Year: 2004
Location: Connecticut, Wolcott
Posts: 64
Todd has much to be proud ofTodd has much to be proud ofTodd has much to be proud ofTodd has much to be proud ofTodd has much to be proud ofTodd has much to be proud ofTodd has much to be proud ofTodd has much to be proud ofTodd has much to be proud of
Re: C++ vs. Java (speed considerations only)

*Ahem*

Beating a dead horse, that was dead a long time before FIRST robotics came around, but throwing in my two cents anyways.

In FIRST robotics, for the applications we develop, if you're concerned with efficiency, then it doesn't matter really at all whether you use labview, c++, or java.

All three are more than sufficiently tight to handle any application a FIRST robot utilizes, so long as it's written correctly.

So long as it's written correctly being the key statement.

I recommend using whatever language your team has the most experience with, or your mentors are most familiar with, or at the worst case, just the one you feel like you want to learn. Hell, take a year and write your robot code from that year in all three and pick one based on just your personal impressions if you want, but keep in mind, if it's slow, if your CPU is capped and your logic isn't getting executed on time, it's very, very, very likely that you're doing it wrong, rather than the language is to blame.

And if someone comes along and mentions something akin to 'all the best teams on Einstein seem to be using c++', don't forget that a lot of the teams on Einstein are either senior teams, who used to HAVE to develop in C, and so already had experience with that when it came to picking between c++ or labview, or have great mentors, and mentors who were probably born in the 50's-80's are much more likely to have C++ experience than java or labview experience, and mentors born from the 70's-80's are much more likely to have java experience on top of c++ experience, but still very little labview, just because it's relatively young and has historically had very specific market exposure.

In my work place we use C, C++, Ada, Java, Labview, and many others, and all are slightly better or more convenient for certain things, but what's most important in every application is that you use something your team is comfortable with, because the great deal of real world efficiency problems are caused because the developer that wrote the functionality didn't realize they could have made it faster if they implemented it slightly different, and are entirely the developers 'fault'.
  #14   Spotlight this post!  
Unread 08-07-2012, 09:39 PM
drakesword drakesword is offline
Registered User
AKA: Bryant
FRC #0346 (Robohawks)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: USA
Posts: 200
drakesword is on a distinguished road
Re: C++ vs. Java (speed considerations only)

[quote=JesseK;1180245]My professional answer is: it depends. For generic software that doesn't use specific hardware implementations, the results aren't quite as intuitive since post-JIT processing will be at least as fast as C++ (i.e. after the same cycle has run a few times).

For hardware-based operations (OpenGL, OpenCV, custom hardware interfaces like radios) C++ is typically faster latency-wise, yet processing wise it's the same as Java. This is only due to the JNI code layer, and is implementation dependent (i.e. most of the time it isn't a noticeable difference unless you're shoving MB's of data through the code per second).[quote]

I agree with you on the first part. The second part I very muc disagree with the MB's of data. I work for a company that does e-discovery. Our main processing system is entirely java. It is able to process Almost 100gb per hour depending on the media. Just today we processed 1.2GB of mail storage in 45 seconds.
  #15   Spotlight this post!  
Unread 08-07-2012, 10:49 PM
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 307
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by drakesword View Post
I agree with you on the first part. The second part I very muc disagree with the MB's of data. I work for a company that does e-discovery. Our main processing system is entirely java. It is able to process Almost 100gb per hour depending on the media. Just today we processed 1.2GB of mail storage in 45 seconds.
How do you define processing? Any language can do simple tasks like data transfer with simple logic instructions... but its another thing where you really process the data that requires inner loops (e.g. 3d rendering, Audio/Video effects processing). With c++ you can use inline assembly and use intrinsics that explicitly choose what assembly instructions to use. You can for example do prefetching to ensure the P and V pipes are always full in an inner loop. Back in the eary 2000-2004ish... we also had to be responsible for scheduling instructions to ensure that we didn't get penalized for branch predictions failing, or put two divides too closely together by squeezing in some lightweight instructions like 'and', 'or', or even adds, or ensure we cycled through each mmx/sse instruction register (it was crazy). Around 2005-2008 Visual Studio mastered the intrinsics to have a competitive optimization of the instruction scheduling. Furthermore you can do things like this http://www.jaist.ac.jp/iscenter-new/...2_hh/vc235.htm. Really now... when you speak of real processing power, consider what language they used to land the Mars Curiosity Rover.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 02:57 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi