Friday, April 19, 2013

Multi-Core Computing

Most modern Central Processing Units (CPUs) are multi-core, and are advertised as such. For example, Intel's processors are usually advertised as "Intel i3 Dual-Core Processor" or "Intel i5 Quad-Core Processor" and even more recently they now have "Intel i7 Hexa-Core Processor." These processors can get a bit extreme, but what does it really mean, let's say, to run a Hexa-Core Processor? Well, on the right you can see a hand-drawn example of a single-core of a CPU, this core can execute a certain number of operations-per-clock-cycle (which used to be 1, but has since increased). Operations can be in the form of a logical operation (like ADD, AND, or XOR) on two binary values of a certain size and then reporting the result to wherever it needs to be. There are many different forms of CPU operations, but most of the actual computing is spent doing the previous example. Processing is just a bunch of math. Adding a second core to a CPU, as you should expect, can theoretically double your operations-per-clock-cycle value. Adding four can quadruple that value. Adding six can sextuple it, and so on and so forth. Within the last year, an exciting new engineering startup company by the name of Parallella began work on a 64-core processor, connected in a square matrix and multiplexed together. The future of multi-core computing is definitely an exciting one.

So at this point, it seems like the more cores, the better. Right? Not exactly, as there are many complications when it comes to programming for multi-core architectures. As an example, take a simple fibonacci sequence calculation. Inside the main loop, the current calculation, which is to add the two previous numbers, relies on the two previous numbers to already have been calculated, and so on and so forth. This greatly limits the amount of multi-tasking that is possible. So computer programs need to specify when multi-core, or "threaded" operations is allowed.

Below are two graphs showing ASU's computer's cores and their usage in a percentage. The graph on the top was recorded during testing of C++ programs, and on the bottom are Java Programs.

CPU usage per core during testing of C++ Applications


CPU usage per core during testing of Java Applications
So, clearly, there are staunch differences in these two pictures. So what exactly is happening that is causing these differences? 

Well, the difference lies in the languages. C++ requires the programmer to explicitly say when operations can be threaded, and when no specific allowances are written, no multi-core optimization takes place. On the contrary, Java allows the programmer to define specific threaded operations, but it does not require that in order to use multi-core optimization. Java's VM will run on multiple cores and distribute operations as they are compiled and executed. So, in conclusion, while C++'s graphs look clean and tidy, and Java's look like a mess, Java is actually optimizing it's code and taking more advantage of the CPU's architecture. 

So now I need to mention the program samples I ran. The CSE students wrote the programs to perform correctly, not efficiently. Maybe some over-achievers might optimize their code, but most students would just try to make the program do what it is supposed to, and when that works they turn it in. If this code were written by an actual software company, like Microsoft or Apple, they would almost certainly invest time in optimizing their code with multiple core architecture in mind. Students on the other hand, would not. 
This brings to mind some pros and some cons. On one hand professional companies have slightly more control over threaded optimization using C++, but on the other hand Java's automatic optimizations make programming much more convenient and can cut down significantly on runtimes of programs that maybe were written by one programmer who otherwise wouldn't have had the time to program lines and lines of code for threaded optimizations.

Of course, this topic will be more deeply analyzed and explained in my upcoming presentation.

Thanks for reading.
- Jeff 

Friday, April 12, 2013

Debugging: What is it?

Debugging is the process of removing "bugs" from code. There are many different ways to do this, and sometimes it can be a long, drawn-out, and frustrating struggle. The problem is: everybody makes mistakes. No one can sit down and write 1000+ lines of code without something going wrong and misbehaving. What distinguishes good coders from great coders, among other things, is their ability to debug. Over the past few weeks I have been doing a lot of debugging, and I have been working on my techniques. I have been getting faster and faster at identifying the root of the problem. There are a few ways that I have become familiar with to watch your code as it executes.

For code with lots of conditional branching, when something goes wrong, you need to know exactly where something goes wrong. In this case, a programmer can insert code that writes to the console at specific points in their code in order to follow-along. I am quite fond of just printing single "*" characters or maybe "+" or "-" characters after condition checks, this allows me to tell exactly which branch of code is being executed when the undesired behavior occurs.

Another way to do this is to print out all the objects involved in an event, and do the condition checks manually. This process can be quite tedious because the programmer needs to define how the object "prints" in text. But thanks to Eclipses' brilliant generate toString() functionality, this process is pretty pain-free.

The last process I have been using to debug my code is really only useful for visual programs such as my Physics Engine. I have defined a few methods in my Entity class that allow me to draw either the entity's previous path or the entity's velocity vector, or both. This allows me to visually watch what is happening behind-the-scenes of my application. In this picture, you can see the path and the velocity vectors of the balls, along with their direction, converted to degrees and printed above their image for clarity. This allows me to slow down their motion, and carefully watch their behavior. This technique has come in quite handy, as I've recently discovered and fixed more than a few minor bugs in my program.

Thanks for reading!

-Jeff

Wednesday, April 10, 2013

More Work on Collisions!

Scrawlings of a mad man
I have been struggling to successfully implement collisions between objects in my physics engine. It turned out a lot harder than I originally thought it would be. So after many revisions and a hours of frustration, I decided I needed to just sit down and write everything out. On the right is a picture of my desk, taken from my phone. This is how I tested out different mathematical algorithms and discerned which ones work all the time, which ones work some of the time, and which ones don't work at all. Writing down everything certainly helped my thought process, but I suspect that my peers here at ASU now think I am insane.

The red ball was placed 1 unit to the left of the blue one.
Here's what I managed so far. I have written a function of the Entity class that takes the angle of incidence of a collision and calculates its new angle for movement. This method took ages to get right, and now works on all 360 degrees. I have yet to add a dampening force yet, so currently the collisions seem overly explosive, but I'll get to it eventually! I have also written an event handler for the collision event which calculates the angles of incidence of both entities and calls their respective functions. This handler, however, needs a lot of work, because after only a little testing I have found some strange issues that most likely stem from there being no delay between bounces. Sometimes this results in the balls getting stuck inside of each other and weirdly vibrating off of the screen. A rather traumatic bug if you ask me. Here's a screenshot of a successful collision! Woo!


As always, thanks for reading!

- Jeff

Friday, April 5, 2013

Standardized Engines

Since I will be writing two copies of my physics engine, one in Java and one in C++, myself and my professor have found it necessary to attempt to keep the programs relatively similar. This will allow for the visual segment of my presentation to be as accurate as possible.  Dr. Bazzi asked me recently if I had based my programs on any standard foundations.  And I figured the best way to do that would be to keep the programs as true-to-life as possible, and avoid any over optimizations. The programs' calculations will be based on floating point calculations of the kinematic equations. These equations will keep the behavior of the objects in my engine as real-life as possible, and the floating-point variables will keep the values highly accurate. I will try to keep these physics calculations the bulk of the program's performance. In this way, I can maintain a relatively similar program between two different programming languages. The reason that is necessary is so that the comparisons between the two programs are relatively fair and equal, as we will be doing the same benchmark tests on them both.

I am aware things are getting quite technical as we approach the end of the project and begin work on the presentation. Thanks for reading.

- Jeff

Friday, March 29, 2013

Entity Collision


So I have been working on my Physics Engine recently, and I've happened upon a rather interesting conundrum. In logic, it is rather simple to detect when an falling entity collides with a box; It's easy tell when the ball hits the ground. However, it is not at all easy to tell when a ball hits another ball, the algorithms just don't work that way. After a little bit of research, I have discovered that no Java library handles anything to do with collision boxes of circles, and I have to write my own. My approach right involves a rather tedious and heavyweight process of calculating the distance from center to center of one ball to every other ball, then comparing that distance to the sum of their respective radii. If that number is greater than the distance, then I must do further calculations to determine the angle of collision. Like the picture on the left, I can use the differences in x and y coordinate values to calculate that angle, but what do I do from there? Well, once I have that angle, I plan to apply the great and powerful Law of Conservation of Momentum, to determine the outcome, and here comes the tricky part. In Physics, many of the collision problems we are required to solve are called elastic collisions, in which no kinetic energy is lost during the collision.
I have noticed, however, that in the simulation, this results in an unreal behavior of bouncing, which makes sense, considering all real-life collisions (including the one one the right) are inelastic. This means that I need to assign some arbitrary dampening value to collisions (in the previous post, this value was set to 10%). So, like I said, this wasn't easy, and I haven't quite got the algorithm working perfectly, yet. But I plan to keep working on it and get it nice and optimized for my presentation.

Thanks for reading!
- Jeff 


A Visual Conclusion

The time has come to start considering how to structure my presentation. While it is necessary to show my data that I have collected and show my statistical analysis, I need to keep it interesting. I plan to show, as well as prove, the complicated differences in Java and C++. It may be easier for me to stand up in front of a powerpoint full of numbers, and explain how I derived my conclusions, but I want to allow my audience to make those conclusions as well. It is for this reason that I have been working on a couple programs, one in Java and one in C++. These programs, called Physics Engines are designed to replicate the behavior of real objects (in my case, in two dimensions). Having the ability to visual demonstrate the differences in Java vs. C++, I think, is going to make my presentation that much more compelling. As Mr. Mac said to our Physics class, "You want to make your audience feel smart at the end of your presentation." I think that this is the best way to do that. To allow my audience to see for themselves the numbers and data that I can rattle off like an auctioneer, will make the biggest impact to my audience.

Thanks for reading,
- Jeff

Friday, March 22, 2013

// Commenting Code

Comments segments of text placed inside of source code that are not compiled. They serve simply to help the programmer and user to understand what the code is doing and why. There are many different types of comments, as well. Among others, there can be title comments, documentation comments, even legal comments. For example, many commercial Open Source projects must add in the GNU Public License, in the form of a large block comment, to the top of every file in their code.

/*
* This is a block comment.
* It is not compiled. It is only used for    
* notation purposes.
*/

Comments must be led by a specific language-defined character or characters that tells the compiler, "This is a comment, please ignore." As an example, Java uses double slashes (//), and Shell Scripts use pound symbols (#). In the picture is my testing script that I wrote two weeks ago. All the gray text is commented code. Obviously, I went a little overboard on the comments, as most of what was said in them can be easily inferred from the actual code. This style of commenting is typically frowned upon in larger programming projects, because some say that it clutters the code even more. A popular saying among programmers is, "Don't comment code, comment decisions." This limits comments to only the most important statements.

Interestingly enough, the Java JDK includes a tool, called Javadoc, that allows programmers to make code documentations from their comments, using keywords like "@params ... " and "@returns ... ." Using Javadoc may be one of the only times where it is necessary for the programmer to heavily comment every public method in all their classes.

In conclusion, comments are a good way for a programmer to write down what his intentions are for the code, and note any important or confusing code. As long as they are not overdone, comments can be incredibly helpful.

// Thanks for reading, as always!
// -Jeff

Wednesday, March 20, 2013

C++ Test Results Are In!

Feel free to click on this photo to enlarge it!

Above you can see some results that I have collected from the students of Dr. Bazzi. I concealed their full names for privacy reasons.  And of couse, Dr. Bazzi has many more students than just nine; I only used the programs that passed all of his tests and received 100%.

In the above tests, I had the compilers compile and run my own custom-written programs, which were considerably more cpu-intensive than the default test files. It is important to note that the students wrote these programs to pass the tests, not for speed, so optimization was not a factor in their programming. However, I believe that this fact does not ruin the integrity of the tests, as both Java and C++ programs will have been written sans-optimizations.

The runtimes are measured in seconds, using the GNU "time" command specified for "User Time." This means that the run times do not include system I/O, only pure computation times. The reason we do not want to record system I/O time is because that time can vary huge amounts on different machines and different hardware. It can even vary based on where the program is reading/writing in the computers file system!

 I find it quite interesting to see the massive amount of differences in runtimes between the programs (ak vs. cm, for example). And I will be going into much more detail about the nature of the tests run in my presentation, and this is by no means a formal explanation of the data. I just thought that you may want to see a little glimpse of some of the data I am collecting. Thanks for reading, and stay tuned!

-Jeff

Friday, March 8, 2013

Fighting bugs


For the last few days I've been fighting bugs. I've started work on a secret Java project (oh boy!), and as with any big project, there are always bugs. I've squashed a few of 'em, yet more seem to keep working their way out of the cracks, those sneaky little punks. Below is one of the nastiest bugs I've encountered so far. It's a null pointer exception seemingly coming from within the Java virtual machine, but I highly doubt that. Usually, these kinds of exception print out exactly which line of code is causing the issue, but this one is a little more difficult. What I have to do is retrace all my steps and work my way through the flow of variables until I find it, because someone somewhere is calling a method on a null object and it's my job to hunt it down and squish it.



So rather than fix it right this minute, I'm going to blog about it. Because why not?

When a critical error occurs within any higher-level programming language, the code does something called "throwing an exception." When the code throws an exception, it immediately stops what it's doing and follows its path all the way up the program stack, recording every step it takes so that it can print out something useful for the debugger. In the picture, all the lines that start with "at" are steps that the exception took before it printed this error message. If the exception works its way all the way up the program stack without being caught, it kills the program and prints its message to the computer's console. If the programmer is expecting an error like this and wants to handle it in a specific way, he can put the problematic code inside a try{} catch{} statement, and any exception that matches the exception specified in the catch's parameters will stop right there and execute the code inside the catch's block.

 Using these techniques it is possible to make a program more "robust" by being very thorough and catching any error that could possibly occur during normal program usage. If your program is designed for security reasons, like a bank account application, it is imperative that it catch any and all exceptions, so that the bank's servers can remain operational. Otherwise, it would be easy for any hacker to input some malformed code and gain access to the bank's private information and money. So yeah, in today's society, programmers can have just as much responsibility as an armed guard in a bank.

Well, thanks for reading, and everyone enjoy your spring break! (I know I will) 

-Jeff

Wednesday, March 6, 2013

A day in the life of a Computer Science student.

So today I impersonated a Computer Science student, and attended CSE 340, a class that Dr. Bazzi teaches. It was very interesting, and quite different from my current Computer Science class at BASIS. First of all, at the 340 level, the students are assumed to know how to program, so the course is not teaching students to program. Instead, it is much more abstract and theoretical, like the difference between learning Calculus and learning Calculus-based Physics. It is already assumed that you know Calculus when you enter a Calculus-based Physics class. For example, in my current CS class we learned about variable types and their significance. In CSE 340, we learned about what makes data types equivalent and to what extent can we allow them to be equivalent. Let me explain.

Equivalence Types:

There are two basic forms of equivalency, name equivalency and structural equivalency.

According to name equivalency, we can say that two types are equivalent if they are declared to be of the same built-in types or the same programmer-named type. This is a simple definition, created by the syntax and semantics of specific programming languages, but why are they defined this way? What are the underlying reasons for name equivalency? That's where structural equivalency comes into play.

Structural equivalency is where the definitions get much more complicated. When we got to this point in Dr. Bazzi's class, he projected a sheet of information onto the board that looked more to me like Math than Computer Science. I quickly copied down five definitions of structural equivalency.

The following are the limitations that Computer languages must follow when defining their variable's equivalency rules, called permissive structural equivalency.


We can say T1 and T2 are structurally equivalent if
1. T1 and T2 are the same basic type
 
2. T1 = pointer to t1
     T2 = pointer to t2
 
3. T1 = struct {
a : t1;
a2 : t2
}
     T2 = struct {
         a : t1
 a2 : t2
    }
    and ti is tructurally equivalent to t'i for i'=1 to k
 
4. T1 is array range1 of t1
     T2 is array range2 of t2
     AND
  a) range1 and range2 have
 (1) the same number of dimensions and (2) the same number of entries in each dimension
  b) t1 and t2 are structurally equivalent 
5. T1 = fuction of (t1, t2, ... tk) returns t
     T2 = function of (t'1, t'2, ... t'l) returns t'
 AND
  a) is structurally equivalent to t'i and
  b) t is structurally equivalent to t'

It's amazing how much Computer Science is similar to Math. As Dr. Bazzi told me in our first meeting, "Math is very important. Computer Science is just another way to write Math."

I enjoyed getting a glimpse into the world of a Computer Science student at ASU, and I hope you enjoyed reading about it. Stay tuned!

-Jeff

Friday, March 1, 2013

Finally, Data!

Below, you are seeing a Terminal output of one of ASU's Ubuntu servers. I ran my new and improved script on it, and finally, I got data! After hours of debugging my stupid mistakes, I finally got it to work. On the top of the screen is my verbose output version I had to write in order to debug the problems, and on the bottom is the data. It's not much now, but it will grow. With this tool that I have written I can easily modify the commands to test different aspects of the computer language, and print it to the terminal. I plan to gather all this information into spreadsheets and use it to create both comprehensive and comprehendible graphs for my audience.

Ubuntu's XTerm successfully running Jeff's Testing Script v2.0

About the Script: 

I rewrote my first shell script to be much more robust and much more comprehensive. I cracked down on integer overflow and avoided executing any commands inside my timing loop besides the target program. On top of that, I rewrote my timing function to average the results of over 20 tests, giving me much more accurate, and much more trustable data. While testing my script, I noticed that the first result  of the timing tests was always slightly slower than the others, I suspect this is due to some program initializations that go way over my head. Regardless, I took this into account in my script and subtracted the first value from every test in order to reduce any inaccuracies caused by it.

In conclusion, I have finished construction of my program testing script, a tool that is going to help me collect the necessary data I need to back up claims in my report. Next thing I need to do is begin gathering all the data on as many programs as necessary. That's all for this week, and thanks for reading!

-Jeff

Wednesday, February 27, 2013

More Shell Scripting!

A quick program I wrote for testing runtimes.
Actually, I was testing the testing of runtimes.
Gotta love testing!
So I wrote version one of my testing script on Monday and ran it on ASU's server. It did alright but there were some errors and I was not certain that the runtime data I was getting could be trusted. This is because I was using the GNU date command, which is supposed to fetch the current UNIX time in milliseconds since the last epoch, in 1970. As you can probably tell, that is a very large number. So large, in fact, it would sometimes overflow the variable's range, and I was sometimes getting ridiculous negative numbers. So, back to the drawing board. Today I built a small program in C++, as shown to the right, that calculates the first million Fibonacci numbers, which only takes about 0.117 milliseconds. I can use this program as a target for my runtime testing script while I'm debugging it.

So that's what I've been doing, testing and writing and testing and writing. I'm learning a lot about shell scripting, about C++, and about Computer Science in general. I've been using an amazing tool I found, called TextMate. It is an open source text editor specifically designed for programmers. It can compile and run just about any programming language you throw at it, all inside the app. It's very impressive. I actually just talked to the main developer, Allan Odgaard, yesterday on IRC and told him so. I would highly recommend this to any of my fellow programmers running OSX.

Thanks for reading!

- Jeff

Monday, February 25, 2013

I am compiling compiled compilers.

On Friday, Dr. Bazzi offered me the opportunity to run some tests on some of his student's programs from the compiler project. So I have begun work on that. Basically, what I need to do is test the programs to make sure they are functioning correctly, then I need to time their execution and compile all of that data into a spreadsheet for further use. It's quite interesting how the student's compilers are tested. What I am given is a list of programs written in a simplified code that the student's compilers should be able to work with. I am also given a list of expected outputs of the student's programs. So I need to compile all the programs, run them on every test file, and make sure that their output matches the expected output. Sounds kind of tedious, right? Wrong!

Instead of doing all that work manually which would take hours and probably days, I'm doing it with a bash script. A bash script is a very high-level kind of code that is written in a computer's command prompt. Bash scripts are incredibly useful for automating tasks.

My friend and fellow researcher, Mohsen, showed me a script that he wrote in order to grade his students on their project. He ran the script and a few minutes later it had generated a huge matrix of 0s and 1s, which he could directly import into a spreadsheet for grading. I found it incredibly fitting that Computer Science students were graded in 0s and 1s.

So I'm writing a bash script to test the programs, and I'm also writing one to time the programs, so that I can take data regarding their typical run times. Although these programs are not designed to be fast, I feel that I have a large enough sample to record an typical run time for both Java and C++.

My goal for this project is to generate plentiful data that I can use for graphs on my presentation. To do so, I must congregate all of the student's programs into one spread sheet for data, which leads me to the title: I am compiling compiled compilers. Thanks for reading!

-Jeff

Friday, February 22, 2013

I am compiling a compiler.

I started my first large-scale programming project today. The problem I am solving was made by Dr. Bazzi for his Computer Science class 340. It is essentially a simplified version of a compiler. If you don't know, a compiler is the program that turns a source code, written by a programmer, into something that the computer can execute. What this program has to be able to do is input a file of source code, and output a file of compiled code. An additional task that Dr. Bazzi has issued to his student was that the program must also be able to execute that file of compiled code.

The only difference between the assigned compiler and a real compiler is simplified programming languages. The input file is written in a very bare-bones and basic language, and the compiled code does not have to be machine code, but rather an intermediate type of code that the program can execute at a later date.

So in conclusion I am writing a compiler that compiles a simplified programming language into another language, and then executes it. The compiler that I am writing, as with all programs, must be compiled, which leads me to the statement: I am compiling a compiler.

Thanks for reading,
- Jeff

Friday, February 15, 2013

The Search for Open Source Code

So I have begun a hunt for code that I can use for testing and analytics. And the code that I use must be available to read, not only run. Because while I will be doing a number of run-time analytics like performance and memory consumption, I will also be doing source code analytics. Analytics like total lines of code, or number of classes, measurements that would not be possible without access to source code, the readable, human-written form of programs. But source code is not always easy to find.

Since source code can be compiled and run on any compatible computer, publishing source code is pretty much giving your program away for free. Nowadays, almost all of the most popular software companies charge money for their software, so source code cannot be published from those companies. This is a shame, because I like open source software, and free software means a lot more than just a free price. Free software gives users complete control over their computers by giving its users the ability to modify the source code. For example, say a text editor on your computer cannot open a specific file type that you use without reformatting the pages and ruining all your beautiful bullet points. Well, if that program is open source then you can take control and fix it yourself, or more likely, search the internet for a fix already written. If the fix has not been written, and you want to alleviate the pain of those in the future who will encounter that same problem as you, then you can write the code and publish it yourself. It's a beautiful system full of progress and void of capitalism, but let's not start with that.

The main reason I like open source is because it allows me to read through the code and actually understand how a program is written. It's like taking apart a new remote control car to see how it works. It's incredibly fun and interesting and it promotes learning. So over the next few days I will be doing just that. I will be reading through others code and searching for the perfect example of Java or C++ to use for testing.

Thanks for reading!

-Jeff

Thursday, February 14, 2013

Today I Learned: Generic Programming

I read a very interesting article today regarding the differences between Java and C++ from the viewpoint of something called "Generic Programming," and I would like to share the basics of that with you. I am aware that I may lose some of you along the way, however I will do all I can to keep it clear and concise.

Generic programming is a powerful tool that can be used for applications that store a lot of data. For reference, the paper that I read was called  A Comparative Evaluation of Generic Programming in Java and C++ by Hossein Saiedian and Steve Hill. It goes into much further detail onto the specifics and does a better job -I'm sure- of describing the differences, but it is very technical. I am going to attempt explain how this paper proves C++'s implementation of generic programming is more efficient than Java's in a simple and easy to follow way.

To begin, what you need to understand is this: When a computer program interacts with data, it must use either objects or primitive data types. These are specifications that tell the computer what kind of data it is operating on. Primitive data types are rather simple, like an Integer (int) or a Character (char). But objects are data types that can be defined by the programmer, opening up many more opportunities. For example, if I wanted to give my dog a shiny new blue collar I could say something like...

       Dog Chance = new Dog();
       Collar blueCollar = new Collar(Color.BLUE);
       Chance.setCollar(blueCollar);

Here we see the objects 'Dog,' 'Collar', and 'Color' used. Now don't worry if you don't know how to program because that's all you need to understand about that. But if you do know Java programming, and are preparing to complain in the comments that I failed to import Java.awt.Color, all I have to say is I was being "clear and concise!"

These objects, like "Dog," can be part of a larger definition of objects (aka class), like "Pet" or maybe "Animal." In Java all user-defined objects are derived from one class, "Object." In contrast, C++ does not have one giant class to which all other classes belong. Two classes in C++ are not necessarily derived from the same class. This is an important distinction.

Generic programming is a technique of programming that enables the computer to operate on data without actually knowing what type of data it is operating on. The benefits of this include modularity and reusability of code. Let's take an example design of storing data in a numbered list. In C++ this can be done rather simply using vectors, provided to programmers in the standard C++ library, std. A programmer can choose to only allow a certain type of object into a vector list, or one could choose to allow any objects in. Std::vector is a simple way of storing data using generic programming in C++. 

In Java it is also possible to store data in numbered lists, Array or ArrayList being a few common ways, both of which can be initialized without a type parameter, meaning you can create and add to these lists without needing to know the data type. The difference between Java and C++ is when a programmer chooses not to provide a data type to their Array or ArrayList, Java uses the Object type. So while generic programming is written almost exactly the same as in C++, Java's version is not truly generic. 

Why would this matter, you ask? It matters because C++'s version of generic programming is much more efficient. The language was specifically designed with generic programming in mind. Whereas Java's version of generic programming is more of a work-around, and the non-type specific Arrays actually call methods of the type Object which must implement a Container interface, which slows down generic programming for Java.

I found this article very interesting. Deep language analysis like the one seen here is something that I would love to include in my presentation. I hope you followed along for the most part, and I hope you enjoyed this article. Thanks for reading!

-Jeff

Saturday, February 9, 2013

Constructing a table.


No, I'm not sawing wood into four legs and a large plane to be used as a vehicle for eating or reading or writing. I have plenty of those, and don't need to make another one. I'm talking about a data table. A beautifully geometric compilation of information in a neat and organized form. Why? Well, let me explain.

So, as previously written, I have been reading. Reading and reading and reading. I have been reading a wide range of articles and postings about many different aspects of Java and C++. Mostly they are scientific articles, usually containing a (preferably large) sample size of tested scenarios and programs, including different compilers and operating systems. In contrast, some things I have read are commercial articles suffering from a severe case of layman's terms, and others too are forum posts, containing a large amount of differing (though unsupported) opinions. Clearly, some of what I read cannot be trusted, while others can. However, all of which are valuable in some small way. Either they offer a unique way of approaching the problem or give a unique piece of evidence, something valuable can be learned from almost all of my readings.

In order to make use of all the information I have encountered, I find it necessary to create a table of data from all those articles. This data is not the type of data you may think it is. I'm not just talking about numbers from tests and programs. I will be noting other important factors, for example, what parameters does a specific paper use to judge the “performance” of a programming language, or what results does the paper value most and why. Comparing the differences between the approaches that these articles take to prove their points will help me decide what kind of approach I can take in order to have the most comprehensive and factually sound comparison, because that's what this is, right? "A Comprehensive Comparison."

I have a lot of work ahead of me, but I'm dedicated and willing to put as much time into this project as necessary. I may be crazy, but I’ve been enjoying all of this technical reading.

As always, I will keep you updated on all the exciting things I am learning from this project, and the progress I am making. Thanks for stopping by, and stay tuned!

-Jeff

Wednesday, February 6, 2013

Read Read Read...

Hello!
It's reading week for me in the Computer Science Department. How fun! *rolls eyes*
Despite this, I must say that reading is something that everyone must do to prepare for a project, no matter how boring. I mean, what good is research if not built off of other research? And what is the purpose of that research if it is not shared publicly? I believe it is the duty of scientists and researchers to spread new knowledge so that it can be utilized everywhere in the world.

I know, I know. I may be a little idealistic because, obviously, research institutions need to make their money somehow, and my head is just stuck in the clouds; however, at ASU, something is different that proves I may not have my head so far up in the clouds. Let me elaborate: on Monday, when Dr. Bazzi was showing me around the Department, he told me something wonderful. When using ASU's wireless internet, everyone can access all articles on Google Scholar that used to be locked behind a price tag.

Wonderful, right?

I know it may sound simple, but for a researcher and a lover of knowledge, I am finally free. And with Google Scholar, reading is actually a little bit fun. A little bit.
I have access to a wealth of articles from very reputable sources, using brilliant methods to test and prove their hypotheses and analyze their data. I no longer have to sift through the commercialized journal articles of online news sites, now I have great sources.
So there's an update, articles are being read and notes are being taken. I'm excited for the future of my research, and I hope you are too. Stay tuned!

~ Jeff

Tuesday, January 22, 2013

Welcome to my blog o' sphere!

Welcome to my blog! I will be updating this blog during the entirety of my senior research project, something that I'm very interested in and excited about. My main question is as follows: In what specific functions is Java faster than C++ and vise versa? This question is infamous on the internet and is known to ignite flame-wars in forums and comment threads alike (think Mac vs. PC or Dogs vs. Cats); however, the debates almost always end up more like: "C++ is obviously faster, duh! Why do you think Apple uses it?" or... "Bro, do you even code? Java is best!" This obviously is not the goal of my research work. I hope to determine with factual and statistical certainty the pros and cons of both languages, and discern which would be more optimized for specific applications.

*Phew*

I get the great privilege to work alongside some brilliant minds of research team of the ASU Computer Science department, and a very kind and intelligent Associative Professor of Computer Science named Dr. Rida Bazzi.

And just for the sake of documentation, I thought it would be a good idea to take down my current opinions and biases for future reference and comparison. So here goes...

My original argument right off the bat and without having done any experiments yet is the following: I believe that through tedious and careful programming, it is entirely possible to optimize C++ code to a higher degree than Java; however I believe that the cost of production and maintenance of that program would be significantly higher due to C++’s inability to be ported to other machines, and it’s difficult manual memory allocations. However, at this point, due to the absence of any actual testing, I acknowledge I may be slightly biased.  I acknowledge the possibility that I am biased towards Java because I have done more extensive study in the Java language, and it’s code makes more sense to me than C++ code. That being said, C++ is widely acknowledged for being one the most difficult languages to learn to use effectively. To prevent this bias, I hope to be able to consult with my peers at ASU, to be sure my C++ programs are effectively optimized and that I am testing it’s applications with fairness.

Thanks a bunch for reading, and don't worry, in the future I will be bringing some visual aids and some really cool graphs to help combat the wall of text before you. Feel free to sign up for email updates in the sidebar, and stay connected! See you soon!


-Jeff